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

Федерация

  • Статья

Федерация позволяет делегирование полномочий авторизации другим членам интерпрайза. Например, рассмотрим следующую бизнес-проблему: компания по производству автозапчастей Contoso Ltd хотела бы предоставить авторизованным сотрудникам своего клиента Fabrikam Inc безопасный доступ к веб-службе заказов деталей Contoso. Одним из решений безопасности для этого сценария является настройка 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 выступает в качестве "проверяющей стороны". Схема, показывающая выдающую и проверяющую стороны в федерации.

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

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

  • На стороне клиента. Для получения маркера безопасности из STS можно использовать функцию 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 для защиты канала.
  • На стороне службы маркеров безопасности. Обратите внимание, что служба маркеров безопасности является приложением веб-службы и может указывать требования к безопасности для тех, кто запрашивает у него маркер безопасности, используя структуру описания безопасности во время создания прослушивателя так же, как и любая другая безопасная веб-служба. Затем он может проанализировать полезные данные входящих сообщений запроса, чтобы проверить запросы маркеров и отправить обратно выданные маркеры в качестве полезных данных ответных сообщений. В настоящее время отсутствуют функции, которые помогут выполнить эти действия по синтаксическому анализу и выполнению.

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

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

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

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

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

Обмен параметрами запросов и метаданными службы маркеров безопасности

Чтобы клиент успешно вел вызов WsRequestSecurityToken , ему необходимо знать параметры этого вызова (например, требуемый тип маркера и типы утверждений), требования к описанию безопасности канала запросов к 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). Дополнительные сведения о реализации корпорации Майкрософт см. в разделе Синтаксис сообщения статьи LWSSP.