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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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