Использование авторизации на основе утверждений

Новый код ASP.NET 4.5 "повторно зарегистрировал" роль ASP.NET RoleProvider для ClaimsProvider.

То, что я пытаюсь понять, это то, как выглядит пример утверждения на основе требований (желательно в MVC4)? Как мой атрибут Authorize взаимодействует или нет с этой возможностью? API WebSecurity и Roles не изменился; отсутствует подпись "DoUserHaveClaim()". Точно так же неясно, как атрибут Authorize взаимодействует с претензиями.

Была ли эта функция авторизации претензий предназначена главным образом для OAuth? Если да, то как претензии направляются в мое приложение? Печенье? Или была ли эта функция требований-поставщиков, предназначенная для более широкого использования?

Короче говоря, что такое история использования ClaimsPrincipal?

Ближайшая вещь, которую я видел для чего-то, что имеет смысл, эта дискуссия. Но я подозреваю, что это датировано - его следует сравнить с тем, что создает шаблон интернет-проекта MVC4. И даже тогда он все еще не предлагал, как использовать атрибут Authorize с настройкой.

UPDATE

Я нашел ответы на свои вопросы из этих источников:

В разделе примечаний ClaimsPrincipal объясняется, что API WebSecurity, Роли и AuthorizeAttribute действительно сводятся к проверкам претензий по мере необходимости.
Пример MVC4 на основе утверждений здесь (наряду с другими).
Базовая История SAML показана здесь.

Ответ 1

Защита, основанная на требованиях, помогает отделить вашу модель безопасности от вашего домена приложения. Требованием может быть все, что вы хотите прикрепить к личности пользователя, например, по электронной почте, номеру телефона или флажку, указывающий, является ли пользователь суперпользователем. Это дает вам максимальную гибкость в отношении того, как вы хотите настроить процесс авторизации. Исторически в приложении ASP.NET вам необходимо определить, какие роли вы хотите разрешить и применять их при программировании вашего приложения. Затем вы проверяете, находится ли пользователь в роли для авторизации. Это сочетает вашу модель безопасности с вашим приложением. В зависимости от претензий вы обладаете гораздо большей гибкостью, и более типично настраивать схему авторизации, которая берет ресурс (например: Заказы в системе управления заказами) и операцию (например: чтение, запись, выполнение) в качестве входных параметров для вашего авторизации, эффективно отделяя безопасность от вашего приложения. См. ClaimsPrincipalPermissionAttribute для примера этой техники.

Защита от претензий требуется с OAuth, но она хорошо работает и с другими схемами авторизации. Пользовательские заявки, которые вы используете в своем приложении, доступны из ClaimsPrincipal.Current. Существуют методы хранения этой информации в файлах cookie, хотя конвейер безопасности ASP.NET не делает этого по умолчанию.

Обсуждение, на которое вы ссылаетесь, относится к Windows Identity Foundation (WIF), который теперь является частью .NET в версии 4.5, и поэтому идентификация на основе утверждений является гражданином первого класса. Все типы Principal наследуются от ClaimsPrincipal. Для хорошего обзора безопасности на основе требований смотрите эту бесплатную электронную книгу " Руководство по идентификации и контролю доступа (2-е издание)". Настоящим экспертом в этой области является Доминик Байер и его блог, наполненный полезной информацией по этой теме. У него также есть отличный онлайн-курс по Pluralsight под названием " Identity and Access Control в ASP.NET 4.5.