7

Я добавляю ASP.NET MVC в существующее приложение WebForms. В настоящее время мне не нужна аутентификация/регистрация, так как эта часть обрабатывается существующим кодом (проверка подлинности форм).Разрешение на основе разрешений в ASP.NET MVC3

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

Как я понимаю, для ASP.NET MVC существует стандарт AuthorizeAttribute, где я могу указать роли. Я также нашел несколько статей, которые предполагают, уточняющие права вместо роли - то, что можно сделать что-то вроде этого:

[CustomAuthorize(Roles = "View products, Edit products")] 

Расширяя AuthorizeAttribute, я могу также определить, как хранить и права доступа.

Это решение было бы приемлемым для меня (хотя изменение семантики ролей немного пахнет).
Но прежде чем переходить к нему, я хотел бы посмотреть, какие у него есть другие варианты. И вот где я застрял - я не нашел полномасштабный обзор различных подходов к авторизации в ASP.NET MVC. Я также хотел бы знать, как все концепции безопасности (например, Аутентификация форм, Поставщики членства, Атрибут авторизации, IPrincipal и т. Д.) Связаны друг с другом и как они должны работать вместе.

+0

Это похоже на то, что было опробовано здесь: http://stackoverflow.com/questions/10338734/custom-security-scenario-in-asp-net-mvc/ – antijon

+0

@antijon Насколько я понимаю, это похоже на реализуя пользовательский атрибут AuthorizeAttribute. Но я хотел бы узнать более подробно о других вариантах и ​​их плюсах и минусах. –

ответ

7

Первое, что вам нужно понять, это то же самое, что и Webforms, в MVC есть конвейер. Каждый запрос проходит через ряд методов, и есть точки расширения по пути, на которые вы можете «зацепиться» и сделать что-то.

Все атрибуты AuthorizeAttribute связаны с точкой расширения OnAuthorization и принимают решение о том, предоставлять ли кто-либо доступ или нет на основе критериев, которые вы ему предоставили (имена пользователей, роли и т. Д.).

Вот пример: http://geekswithblogs.net/brians/archive/2010/07/08/implementing-a-custom-asp.net-mvc-authorization-filter.aspx

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

Это метод, который предпочитает MVC. Еще одна приятная вещь: если вы также сделаете ее фильтром, вы можете добавить ее в глобальные фильтры и применить ее ко всему, если хотите.

У вас в основном есть два других разумных варианта. Внедрите обработчик в global.asax в Application_AuthenticateRequest (не рекомендуется) или создайте общий BaseController, который вы переопределите OnAuthorize (атрибут перехватывает одно и то же, но в другом месте).

Многие люди пытаются выполнить аутентификацию с использованием переменных Session, и это самое худшее.

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

+0

Благодарим вас за ответ!Что касается аутентификации - это просто имя пользователя и пароль через Forms Auth и использование пользовательского класса. Что касается системы разрешений - для каждой страницы у нас есть «ключ модуля», и мы сохраняем в разрешениях базы данных для каждого пользователя доступ к каждой странице. Проверка прав в настоящее время реализована в «BasePage: Page». Я не уверен, что это информация, которую вы хотели бы знать? –

Смежные вопросы