Аутентификация ролей в ASP.NET - использование ролей в качестве действий?

Question

Я хочу сделать шаг вперед, чем простая авторизация на основе ролей (Admin, User, Super User и т. Д.)

и вместо этого сделать авторизацию на основе действий.

Мое мышление состояло в том, чтобы назначать действия для входа в систему пользователям, которые связаны с тем, могли ли они выполнять действие.

Например

CreateUser

ReadUser

UpdateUser

DeleteUser

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

т.е.

CreateUser.aspx

на каждой странице я хотел бы сделать проверку, чтобы увидеть, если идентифицированный пользователь действительно имеет право доступа к деятельности.

Я сделал бы это, используя Роли.

, например

IsInRole («CreateUser»)

До этого я мог бы назначить деятельности (роли) для идентифицированного пользователя после успешной регистрации

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

, например, я в настоящее время есть 60 мероприятий в моей системе (но это может возрастать по мере добавления дополнительных функций - каждая функция в itselve новый вид деятельности)

Если куки аутентификации должен нести около 60+ роли (деятельности) может вызвать любые известные проблемы?

Может ли кто-нибудь предложить альтернативный подход?

Answer 1

Возможно, вы захотите изучить IdentityModel framework. Он имеет базовый класс для создания настраиваемого модуля авторизации для проверки разрешений на основе шаблона Resource-Action. Но это построено для .NET 4.5, не уверен, что такое ваша платформа.

.NET 4.5 также включает в себя SessionAuthenticationModule (SAM) для веб-аутентификации. SAM может кэшировать роли между пользовательскими вызовами, так что вам не нужно отправлять их туда и обратно в файл cookie. Here - это дополнительная информация о том, как это работает.

Answer 2

Используйте операции и разрешения, как описано в Ayende's blog. У него много статей по этой теме.

http://ayende.com/blog/3109/rhino-security-overview-part-i

http://ayende.com/blog/tags/rhino-security

Answer 3

Что вы хотите, список возможностей подход.

Решение этой проблемы является отображением ролей в возможностях, похожее на это:

>Online    Anon  User  Admin 
Article    ReadOnly ReadWrite ReadWrite 
Article.List  ReadOnly ReadOnly ReadOnly 
Article.Edit  Hidden ReadWrite ReadWrite 
Article.Delete  Hidden ReadOnly ReadWrite 
Article.Title.Edit *   *   ReadWrite 

На практике это будут ваши координаты:

>(system state) 

Система может быть «Интернет, Offline, Maintenance "и, возможно, больше. Используйте начальный >, чтобы найти начало вашей матрицы в файле (у вас будет много таких). В C# у вас будет enum.

На одной и той же линии являются роли:

Anon User Admin 

Тогда на левой стороне вы будете иметь возможности в области видимости пространства имен и действий:

<item> 
<item>.<action> 
<item>.<field>.<action> 
<item>.<field>.<value>.<action> 

клетки будут содержать один из них значения:

Hidden, ReadOnly, ReadWrite or * 

* будет означать «унаследовать» от родительского элемента или поле.

Таким образом, вы сможете точно настроить разрешения на основе элементов, действий, ролей и текущего состояния системы.

Простой парсер, переводящий список в структуру памяти. Не ставьте это на БД, это будет боль. Сохранять его на уровне текстового файла/на памяти лучше. Добавьте файл FileSystemWatcher, чтобы прочитать этот файл, когда он изменен для дополнительной функциональности и использует ленивую загрузку. Также сохраните его в памяти Application state, а не в сеансе.

Помните: по умолчанию будет Hidden (доступ даже не читать, пункт/действие будет полностью недоступен для этой роли

Ваша реальная проблема будет тогда, какие роли вам действительно нужно (в. мой опыт играет важную роль для актера UML, может быть, с некоторыми небольшими отклонениями), и каковы элементы/поля/значения и действия на самом деле. Когда вы пишете пункт, вы действительно можете иметь в виду группу элементов. нет необходимости сопоставлять список возможностей напрямую с базой данных/сущностью или структурой кода. Список возможностей находится на более высоком уровне языка, это semantic и привязаны к домену, а не к коду (я хочу подчеркнуть это, потому что это реальная сила этого подхода).

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