Поделиться через

Федерация

  • Статья

Федерация позволяет делегированию центра авторизации другим членам межпричин. Например, рассмотрим следующую бизнес-проблему: компания Contoso Ltd для производства автозачасти хотела бы разрешить авторизованным сотрудникам клиента Fabrikam Inc безопасно получить доступ к частям компании Contoso заказа веб-службы. Одним из решений безопасности для этого сценария является настройка механизма доверия с Fabrikam для делегирования решения о авторизации доступа в Fabrikam. Этот процесс может работать следующим образом:

  • Fabrikam, когда он становится партнером Contoso, настраивает соглашение доверия с Contoso. Цель этого шага — согласиться с типом маркера безопасности и содержимым, которые будут представлять авторизацию Fabrikam и будут приемлемы для Contoso. Например, может быть решено, что доверенный сертификат X.509 с именем субъекта CN=Fabrikam Inc Supplier STS должен подписать токен SAML для этого SAML, который будет принят веб-службой Contoso. Кроме того, может быть решено, что утверждение безопасности в выданном токене SAML должно иметь значение "https://schemas.contoso.com/claims/lookup" (для авторизации подстановки части) или "https://schemas.contoso.com/claims/order" (для авторизации заказа частей).
  • Когда сотрудник Fabrikam использует внутреннее приложение для упорядочивания частей, он сначала обращается к службе маркеров безопасности (STS) внутри Fabrikam. Этот сотрудник проходит проверку подлинности с помощью внутреннего механизма безопасности Fabrikam (например, имени пользователя домена Windows или пароля), его авторизация для заказа частей проверяется, и он выдается короткий токен SAML, содержащий соответствующие утверждения и подписанный сертификатом X.509, описанным выше. Затем приложение заказа частей связывается со службой Contoso, представляющей выданный токен SAML для проверки подлинности и выполнения задачи упорядочивания.

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

Функции федерации

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

  • На стороне клиента: для получения маркера безопасности из службы безопасности можно использовать функцию WsRequestSecurityToken. Кроме того, можно использовать библиотеку поставщика маркеров безопасности на стороне клиента, например CardSpace или LiveID, а затем использовать их выходные данные для локального создания маркера безопасности с помощью WsCreateXmlSecurityToken. В любом случае после того, как клиент имеет маркер безопасности, он может затем создать канал в службу, указав WS_XML_TOKEN_MESSAGE_SECURITY_BINDING представить маркер вместе с привязкой безопасности транспорта, например WS_SSL_TRANSPORT_SECURITY_BINDING для защиты канала.
  • Сервер. В сценарии федерации со службой маркеров безопасности, которая выдает токены SAML, сервер может использовать WS_SAML_MESSAGE_SECURITY_BINDINGвместе с привязкой безопасности транспорта, например WS_SSL_TRANSPORT_SECURITY_BINDING для защиты канала.
  • StS-side. Обратите внимание, что служба STS является приложением веб-службы, и она может указать требования к безопасности для тех, кто запрашивает маркер безопасности из него, используя описание безопасности структуру во время создания прослушивателя так же, как и любой другой безопасной веб-службы. Затем он может проанализировать полезные данные входящих сообщений запроса, чтобы проверить запросы маркеров и отправить обратно выданные маркеры в виде полезных данных сообщения ответа. В настоящее время никакие функции не предоставляются, чтобы помочь в анализе и выполнении шагов.

Обратите внимание, что клиентская сторона может обрабатывать выданный маркер безопасности в качестве маркера безопасности XML, не зная тип токена или выполняя обработку конкретного типа маркера. Однако сервер должен понять конкретный тип маркера безопасности, чтобы понять и обработать его. Шаги запроса и ответа маркера безопасности используют конструкции, определенные в спецификации WS-Trust.

Более сложные сценарии федерации

Сценарий федерации может включать несколько stS, которые образуют цепочку федерации. Рассмотрим следующий пример:

  • Клиент выполняет проверку подлинности в stS LiveID с помощью имени пользователя или пароля LiveID и получает маркер безопасности T1.
  • Клиент проходит проверку подлинности в STS1 с помощью T1 и получает маркер безопасности T2.
  • Клиент проходит проверку подлинности в STS2 с помощью T2 и получает маркер безопасности T3.
  • Клиент проходит проверку подлинности в целевой службе S с помощью T3.

Здесь liveID STS, STS1, STS2 и S образуют цепочку федерации. Службы STS в цепочке федерации могут выполнять различные роли для общего сценария приложения. Примерами таких функциональных ролей STS являются поставщик удостоверений, средство принятия решений по авторизации, анонимизатор и диспетчер ресурсов.

Параметры запроса STS и обмен метаданными

Чтобы клиент успешно вызов WsRequestSecurityToken, необходимо знать параметры этого вызова (например, необходимые типы маркеров и типы утверждений), описание безопасности требований канала запроса к STS, а также адрес конечной точки stS. Клиентское приложение может использовать любой из следующих методов для определения этих сведений:

  • Жесткий код информации в приложении в рамках решений времени разработки.
  • Ознакомьтесь с этой информацией из файла конфигурации уровня приложения, настроенного локальным развертыванием приложений.
  • Динамически обнаруживайте эти сведения во время выполнения с помощью функции импорта метаданных со структурой WS_ISSUED_TOKEN_MESSAGE_SECURITY_BINDING_CONSTRAINT.

Чтобы проиллюстрировать использование динамического MEX с федерацией, рассмотрим приведенный выше пример 3 STS. Клиент сначала сделает динамический MEX с S для получения сведений о T3 (т. е. о том, что запрашивать от STS2), а также динамический MEX-адрес STS2 (т. е. где найти STS2). Затем эта информация будет использоваться для выполнения динамического MEX с STS2 для обнаружения сведений о T2 и STS1 и т. д.

Таким образом, динамическая процедура MEX выполняется в порядке 4, 3, 2, 1, чтобы создать цепочку федерации, а также выполнить действия по запросу токена и презентации в порядке 1, 2, 3, 4 для очистки цепочки федерации.

Заметка

Windows 7 и Windows Server 2008 R2: WWSAPI поддерживает только Ws-Trust и Ws-SecureConversation, как определено профилем безопасности упрощенных веб-служб (LWSSP). Дополнительные сведения о реализации Корпорации Майкрософт см. в разделе Синтаксис MESSAGE LWSSP.