ASP.NET: архитектура разрешений / аутентификации

Я собираюсь создать аутентификацию в моем приложении ASP.NET со следующими требованиями.

  • У пользователя ровно одна роль (например, администратор, менеджер по продажам, отдел продаж и т. Д.).
  • Роль имеет набор разрешений на доступ CRUD к подмножеству существующих объектов. Т.е. "У отдела продаж есть права CREAD, READ, WRITE для типа объекта" Products ", но не DELETE"
  • Почему-то мне нравится, что разрешения находятся в иерархии с наследованием, поэтому мне, например, администратору не нужно указывать все доступные объекты.
  • Система должна быть в состоянии быстро ответить на вопрос «Есть ли у пользователя X разрешение выполнять Y с объектом Z».
  • Управление всей базой данных (MSSQL), реализованное на C # / ASP.NET

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


c# security asp.net forms-authentication
person Niels Bosma    schedule 19.12.2008    source источник

Ответы (5)


arrow_upward
6
arrow_downward

Я думаю, что вам нужно здесь реализовать набор методов запроса разрешений либо в ваших бизнес-объектах, либо в вашем контроллере. Примеры: CanRead (), CanEdit (), CanDelete ()

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

Я не могу придумать способ декларативно определить эти разрешения централизованно. Их нужно распределить на реализацию функций. Однако, если вы хотите улучшить дизайн, вы можете использовать внедрение зависимостей, чтобы вставить авторизаторы в свои бизнес-объекты и, таким образом, сохранить отдельные реализации.

В книге Рокки Лхотки есть код, использующий эту модель. Новой версии нет в Google пока нет.

person JoshRivers    schedule 19.12.2008

arrow_upward
2
arrow_downward

Я думаю, что одна из лучших реализаций, которые, как мне кажется, будут соответствовать вашим требованиям, документирована здесь < / а>. Единственная проблема заключается в том, что это подключается к NHibernate, но вы можете использовать его в качестве шаблона для создания собственной реализации разрешений и просто подключаться к своей собственной модели событий, а не к модели NHibernates Interceptors.

Я сам работаю над такой системой и напишу об этом в блоге, когда буду доволен ею.

person Ryan Tomlinson    schedule 16.06.2009

arrow_upward
1
arrow_downward

API членства, предоставляемый начиная с ASP.NET 2.0, должен хорошо соответствовать вашим требованиям. Боюсь, что единственное, чего он напрямую не поддерживает, - это иерархические роли. Однако вы можете легко использовать обычную безопасность на основе ролей с другой написанной вручную иерархической таблицей ролей для достижения требуемых вещей.

person mmx    schedule 19.12.2008

arrow_upward
1
arrow_downward

Вы можете прочитать, как настроить членство в ASP.NET здесь: http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx

Это позволяет группировать папки / страницы и т. Д. В Группы / Пользователи. Думаю, вам этого будет достаточно!

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

person Filip Ekberg    schedule 19.12.2008

arrow_upward
0
arrow_downward

Я бы построил отношения пользователь / роль, чтобы у пользователей могло быть более одной роли. Я вижу отношения 1-1 и нервничаю, потому что знаю, что даже если мы не видим в этом необходимости сейчас, кто-то когда-нибудь захочет, чтобы кто-то был одновременно пользователем отдела продаж и пользователем службы поддержки.

В нашей клиентской системе мы используем роли для наложения таких вещей, как «delinquentCustomer». Таким образом, исходные разрешения остаются в силе - как только они оплачивают свой счет. Стоит рассмотреть этот подход.

person Code Silverback    schedule 12.04.2010