Авторизация в веб-приложениях и службах с поддержкой утверждений
Обновлено: 19 июня 2015 г.
Область применения: Azure
Применяется к
Microsoft Azure Active Directory Access Control (также называется Access Control Service или ACS)
Windows® Identity Foundation (WIF)
ASP.NET
Windows Communication Foundation (WCF)
Сводка
В приложении с проверяющей стороной авторизация определяет, к каким ресурсам имеет доступ удостоверение, прошедшее проверку подлинности, и какие операции ему разрешается выполнять по отношению к данным ресурсам. Неправильная или слабая авторизация приводит к утечке информации и хищению данных. В этом разделе описываются доступные подходы к реализации авторизации для поддержки утверждений ASP.NET веб-приложениям и службам с помощью ACS и WIF.
Задачи
Перечислить способы авторизации, использующие утверждения.
Описать высокоуровневую концепцию для каждого подхода.
Указать преимущества и недостатки каждого подхода.
Обзор
Начиная с первой версии, .NET Framework предлагает гибкий механизм для внедрения авторизации. Он основан на двух простых интерфейсах IPrincipal и IIentity. Конкретные реализации IIentity представляют пользователя, прошедшего проверку подлинности. Например, реализация WindowsIdentity представляет пользователя, прошедшего проверку подлинности Active Directory, и GenericIdentity представляет пользователя, прошедшего проверку подлинности с помощью пользовательской проверки подлинности. Конкретные реализации IPrincipal помогают проверять разрешения, используя роли, в зависимости от хранилища ролей. Например, WindowsPrincipal проверяет WindowsIdentity на членство в группах Active Directory. Для проверки вызывается метод IsInRole интерфейса IPrincipal. Проверка доступа на основе ролей называется управлением доступом на основе ролей (RBAC). RBAC описывается в разделе "Управление доступом на основе ролей" этой статьи. Утверждения могут использоваться для передачи информации о ролях в целях поддержки традиционных механизмов авторизации на основе ролей.
С помощью утверждений также можно реализовать намного более широкие возможности авторизации. Утверждения могут быть основаны практически на чем угодно — возрасте, почтовом индексе, размере обуви и т. д. Проверку доступа на основе произвольных утверждений называют управлением доступом на основе утверждений (CBAC) или авторизацией на основе утверждений. Этот тип авторизации описывается в разделе "Управление доступом на основе утверждений" этой статьи.
Проверки авторизации выполняются на стороне приложения, а не на стороне ACS. ACS служит службой маркеров безопасности (STS), которая выдает маркеры, которые несут утверждения приложению. Маркеры обогащены утверждениями поставщиками удостоверений и при необходимости самим ACS, используя его обработчик правил. Когда приложение получает токен с утверждениями, оно может проанализировать его, извлечь нужные утверждения и принять решение об авторизации, используя RBAC или CBAC. WIF используется для синтаксического анализа токена и его обработки при принятии решений об авторизации с помощью простого интерфейса API. Дополнительные сведения о WIF см. в пакете SDK WIF (https://go.microsoft.com/fwlink/?LinkID=187481). При рассмотрении авторизации в приложениях и службах с поддержкой утверждений обращайтесь к следующей схеме. Обратите внимание, что после успешной проверки подлинности поставщик удостоверений создает токен (токен IdP на схеме). Маркер поставщика удостоверений можно преобразовать с помощью обработчика правил ACS. ACS может добавлять, удалять или изменять утверждения, поступающие в маркер, который выдает поставщик удостоверений. Наконец, маркер, выданный ACS, отправляется в приложение и обрабатывается WIF. Проверка доступа выполняется в WIF с использованием RBAC или CBAC.
.gif "ACS v2 WIF Authorization")
Управление доступом на основе ролей
RBAC — это подход к авторизации, согласно которому управление и внедрение пользовательских разрешений осуществляется приложением на основе ролей пользователя. При наличии у пользователя необходимой роли для выполнения того или иного действия ему предоставляется доступ; в противном случае доступ не предоставляется.
Метод IPrincipal.IsInRole
Для реализации RBAC в приложениях с поддержкой утверждений используйте метод IsInRole() интерфейса IPrinicpal, как и в других приложениях. Метод IsInRole() можно использовать несколькими способами:
Явный вызов в IPrincipal.IsInRole(“Administrator”). При использовании данного подхода на выходе получится логическое значение. Используйте его в условных операторах. Его можно произвольно применить в любом сегменте кода.
Использование требования безопасности PrincipalPermission.Demand(). При использовании этого подхода результатом будет исключение, если требование не удовлетворено. Оно должно соответствовать вашей стратегии обработки исключений. Вызов исключение обходится намного дороже с точки зрения производительности по сравнению с логическим значением. Такой результат можно применить в любом сегменте кода.
Использование декларативных атрибутов [PrincipalPermission(SecurityAction.Demand, Role = “Administrator”)]. Такой подход называется "декларативным", поскольку он используется для декларации методов. Его нельзя использовать в блоках кода в реализациях метода. Результатом будет исключение, если требование не удовлетворено. Необходимо убедиться, что оно соответствует вашей стратегии обработки исключений.
Использование авторизации URL-адреса с помощью <раздела авторизации> в web.config. Этот подход подходит при управлении авторизацией на уровне URL-адреса. Это наименее детализированный уровень из указанных выше. Преимущество такого подхода состоит в том, что изменения вносятся в файл конфигурации, а следовательно, код не требуется компилировать, чтобы применить изменение.
Представление ролей как утверждений
При вызове метода IsInRole() выполняется проверка наличия у текущего пользователя данной роли. В приложениях, поддерживающих утверждения, эта роль выражается типом утверждения роли, который должен быть доступен в токене. Тип утверждения роли выражается при помощи следующего URI:
https://schemas.microsoft.com/ws/2008/06/identity/claims/role
Существует несколько способов добавления типа утверждения роли в токен:
С помощью обработчика правил ACS создается правило с помощью портала управления ACS или службы управления ACS для создания правил преобразования утверждений, которые создают утверждения определенного типа роли. Дополнительные сведения о правилах и преобразовании маркеров см. в разделе "Группы правил" и "Практическое руководство. Реализация логики преобразования маркеров с помощью правил".
Преобразование произвольных утверждений в тип роли утверждений с помощью ClaimsAuthenticationManager — это реализуется с помощью ClaimsAuthenticationManager, компонента WIF. Он предоставляет возможность перехватывать запросы, когда они запускают приложения, проверяя токены и преобразуя их путем добавления, изменения или удаления утверждений. Дополнительные сведения об использовании ClaimsAuthenticationManager для преобразования утверждений см. в статье "Практическое руководство. Реализация контроль доступа на основе ролей (RBAC) в приложении с поддержкой утверждений ASP.NET с помощью WIF и ACS
Сопоставление произвольных утверждений с типом роли с помощью раздела конфигурации samlSecurityTokenRequirement — декларативный подход, при использовании которого утверждения преобразуются только с помощью конфигурации (без кода).
Управление доступом на основе утверждений
CBAC — это способ авторизации, при котором решение о предоставлении доступа основывается на произвольной логике, использующей данные, доступные в утверждениях. Помните, что в случае RBAC единственным используемым утверждением являлось утверждение типа роли. Утверждение типа роли использовалось для проверки принадлежности пользователя к определенной роли. Ниже представлен пример процесса принятия системой авторизации решения на основе утверждений:
Приложение получает запрос.
Оно извлекает входящие утверждения.
Приложение передает утверждения в механизм логики принятия решений. Это может быть код в памяти или вызов веб-службы, запрос базы данных или вызов сложного модуля правил.
Механизм принятия решения вычисляет результат на основе утверждений.
Доступ предоставляется, если результат имеет значение true, и не предоставляется, если результат имеет значение false. Например, правило может быть таким, что пользователь в возрасте 21 лет или выше, живет в штате Вашингтон и прошел проверку подлинности с помощью Windows Live ID (учетная запись Майкрософт).
ACS служит службой маркеров безопасности, которая выдает маркеры, которые несут утверждения. Вы можете контролировать, какие утверждения выдаются ( как типы утверждений, так и значения) с помощью обработчика правил ACS. Дополнительные сведения о обработчике правил ACS см. в разделе "Группы правил" и "Практическое руководство. Реализация логики преобразования маркеров с помощью правил". ClaimsAuthorizationManager — ключевой компонент для реализации CBAC в приложениях с поддержкой утверждений. ClaimsAuthorizationManager поставляется как часть WIF. ClaimsAuthorizationManager позволяет перехватывать входящие запросы и реализовать любую логику на усмотрение разработчика для принятия решений об авторизации на основе входящих утверждений. С помощью этого компонента вы также можете вынести решения об авторизации из кода приложения. Такая возможность приобретает существенное значение, если логику авторизации требуется изменить. В этом случае использование ClaimsAuthorizationManager не влияет на целостность приложения, благодаря чему уменьшается вероятность возникновения ошибки приложения в результате изменения. Дополнительные сведения об использовании ClaimsAuthorizationManager для реализации управления доступом на основе утверждений см. в статье "Практическое руководство. Реализация авторизации утверждений в приложении с поддержкой утверждений ASP.NET с помощью WIF и ACS".