Авторизация с помощью ролей в луковой архитектуре

всем привет

У меня есть проект, в котором я использую ASP.NET Identity 2.0. В этом проекте я следую архитектуре Луковицы. слои:

1.UI: нет ссылки на Owin или ASP.Net Identity

2.AuthenticationService: содержит оболочку для usermanager идентификации asp.net. Эта оболочка реализует интерфейс, который живет на уровне Bal. Этот уровень также содержит мой пользовательский UserStore.

3.Dal: Здесь живет DbContext.

4. Баланс: содержать сущности и интерфейсы домена. Нет ссылок на Owin, удостоверение ASP.NET или что-либо еще.

5.DependencyResolver: здесь запускается Owin, а также несколько модулей Ninject и NinjectWebCommon. Итак, я использую Ninject.

до сих пор все в порядке. пользователи с удовольствием создают учетные записи, и они могут входить / выходить из системы / управлять в любое время, когда захотят. Проблема, с которой я сейчас сталкиваюсь, связана с авторизацией (Role = "rolename"). Это просто не работает.

[Authorize(Users="pedro")]
[Authorize]

обе эти работы

[Authorize(Roles="Admin")]

это один нет.

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

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

Спасибо за уделенное время


asp.net-mvc asp.net-identity owin onion-architecture
person TuxAddictor    schedule 16.11.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

ну Здесь я отвечаю на свой вопрос.

На самом деле проблема заключалась в том, что метод User.IsInRole (или IPrincipal.IsInRole, потому что User является IPrincipal). Проверка кода AuthorizeAttribute с помощью отражателя показывает, что этот атрибут использует метод IsInRole для проверки того, находится ли аутентифицированный пользователь в роли X или Xs. но здесь возникает другой вопрос. Почему он не может этого сделать, я имею в виду, почему он не может найти вне зависимости от того, принадлежит ли пользователь определенной роли или нет.

проблема возникает из-за Cookie, созданного для пользователя. поскольку роли связаны с Cookie, они должны быть там, поэтому IsInRole может их найти, и именно здесь я совершил свою ошибку. Я переместил аутентификацию и авторизацию в другое место, но не сделал этого. t предоставляют способ встраивать информацию о ролях в файл cookie, чтобы IsInRole (от пользователя или от ролей) не мог их найти, чтобы атрибут авторизации выполнял свою работу так, как я хотел. поэтому хорошая новость заключается в том, что я нужно только как-то вставить роли внутри файла cookie.

лучшая новость: ASP.NET Identity, которую я сейчас использую, поддерживает утверждения, а в 4.5 GenericPrincipal является производным от ClaimsPrincipal, который, в свою очередь, является производным от IPrincipal, поэтому я могу работать с утверждениями, а не с ролями старой моды (которые мы все еще можем использовать, если хотим к).

ну. если кто-то сталкивался с такой же проблемой, я рекомендую следующее:

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

2. используйте thinktecture Nuget, а не атрибуты Authorize или ClaimsPrincipalPermission, что дает вам преимущества обоих из них.

3.Узнайте о претензиях. Вы никогда не пожалеете об этом.

person TuxAddictor    schedule 19.11.2014