Авторизация и информация о пользователе на уровне сервиса (приложение .NET) - PullRequest
9 голосов
/ 18 января 2010

В настоящее время я работаю с корпоративным приложением в среде .NET (n-многоуровневая), и мне хотелось бы узнать, как лучше всего управлять аутентификацией / авторизацией + фильтрацией данных в моем BussinessLayer (BL). Мы будем использовать этот BL из нескольких интерфейсов (приложений ASP.NET и WebServices), и я думаю, что мой ServiceLayer должен выполнить эту работу, но я просто не могу найти лучший способ.

Полагаю, это может быть что-то вроде этого: (1) Пользователь проходит проверку подлинности (веб-клиент ASP.NET), возможно, с использованием FormsAuthentication. (2) ASP .NET code (Controller / CodeBehind) создает Сервис для выполнения некоторого пользовательского случая, передавая каким-то образом «Пользователь». (3) Сервисный метод проверяет, существует ли «Пользователь» (аутентификация) и его роли (авторизация), чтобы убедиться, что он может вызвать этот метод. Если не заверено или разрешено, исключение выдается. (4) Сервис использует репозитории + другие сервисы + все, что нужно для выполнения работы. Если требуется какая-либо мелкозернистая фильтрация (например, у пользователя есть разрешения только для некоторых проектов), служба применяет его автоматически.

То, что я хочу, - это изолировать ServiceLayer от «веб-материалов» (не обращаясь к сеансу ...), но кто знает, что пользователь вызывает свои методы, чтобы действовать правильно. Также я не знаю, как правильно сопоставить эту работу с проверкой подлинности ASP .NET ... Я подумываю о том, чтобы свести «пользователя» в служебный ctor, чтобы его методы имели «контекст», в котором они нуждаются, может ли это сработать? ... Буду признателен за некоторые указания или существующие фрагменты кода на этом.

Спасибо за вашу помощь ...

Ответы [ 2 ]

11 голосов
/ 18 января 2010

Прежде всего, аутентификация и авторизация - это две разные вещи. Ваш вопрос подразумевает, что вы уже знаете это, но я просто хотел прояснить это.

Аутентификация должна происходить на границе приложения (например, Аутентификация с помощью форм в веб-приложении).

Подход по умолчанию заключается в том, что модуль аутентификации устанавливает Thread.CurrentPrincipal при успешной аутентификации.

Как правило, IPrincipal является стандартной основой для моделирования пользовательского контекста в .NET. Например, HttpContext.User является IPrincipal.

В ваших доменных моделях и модулях доступа к данным вы можете использовать Thread.CurrentPrincipal для реализации логики авторизации. Это позволяет вам изменять аутентификацию и авторизацию независимо друг от друга.

2 голосов
/ 18 января 2010

Мне кажется, что это и проще, и более расширяемо, если вы позволите уровням клиента (вашему веб-сайту / сервисам) выполнять аутентификацию и оставите BL для хранения только бизнес-логики.

Если вам нужна ссылка на текущего пользователя в BL, вы могли бы рассмотреть интерфейс, чтобы «обернуть» некоторую информацию о личности пользователя, и это можно было бы передать из различных уровней пользовательского интерфейса.

...