Эта документация перемещена в архив и не поддерживается.

Авторизация в веб-приложениях и службах с поддержкой утверждений

Опубликовано: Апрель 2011 г.

Обновлено: Июнь 2015 г.

Назначение: Azure

  • Microsoft Azure Active Directory Access Control (также называется Access Control Service или ACS)

  • Windows® Identity Foundation (WIF)

  • ASP.NET

  • Windows Communication Foundation (WCF)

В приложении проверяющей стороны авторизация определяет, к каким ресурсам у прошедшего проверку подлинности удостоверения есть доступ и какие операции ему разрешено выполнять с этими ресурсами. Неправильная или слабая авторизация может привести к разглашению информации и искажению данных. В этой статье описаны доступны подходы реализации авторизации для веб-приложений и служб ASP.NET с поддержкой утверждений с использованием Служба управления доступом и WIF.

  • Перечислить способы авторизации, использующие утверждения.

  • Описать высокоуровневую концепцию для каждого подхода.

  • Указать преимущества и недостатки каждого подхода.

С самой первой версии платформа .NET Framework предоставляет гибкий механизм для реализации авторизации. Он основан на двух простых интерфейсах IPrincipal и IIentity. Конкретные реализации IIentity представляют пользователя, прошедшего проверку подлинности. Например, реализация WindowsIdentity представляет пользователя, который проверяется Active Directory, а GenericIdentity — пользователя, который проверяется с помощью настраиваемого механизма проверки подлинности. Конкретные реализации IPrincipal помогают проверять разрешения, используя роли, в зависимости от хранилища ролей. Например, WindowsPrincipal проверяет членство WindowsIdentity в группах Active Directory. Для проверки вызывается метод IsInRole интерфейса IPrincipal. Проверку доступа на основе ролей называют управлением доступа на основе ролей (RBAC). RBAC описывается в разделе "Управление доступом на основе ролей" этой статьи. Утверждения можно использовать для переноса информации о ролях, что позволяет поддерживать знакомые механизмы авторизации на основе ролей.

С помощью утверждений также можно реализовать намного более широкие возможности авторизации. Утверждения могут быть основаны практически на чем угодно — возрасте, почтовом индексе, размере обуви и т. д. Проверку доступа на основе произвольных утверждений называют управлением доступом на основе утверждений (CBAC) или авторизацией на основе утверждений. Этот тип авторизации описывается в разделе "Управление доступом на основе утверждений" этой статьи.

Проверки авторизации выполняются на стороне приложения, а не Служба управления доступом. Служба Служба управления доступом действует как служба токенов безопасности (STS), она выдает токены, передающие утверждения приложению. Утверждения добавляются в токены поставщиками удостоверений и, при необходимости, самой службой Служба управления доступом с использованием модуля правил. Когда приложение получает токен с утверждениями, оно может проанализировать его, извлечь нужные утверждения и принять решение об авторизации, используя RBAC или CBAC. WIF используется для синтаксического анализа токена и его обработки при принятии решений об авторизации с помощью простого интерфейса API. Дополнительные сведения о WIF см. в статье WIF SDK (http://go.microsoft.com/fwlink/?LinkID=187481). При рассмотрении авторизации в приложениях и службах с поддержкой утверждений обращайтесь к следующей схеме. Обратите внимание, что после успешной проверки подлинности поставщик удостоверений создает токен (токен IdP на схеме). Токен IdP может преобразовать модуль правил Служба управления доступом. Служба Служба управления доступом может добавить, удалить или изменить утверждения в токене, выданном поставщиком удостоверений. Наконец, токен, выданный Служба управления доступом, передается приложению и обрабатывается WIF. Проверка доступа выполняется в WIF с использованием RBAC или CBAC.

Авторизация WIF для ACS версии 2

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

Для реализации RBAC в приложениях с поддержкой утверждений используйте метод IsInRole() интерфейса IPrinicpal, как и в других приложениях. Метод IsInRole() можно использовать несколькими способами:

  • Явный вызов в IPrincipal.IsInRole(“Administrator”). В этом случае результатом будет логическое значение. Используйте его в условных операторах. Его можно использовать в любом месте кода.

  • Использование требования безопасности PrincipalPermission.Demand(). В этом случае результат — исключение, если требование не выполнено. Данный подход позволяет реализовать стратегию обработки исключений. Вызов исключение обходится намного дороже с точки зрения производительности по сравнению с логическим значением. Его можно использовать в любом месте кода.

  • Использование декларативных атрибутов [PrincipalPermission(SecurityAction.Demand, Role = “Administrator”)]. Этот подход называют декларативным, потому что он используется для оформления методов. Его нельзя применять в блоках кода в реализации метода. Результат — исключение, если требование не выполнено. Следует убедиться, что это подходит для вашей стратегии обработки исключений.

  • Используя авторизацию URL-адреса и раздела <authorization> файла web.config. Этот способ применим, если вы управляете авторизацией на уровне URL-адресов. Он наиболее высокоуровневый метод среди всех упомянутых. Его преимущества заключаются в том, что изменения вносятся в файл конфигурации, т. е. для применения изменения не нужно компилировать код.

При вызове метода IsInRole() выполняется проверка наличия у текущего пользователя данной роли. В приложениях с поддержкой утверждений роль выражается типом утверждения роли, который должен быть доступен в токене. Тип утверждения роли выражается с помощью следующего URI:

http://schemas.microsoft.com/ws/2008/06/identity/claims/role

Существует несколько способов добавить в токен тип утверждения роли:

  • С помощью модуля правил Служба управления доступом — в этом случае вы создаете правило с помощью портала управления Служба управления доступом или службы управления Служба управления доступом, чтобы создать правила преобразования утверждений, формирующие утверждения для определенного типа роли. Дополнительные сведения о правилах и преобразовании токенов см. в разделах Группы правил и правила и Инструкции Реализация логики преобразования маркеров с помощью правил.

  • Преобразование произвольных утверждений в тип роли утверждений с помощью ClaimsAuthenticationManager — это реализуется с помощью ClaimsAuthenticationManager, компонента WIF. Он позволяет перехватывать запросы при запуске приложения, анализировать токены и преобразовать их, добавляя, изменяя и удаляя утверждения. Дополнительные сведения об использовании ClaimsAuthenticationManager для преобразования утверждений см. в разделе Инструкции Реализация управления доступом на основе ролей (RBAC) в веб-приложениях ASP.NET с поддержкой утверждений с помощью WIF и ACS.

  • Сопоставление произвольных утверждений с типом роли с помощью раздела конфигурации samlSecurityTokenRequirement — декларативный подход, при использовании которого утверждения преобразуются только с помощью конфигурации (без кода).

CBAC — это способ авторизации, при котором решение о предоставлении доступа основывается на произвольной логике, использующей данные, доступные в утверждениях. Как вы помните, в RBAC единственным утверждением было утверждение типа роли. Оно использовалось для проверки принадлежности пользователя определенной роли. Чтобы продемонстрировать процесс принятия решений об авторизации с помощью CBAC, рассмотрим следующий процесс.

  1. Приложение получает запрос.

  2. Оно извлекает входящие утверждения.

  3. Приложение передает утверждения логике принятия решений. Это может быть код в памяти или вызов веб-службы, запрос базы данных или вызов сложного модуля правил.

  4. Механизм принятия решений определяет результат на основе утверждений.

  5. Доступ предоставляет, если результатом является истина. Например, правило может быть следующим: пользователь не младше 21 года живет в Ивановской области и был проверен Идентификатор Windows Live ID (учетная запись Майкрософт).

Служба управления доступом действует как служба STS, которая выдает токены, передающие утверждения. Вы можете определять, какие утверждения выдаются (типы и значения утверждений), с помощью модуля правил Служба управления доступом. Дополнительные сведения о модуле правил Служба управления доступом см. в разделах Группы правил и правила и Инструкции Реализация логики преобразования маркеров с помощью правил. ClaimsAuthorizationManager — ключевой компонент для реализации CBAC в приложениях с поддержкой утверждений. ClaimsAuthorizationManager поставляется как часть WIF. ClaimsAuthorizationManager позволяет перехватывать входящие запросы и реализовать любую логику принятия решений об авторизации на основе входящих утверждений. С помощью этого компонента вы также можете вынести решения об авторизации из кода приложения. Это важно, если логику авторизации необходимо изменить. В этом случае использование ClaimsAuthorizationManager не повлияет на целостность приложения, тем самым снизит вероятность ошибки в результате изменения. Дополнительные сведения об использовании ClaimsAuthorizationManager для реализации управления доступом на основе утверждений см. в разделе Инструкции по реализации авторизации утверждений в приложении ASP.NET с поддержкой утверждений на основе WIF и ACS.

См. также

Показ: