Принятие авторизации на основе утверждений и федеративной модели безопасности позитивно отражается на приложениях WCF и ASP.NET по многим причинам. При организации безопасности на основе утверждений приложения отделяются от режима проверки подлинности; в результате такие обстоятельства, как изменение требований к учетным данным или поддержка новых типов, не отражаются на приложениях. И что важнее всего — авторизация на основе утверждений поддерживает федеративные модели безопасности. Наиболее важное предлагаемое преимущество модели федеративной безопасности состоит в том, что приложения могут предоставлять доступ пользователям, которые прошли процедуру аутентификации в другом домене. В результате сокращаются непроизводительные расходы в сфере ИТ, связанные с подготовкой и отзывом пользователей, снижается вероятность ошибок, проистекающих из управления повторяющимися учетными записями в различных приложениях и доменах, и открывается возможность безопасного установления доверительных отношений между приложениями, департаментами или даже между корпорациями.

Работая над статьей, я исходила из того, что читателям известно, в чем состоят преимущества от использования рассматриваемых технологий. Далее я кратко опишу концепцию федеративной безопасности, а за этим последует экспресс-обзор средств WIF для WCF и ASP.NET. Я подробно расскажу об участниках и о потоке коммуникации как для активного, так и для пассивного федерирования, разъясняя при этом базовые требования к каждому из сценариев с WIF. Кроме того, в общих чертах будет представлен процесс построения активной или пассивной службы маркеров безопасности Security Token Service (STS) с WIF.

Азы федеративной безопасности

Начнем с краткого введения в тему «федеративная безо­пасность». На рисунке 1 представлен сценарий федеративной безопасности, а также участники в самом общем виде.

Рисунок 1. Участники федерации и поток коммуникаций

  • Субъектом является сторона, которой будет предоставлен доступ к приложению. Как правило, это конечный пользователь, взаимодействующий с клиентским приложением или с веб-приложением через браузер.
  • Инициатором запроса является агент (клиентское приложение или браузер), запрашивающий маркер безопасности с описанием субъекта.
  • Проверяющей стороной Relying Party (RP) может быть веб-приложение (ASP.NET) или служба, которая подтверждает доступ к средствам и функциональным возможностям на основе утверждений, изложенных в маркере безопасности. Этот маркер должен быть выдан доверенным издателем маркеров.
  • Задача проверки прав доступа возлагается на провайдера удостоверений Identity Provider (IdP). Из этого следует, что в домене провайдера (скажем, в каталоге Active Directory или в специализированной базе данных учетных данных) имеется хранилище учетных данных.
  • Служба STS ответственна за выдачу субъекту маркера безопасности. Если STS размещена в провайдере удостоверений (IdP), она, вероятно, выдаст маркер безопасности, содержащий идентификационные утверждения для субъекта. STS может также предоставлять и иные утверждения, имеющие отношение к авторизации у проверяющей стороны.
  • В разных сценариях могут использоваться разные форматы маркеров безопасности; однако стоит отметить, что весьма популярным форматом маркеров при использовании федеративной модели является язык Security Assertion Markup Language (SAML). SAML — это совместимый формат маркеров безопасности на базе языка XML. Он позволяет транспортировать утверждения SAML: выпускающая служба STS подписывает маркер и, как правило, зашифровывает его для передачи проверяющей стороне.

Между проверяющей стороной и STS должны быть установлены доверительные отношения. Если служба STS не имеет сведений о той или иной проверяющей стороне, она не будет выдавать для нее маркеры. В свою очередь, проверяющая сторона не принимает маркеры от службы STS, которой она не доверяет. Проверяющая сторона указывает на необходимые для успешной аутентификации утверждения; инициатор запроса обращается к STS, запрашивая для субъекта маркер безопасности, в котором передаются требования проверяющей стороны и учетные данные для субъекта; STS (в провайдере удостоверений) проверяет подлинность субъекта, собирает утверждения по идентичности, а также иные относящиеся к делу утверждения и выдает маркер безопасности, содержащий эти утверждения. Запросившая сторона передает маркер проверяющей стороне для осуществления авторизации; проверяющая сторона удостоверяется в том, что маркер поступил от доверенного издателя, и предоставляет права доступа в соответствии с полученными утверждениями.

Этот коммуникационный поток основывается на протоколе WS-Trust (см. docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html). Инициирующая сторона передает службе STS запрос маркера безопасности Request for Security Token (RST) в соответствии с данной спецификацией, и STS направляет ей в ответ Request for Security Token Response (RSTR). В спецификацию WS-Federation (см. документацию WS-Trust 1.3 OASIS Standard) входят два профиля для федерации с WS-Trust: Active Requestor Profile (сценарий с использованием клиента с расширенными возможностями и веб-службы) и Passive Requestor Profile (сценарий с использованием браузера и веб-приложения). С помощью приложения WIF, созданного посредством. NET Framework, вы можете реализовывать сценарии, основанные на этих протоколах.

Windows Identity Foundation

WIF — новая модель идентичности для платформы. NET Framework. Она предоставляет средства, необходимые для построения приложений и служб на основе утверждений, для поддержки сценариев активной и пассивной федеративной безопасности и для создания по мере необходимости специализированных реализаций STS. Кроме того, модель располагает встроенными средствами поддержки информационных карточек (для выполнения сценариев, связанных с применением Windows CardSpace). WIF позволяет реализовывать сценарии на основе утверждений и сценарии федеративной безопасности с использованием гораздо меньших объемов кода. Вот несколько примеров того, что можно сделать с помощью модели WIF (это далеко не полный список).

  • Заменять классические механизмы безопасности WCF новым, более гибким механизмом вызовов аутентификации и авторизации. Это можно делать даже в тех случаях, когда модель федеративной безопасности не применяется.
  • Создавать для служб WCF модель безопасности на основе утверждений, которая хорошо интегрируется с классическими методами обеспечения безопасности. NET Framework на основе ролей.
  • Подобным же образом реализовывать на основе утверждений приложения ASP.NET, позволяющие задействовать классические приемы обеспечения безопасности на основе ролей, включая существующие элементы управления доступом ASP.NET.
  • Поддерживать пассивную федеративную систему в приложениях ASP.NET.
  • Реализовывать специализированную службу STS, соответствующую требованиям, которым не удовлетворяет существующая платформа STS, таким как Active Directory Federation Services (ADFS). Построение полнофункциональной специализированной STS связано с проведением больших объемов работ и потому должно рассматриваться как последнее средство.
  • Выпускать управляемые информационные карточки от STS для поддержки выбора идентичности с помощью CardSpace.
  • Поддерживать выбор информационных карточек с помощью приложений ASP. NET.

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

Активное федерирование с использованием WIF

Для осуществления активного федерирования необходимо иметь клиентское приложение (источник запроса), веб-службу (проверяющая сторона) и службу STS для выдачи маркеров (эта служба может быть частью провайдера удостоверения). На рисунке 2 представлен простой сценарий активной федерации с использованием одной службы STS. В данном случае служба WCF проверяющей стороны экспонирует федеративную конечную точку; STS экспонирует конечную точку WS-Trust; клиент использует посредник WCF для подтверждения прав доступа к конечной точке STS и запрашивает маркер безопасности, а затем передает этот маркер по первому вызову проверяющей стороне, с тем чтобы установить для пользователя защищенный сеанс связи.

Рисунок 2. Активная федерация с использованием WCF и WIF

Настройка WIF для службы WCF

Для создания службы WCF необходимо экспонировать федеративную конечную точку и настроить службу для использования WIF. В листинге 1 показана возможная конфигурация для службы RP Service, представленной на рисунке 2.

К федеративной конечной точке применяется стандарт связывания S2007 FederationHttpBinding, основанный на спецификации WS-Trust 1.3 (которая является новейшей версией стандарта). В настройках связывания указываются следующие данные:

  • какой формат маркера ожидается, в данном случае это SAML 1.1;
  • какие утверждения необходимы, в данном случае указывается утверждение простого имени;
  • где размещается конечная точка обмена метаданными доверенного издателя; данные необходимы для того, чтобы клиент мог сформировать федеративный proxy.

В дополнение к федеративной конечной точке служба настраивается для WIF с использованием функции . Данная функция устанавливает компоненты FederatedServiceCredentials и IdentityModelServiceAuthorizationManager взамен применяемых по умолчанию ServiceCredentials и ServiceAuthorizationManager. Эти компоненты WIF (наряду с прочими) обеспечивают новый механизм обработки поступающих маркеров безопасности и адресованных службе вызовов авторизации. Их функционирование определяется отдельным разделом настроек , который активирует среду WIF. В листинге 2 показаны главные параметры, которые необходимо указать для службы WCF.

В разделе приведен один доверенный сертификат, указанный по его отпечатку. Сертификат, соответствующий отпечатку, должен храниться в хранилище LocalMachine\TrustedPeople. В результате маркеры безопасности будут признаваться лишь в том случае, если они подписаны соответствующим закрытым ключом для того или иного сертификата; в данном сценарии это означает, что доверием пользуется лишь RP-STS (см. рисунок 2). По умолчанию в соответствии с настройками раздела предусматривается, что пользователь должен представить по меньшей мере один принятый идентификатор Uniform Resource Identifier (URI) аудитории. Как правило, маркеры SAML включают ограничение по аудитории, указывающее, для кого именно выдан маркер. Если эта функция отключена, входящий маркер будет действителен лишь в том случае, если он включает соответствующий URI из этого списка. Раздел указывает на сертификат, который следует использовать для расшифровки входящих маркеров в случае, если они зашифрованы. Таковы базовые параметры, которые следует вводить, дабы инициализировать WIF для службы RP. Наряду с этим имеется ряд других параметров модели идентичности, полезных для RP, и я буду рассказывать о них в следующих статьях.

Итак, мы получили службу WCF, готовую к использованию в федеративной модели. Клиент будет генерировать proxy WCF из метаданных службы, основанных на этой настройке, и должен будет представить соответствующие учетные данные ClientCredentials для подтверждения прав доступа к STS. Для реализации активной федеративной модели установка среды WIF на клиенте не требуется, хотя надо сказать, что в эту среду входит ряд весьма полезных компонентов, применяемых в определенных реализациях клиентов.

Теперь, когда служба готова к работе в составе федерации, возникает вопрос: как осуществить авторизацию для получения доступа к операциям и базовым функциям? Если службу интересует только одно обстоятельство, а именно есть ли у пользователя право доступа к STS, достаточно установить, что маркер безопасности выдан доверенным провайдером. Скорее всего, вы будете исходить из того, что STS выдает маркер с утверждениями, полезными для целей получения авторизации, такими как роли или разрешения. WIF присоединяет к каждому потоку запросов прошедшего процедуру аутентификации участника безопасности — в данном случае типа ClaimsPrincipal, который представляет собой оболочку для коллекции утверждений из выданного маркера безопасности. Как и любой тип участника безопасности, реализующий IPrincipal, ClaimsPrincipal экспонирует метод IsInRole (), который может быть использован для реализации управления доступом.

if (! Thread.CurrentPrincipal.
IsInRole ("Admin")) 
   throw new SecurityException ("Access is denied.");

Вы можете задействовать настройки модели идентичности для указания на то, какой тип утверждений представляет «роль» для вызовов IsInRole (), или написать код для проверки экземпляра ClaimsPrincipal на наличие определенного набора утверждений. Первая из моделей «чище», и для ее функционирования достаточно, чтобы с целью проверки доступа использовался только один тип утверждений.

Реализация активной STS с использованием WIF

В сценарии, представленном на рисунке 2, применяется специализированная STS, поэтому я кратко опишу, что нужно сделать для ее реализации. Впрочем, имейте в виду, что в этом сжатом описании для краткости я опускаю большое количество деталей. Весьма примитивную службу STS можно реализовать следующим образом.

  • Создайте подкласс на основе типа SecurityTokenService и выполните переопределение для GetScope () и GetOutputClaimsIdentity ().
  • С помощью одного из контрактов WS-Trust, реализованного в базовом типе STS, создайте конечную точку WCF для службы STS.

В листинге 3 представлена простая реализация службы STS. Переопределение GetScope () обеспечивает проверку запроса на предназначение для отправки доверенной проверяющей стороне. При успешном прохождении проверки сертификат будет представлен для подписи маркера (в данном случае это закрытый ключ STS), и сертификат будет использоваться для шифрования маркера (служба STS должна получить сертификат RP из доверенного источника).

Переопределению для GetOutputClaimsIdentity () предоставляется доступ к участнику безопасности на основе IClaimsPrincipal. Этот тип содержит утверждения, касающиеся пользователя, прошедшего проверку подлинности; в данном случае они базируются на учетных данных пользователя, применяемых в системе Windows. Перед выпуском маркера обычно осуществляется конвертация этих утверждений в понятный набор утверждений для проверяющей стороны. Для этого нужно инициализировать новый экземпляр ClaimsIdentity. В данном примере хранилище учетных данных возвращает соответственные утверждения, касающиеся прошедшего аутентификацию пользователя. Для исследования дополнительных деталей вам следует рассмотреть образец кода, но, в сущности, изложенным выше исчерпываются главные аспекты простой реализации службы STS.

Представленная в листинге 4 настройка модели службы показывает, как демонстрационная STS из рисунка 2 экспонирует конечный пункт WS-Trust 1.3 с помощью синхронной версии контракта: IWSTrust13 SyncContract. Связывание основывается на принимаемых по умолчанию параметрах WS2007 HttpBinding; это означает, что для аутентификации вызовов службе STS требуются учетные данные Windows. В данном примере будет достаточно модели идентичности, принимаемой по умолчанию, — например, нет необходимости переопределять процедуру обработки входящих учетных данных.

Пассивное федерирование с использованием WIF

Для осуществления пассивного федерирования требуется браузер (запрашивающая сторона), веб-приложение (проверяющая сторона) и пассивная служба STS для выпуска маркеров. На рисунке 3 представлен простой сценарий пассивной федерации, где проверяющей стороной является приложение ASP.NET, предназначенное для реализации пассивной федерации, и специализированная STS, тоже пассивная — в том смысле, что она базируется на браузере, а не является реализацией службы на базе WCF. Когда пользователь ищет проверяющую сторону, он перенаправляется для аутентификации на STS, а затем, после получения маркера, вновь направляется на проверяющую сторону. В этот момент устанавливается сеанс безопасной связи и генерируется cookie-файл сеанса.

Рисунок 3. Пассивная федерация с использованием ASP.NET и WIF

Пассивная федерация все еще связана с передачей сообщений по протоколу WS-Trust в форме RST и RSTR; в последнем случае применяется выданный маркер безопасности. Различие состоит в том, что они передаются как строки запроса и параметры формы, а не сообщения по протоколу Simple Object Access Protocol (SOAP). В следующих разделах речь пойдет о том, как настраиваются приложения ASP.NET, а также о пассивных реализациях STS.

Включение пассивной федерации для ASP.NET

Среда WIF включает в себя два модуля HTTP для поддержки пассивной федерации: WSFederationAuthenticationModule (FAM) и SessionAuthenticationModule. Модуль FAM отвечает за перенаправление с проверяющей стороны на STS и осуществляет обработку RSTR с целью извлечения маркера безопасности, а также установления ClaimsPrincipal для потока запросов. SessionAuthenticationModule управляет сеансом аутентификации: генерирует маркер безопасности сеанса, который содержит ClaimsPrincipal; записывает его в cookie-файл; управляет временем жизни cookie-файла сеанса и восстанавливает ClaimsPrincipal из cookie-файла, когда он есть. С целью подключения этих двух модулей добавьте показанный в листинге 5 код к разделу (для Microsoft IIS 6.x) и к разделу (для IIS 7).

Чтобы обеспечить возможность обработки запросов с помощью модуля FAM, необходимо для режима аутентификации выбрать параметр None и заблокировать доступ к узлу анонимных пользователей:

Кроме того, модуль FAM инициализируется посредством настройки модели идентичности. Вы должны указать по меньшей мере следующие параметры: список доверенных издателей сертификатов, идентификаторы URI уполномоченной аудитории, типы утверждений, необходимых для авторизации и конфигурацию для пассивной федерации. Первые три из них функционируют таким же образом, как и в активной федерации, тогда как настройка для пассивной федерации применяется лишь в сценариях ASP.NET. В листинге 6 представлен пример настройки модели идентификации для пассивного узла.

В разделе нужно включить функцию пассивного перенаправления, чтобы организовать пассивную федерацию для приложения ASP.NET. В результате модулю FAM будет предписано осуществлять процесс обработки поступающих на узел запросов и перенаправлять в службу STS все вызовы, не прошедшие процедуру аутентификации. Параметр «издатель» указывает на STS, куда следует перенаправлять вызовы. Область определения настроек фактически указывает издателю (как части RST), для кого будет выдан маркер, и эти данные должны соответствовать одному из кодов URI для соответствующей аудитории. Когда RSTR возвращается приложению, модуль FAM обрабатывает этот ответ и формирует ClaimsPrincipal для потока запросов.

И вновь ClaimsPrincipal оказывается полезным для управления доступом. При использовании приложений ASP.NET флажок IsInRole () полезен не только для динамических проверок; помимо прочего, этот метод инкапсулируется в большинстве элементов управления доступом. Вероятно, если вы сможете выбрать тот или иной тип утверждения в качестве «ролевого» типа утверждения (это настраиваемый параметр), у вас появится возможность продолжать реализацию безопасности на основе ролей с помощью привычных приемов; правда, нужно иметь в виду, что ролевая проверка превращается в проверку утверждений.

Реализация пассивной STS в среде WIF

В среде WIF пассивная STS может быть реализована двумя способами: с помощью элемента управления доступом FederatedPassiveTokenService (управляющий элемент STS) или при помощи модуля FAM с использованием дополнительного специального кода. Для простоты я остановлюсь на реализации с помощью управляющих элементов. Архитектура данной реализации представлена на рисунке 4 (будем исходить из того, что перед выпуском маркеров вы проверяете подлинность пользователей методом аутентификации с помощью форм).

Рисунок 4. Пассивная STS, реализованная с помощью элемента управления FederatedPassiveTokenService

Когда модуль FAM перенаправляет на STS вызов, поступивший проверяющей стороне, вместе с запросом передается и запрос маркера безопасности. В данном случае FormsAuthenticationModule перенаправит вызов на страницу регистрации, передавая исходный запрос в строке запроса ReturnUrl. В обратном послании страницы регистрации пользователь аутентифицируется (с помощью модели провайдера ASP.NET или специального кода), затем перенаправляется на ReturnUrl, который представляет собой исходный RST, и, вероятно, попадает на страницу, содержащую элемент управления STS.

Элемент управления STS обрабатывает входящие запросы RST до загрузки страницы (на этапе PreRender). Элемент управления связан со специализированной реализацией STS. Эта реализация STS программно предписывает модулю FAM сформировать ClaimsPrincipal для прошедшего аутентификацию пользователя, после чего вызываются те же переопределения для GetScope () и GetOutputClaimsIdentity (); последнее из них вновь отвечает за то, чтобы реальные утверждения были выпущены и включены в маркер безопасности. После этого элемент управления перенаправляет вызов обратно проверяющей стороне (URL, указывающий, куда следует адресовать ответ, содержится в RST), передавая RSTR в форме параметра POST. В этот момент модуль FAM обрабатывает RSTR на проверяющей стороне и устанавливает ClaimsPrincipal в поток запросов для авторизации.

Метод, предполагающий использование этого управляющего элемента, отличается изяществом; в данном случае требуется весьма малый объем кода — только код специализированной STS, как отмечалось выше. Разумеется, у него есть недостаток: значительная часть механизма пассивной федерации не поддается настройке, если не считать возможности осуществления нескольких простых переопределений до и после обработки RST. В следующих статьях я рассмотрю несколько более сложных сценариев, предполагающих индивидуализацию кода.

Продолжение следует

Надеюсь, вы с интересом ознакомились с этим экспресс-обзором модели федеративной безопасности и WIF, в котором я заложила основу для предстоящих статей. Если вам требуется более фундаментальное введение в платформу WIF, загрузите руководство по WIF на сайте MSDN, где представлены дополнительные средства WIF. Кроме того, описанию достоинств модели безопасности на базе утверждений и федеративной безопасности я посвятила часть своей книги Claims-Based WPF, которую можно найти в Интернете по адресу claimsbasedwpf.codeplex.com.

Мишель Бустаманте (mlb@idesign.net) — главный архитектор компании IDesign, региональный директор Microsoft в Сан-Диего и обладатель сертификата Microsoft MVP for Connected Systems. Ведет блог по адресу www.dasblonde.net

Листинг 1. Настройки модели службы для экспонирования федеративной конечной точки с?активированной средой WIF 

  
    
      
    
  
  
    
      
        
    
            
              
            
            
          
        
      
    
  
  
    
      
  
      
    
 
Листинг 2. Образец настройки модели идентичности для службы WCF 

  
    
      
        
      
    
    
      
    
    
      
    
  
Листинг 3. Реализация активной службы STS для образца 
public class RPSTS : SecurityTokenService
{
    public RPSTS(SecurityTokenServiceConfiguration config)
        : base( config )
    {}

   protected override Scope  GetScope(IClaimsPrincipal principal,
   RequestSecurityToken request)
   {

    Scope scope = new Scope(request.AppliesTo.Uri.AbsoluteUri);
    scope.EncryptingCredentials = this.GetCredentialsForAppliesTo
    (request.AppliesTo);
    scope.SigningCredentials = new X509SigningCredentials
    (CertificateUtil.GetCertificate(StoreName.My,
StoreLocation.LocalMachine, "CN=RPSTS"));

    return scope;
   }

    protected override IClaimsIdentity GetOutputClaimsIdentity
    (IClaimsPrincipal principal,
RequestSecurityToken request, Scope scope)
   {
    IClaimsIdentity claimsIdentity = new ClaimsIdentity();
    claimsIdentity.Claims.AddRange(
CredentialStore.GetClaimsForUser(principal.Identity.Name));

    return claimsIdentity;
   }

   // other supporting methods
}
Листинг 4. Конфигурация простой конечной точки WS-Trust 

  
    
      
      
    
  
  
    
      
        
      
     
 
Листинг 5. Код, подключающий модули WIF HTTP для пассивной федерации 

     
Листинг 6. Пример конфигурации модели идентичности для приложения ASP.NET