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

Question

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

R.

Answer 1

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