Повторное использование утверждения SAML

Question

Я реализую единый вход с несколькими SP. Вот мое основное понимание:

1) Браузер (Пользователь) запрашивает ресурс у поставщика услуг (SP).
2) Перенаправления SP (с запросом SAML) поставщику удостоверений (IdP).
3) Так как это первый логин, Пользователь дает (IdP) свои действительные учетные данные.
4) IdP затем перенаправляет браузер (с ответом SAML, который включает токен SAML) на страницу SP.

Теперь предположим, что у меня есть поставщик услуг A и поставщик услуг B. Пользователь выполнил шаг для поставщика услуг A. Из поставщика услуг A (salesforce.com в моем сценарии), я написал серверную сторону метод, который выдает выноску конечной точке поставщика услуг B. Возможно ли повторное использование утверждения SAML в этом случае? То есть будет ли провайдер услуг B доверять бэкэнд-методу?

Answer 1

Вам необходимо будет настроить Поставщика услуг B, чтобы он принял, понял и интерпретировал Assertion, полученный Провайдером A. Это, безусловно, не будет работать из коробки.

The SAML Assertion включен в SAML Response в Service Provider А содержат фрагменты данных, которые коррелируют с его оригинальной SAML Request и определяют получатель сообщения (например, с использованием элементов SubjectConfirmationData и Audience). Поставщику услуг B необходимо будет игнорировать значения в этих полях, так как на самом деле это не отступом получателя Assertion.

Проблема о том, как доверять брокеру между двумя машинами, где идентификация пользователя утверждается поставщиком идентификации, может быть решена несколькими стандартными подходами. Один из них - использовать Session Token Service (на основе WS-Trust), который определяет способ запроса и выдачи токенов сторонним службам. Другим является использование OAuth 2.0. Разумеется, вы также можете просто аутентифицировать поставщика услуг A поставщику услуг B с помощью специальной схемы с паролем, HMAC, ...

Answer 2

Короткий ответ - нет, если поставщик услуг B реализован как стандартный SAML 2.0 SP.

Утверждения SAML 2.0 являются «целевыми» и подписанными. У них есть определенная аудитория и URL-адрес получателя. Вы не можете изменить их, не нарушая подпись. Утверждение, полученное SP A, содержит имя SP A в качестве аудитории и конечную точку ACS SP A в качестве URL-адреса получателя. Такое утверждение не будет принято SP B.

Что мешает вам просто вызвать SP B стандартным способом и позволить ему инициировать собственный поток SAML 2.0? Другой вариант - выполнить инициированный IDP поток SSO для SP B. Однако не все реализации IDP поддерживают его.