Полностью настраиваемая аутентификация/авторизация в приложении ASP.NET MVC. Хорошая или плохая идея?

Я уже знаю, что вы говорите (плохая идея), но, пожалуйста, сначала прочитайте :)

Я разрабатываю приложение на основе ASP.NET MVC, для которого потребуются некоторые специфические функции:

  1. комбинация «локальных» пользователей и логина facebook connect, но пользователи FB будут «отражаться» в каком-то локальном представлении, потому что будет некоторая статистика и другие вещи, необходимые для хранения для обоих типов.

  2. авторизация будет трехуровневой вместо стандартных двухуровневой asp.net. Под этим я подразумеваю: пользователь находится в группе (m:n), а группа находится в роли (m:n), а не пользователь в роли (m:n).

Итак, если бы я хотел использовать стандартный подход аутентификации/авторизации, мне пришлось бы:

  1. реализовать пользовательский провайдер членства, и это будет даже «правильным», потому что он будет использовать такие методы, как AddUserToGroup и AssignRoleForGroup и т. д.

  2. реализовать собственный Принципал/Идентификацию для доступа к моим собственным объектам пользователя

  3. приведение HttpContext.User к моему объекту каждый раз, когда это необходимо...

  4. реализовать пользовательский поставщик ролей

  5. собственный механизм использования AuthCookie (уникальный идентификатор пользователя в пользовательских данных, нельзя полагаться на имя пользователя со сторонними пользователями FB в системе)

  6. ... (вы, конечно, можете придумать что-то еще)

Ну, мне действительно не нравится идея «сгибать» и заменять каждую часть, чтобы в итоге получить довольно грязное решение. Поэтому я думаю реализовать свой собственный механизм, инкапсулированный в одном месте — назовем его AuthService.

  1. AuthService будет потокобезопасным синглтоном
  2. Вместо AuthCookie будет использоваться стандартный объект сеанса (я знаю, что сеансы также используют файлы cookie, но я действительно не вижу преимущества низкоуровневого хранилища (файлов cookie) над сеансом)
  3. AuthService предоставит AuthService.CurrentUser (моего собственного типа), заполняемый из сеанса в начале каждого запроса (я думаю, Application_AuthenticateRequest)
  4. AuthService предоставит в одном месте все методы — ValidateUser, RolesForUser, IsInRole, Logout и т. д.

Так что теперь... почему бы мне не сделать это таким образом? :)

Я думаю, что сеанс одинаково безопасен для AuthCookie (те же риски для билета и authcookie). Я действительно не ищу «модульности» (поставщики ролей plug-and-play, поставщики членства, поставщики профилей..) - я имею дело здесь с довольно специфическими вещи, я не ожидаю, что стандартные компоненты подойдут ... есть ли у «моего подхода» какие-либо другие недостатки?

Спасибо за все хорошие идеи и извините за мой ужасный английский, я из неанглоязычной страны :)

R.


authentication asp.net-mvc authorization
person rouen    schedule 19.04.2010    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Я, конечно, понимаю, почему вы не хотите внедрять всего поставщика членства. Однако я бы воспользовался низкоуровневой поддержкой, предлагаемой аутентификацией форм (например, файл cookie, истечение срока действия и т. д.), и просто выполнил бы свою собственную пользовательскую аутентификацию. Если вы сделаете это, вы сможете внедрить свой собственный пользовательский класс в контекст HTTP и использовать его во всем коде. Ваш пользовательский объект будет реализовывать IIdentity и IPrincipal. Ваш IPrincipal.IsInRole будет работать против вашей пользовательской схемы аутентификации. Это позволит вашему коду более высокого уровня использовать стандартные разрешения .NET framework. Это самый изящный и простой способ добиться того, чего вы хотите, используя при этом то, что уже существует.

person Tom Cabanski    schedule 19.04.2010