В этом сценарии описывается использование единого входа в систему для сотрудника организации-партнера, когда он пытается получить доступ к ресурсам из домена другого партнера. В сценарии федерации задействованы три основных участника: поставщик удостоверений, поставщик утверждений и проверяющая сторона. Windows® Identity Foundation (WIF) предлагает API-интерфейсы для создания всех трех участников.

Приведенная ниже диаграмма иллюстрирует типичный сценарий федерации, в котором сотрудник Fabrikam хочет получить доступ к ресурсам Contoso.com без необходимости выполнять повторный вход, то есть используя единый вход в систему.

В сценарии участвуют следующие вымышленные пользователи:

  • Фрэнк: сотрудник Fabrikam, которому требуется доступ к ресурсам Contoso.

  • Дмитрий: разработчик приложения Contoso, вносящий в него необходимые изменения.

  • Андрей: системный администратор компании Contoso.

Компоненты, задействованные в сценарии:

  • web1: заказывающее части веб-приложение, которое создано с ASP.NET и контролирует доступ к соответствующим частям.

  • sts1: служба STS, выполняющая функции поставщика утверждений в Contoso.com и выдающая утверждения, которые необходимы приложению (web1). Она установила отношения доверия с Fabrikam.com и настроена на разрешение доступа для сотрудников Fabrikam.

  • sts2: служба STS, выполняющая функции поставщика удостоверений в Fabrikam.com и предоставляющая конечную точку, которая используется для проверки подлинности сотрудника Fabrikam. Эта служба установила отношения доверия с Contoso.com, чтобы сотрудникам Fabrikam был разрешен доступ к ресурсам Contoso.com.

Как показано на предыдущей диаграмме, в данном сценарии используется следующий поток.

  1. Администратор Contoso Адам настраивает отношения доверия между приложением проверяющей стороны и sts1.

  2. Администратор Contoso Адам настраивает отношения доверия с sts2 и поставщиком удостоверений.

  3. Администратор Fabrikam Фрэнк настраивает отношения доверия с sts1 как с поставщиком утверждений и затем получает доступ к приложению.

Основные этапы сценария

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

Настройка поставщика утверждений

Для администратора Contoso.com, Адама, существует три возможности:

  1. Установить продукт STS, например Службы федерации Active Directory® (AD FS) 2.0.

  2. Подписаться на веб-службу STS, такую как LiveID STS.

  3. Создать пользовательскую службу STS с использованием WIF.

Выбор варианта зависит от нескольких факторов, таких как потребности бизнеса, временная шкала, доступность технических ресурсов, выделенный бюджет и т. д. В этом сценарии предполагается, что Адам выбирает первый вариант и устанавливает Службы федерации Active Directory 2.0 в качестве службы RP-STS, используя документацию по продукту Службы федерации Active Directory 2.0.

Как сделать приложение поддерживающим утверждения

Чтобы сделать web1 приложением, поддерживающим утверждения, Даниэль устанавливает WIF и затем добавляет следующий код для перечисления утверждений. Дополнительные сведения см. в разделах FedUtil — служебная программа федерации для установления отношения доверия между проверяющей стороной и службой STS, Шаблоны Visual Studio и Создание приложений проверяющей стороны.

  Копировать код 
// Get the access to IClaimsIdentity IClaimsIdentity claimsIdentity = ((IClaimsPrincipal)Thread.CurrentPrincipal).Identities[0];

foreach ( Claim claim in claimsIdentity.Claims ) { // Before using the claims validate that this is an expected claim. // If it is not in the expected claims list then ignore the claim. if ( ExpectedClaims.Contains( claim.ClaimType ) ) { // Write out the claim or use the claim as needed by application logic WriteClaim( claim, table ); } }

Установление отношений доверия между приложением проверяющей стороны и STS

С помощью средства FedUtil — служебная программа федерации для установления отношения доверия между проверяющей стороной и службой STS Даниэль устанавливает отношения доверия между приложением проверяющей стороны и STS. Это средство также создает метаданные для приложения проверяющей стороны и помещает XML-файл (metadata.xml) в папку приложения проверяющей стороны. Файл web.config приложения проверяющей стороны автоматически обновляется информацией о STS (sts1).

Настройка приложения проверяющей стороны в организации поставщика утверждений.

После ознакомления с документацией по продукту Службы федерации Active Directory 2.0 Адам устанавливает отношения доверия с приложением проверяющей стороны.

Настройка поставщика удостоверений (IP) в Fabrikam

Для администратора Fabrikam.com, Владимира, возможно три варианта действий:

  1. Приобрести и установить службу STS, такую как Службы федерации Active Directory 2.0.

  2. Подписаться на веб-службу STS, такую как LiveID STS.

  3. Создать пользовательскую службу STS с использованием WIF.

В данном сценарии предполагается, что Владимир выбрал первый вариант и установил в качестве службы STS и поставщика удостоверений службу Службы федерации Active Directory 2.0. После ознакомления с документацией по продукту Службы федерации Active Directory 2.0 Фрэнк также устанавливает отношения доверия с Contoso.com как с поставщиком удостоверений.

Доступ к веб-приложению

Фрэнк входит в систему Fabrikam как пользователь домена Fabrikam. Затем от открывает браузер и переходит на страницу приложения проверяющей стороны Contoso.com. Поскольку между Fabrikam и Contoso установлены отношения доверия федерации, Фрэнк может теперь получать доступ к ресурсам в Contoso, не проходя повторно проверку подлинности.

Примеры ресурсов

См. также следующие примеры сценариев:

  • Полностью\Федерация для веб-служб (активный случай).

  • Полностью\Федерация для веб-приложения (пассивный случай).

Обратите внимание, что данные примеры подразумевают работу в одной системе с пользовательскими службами STS и проверяющей стороной.