Позволяет ли SAML 2.0 отправлять данные SP в IdP?

Question

Я читаю спецификацию SAML и экспериментирую с Keycloak и Shibboleth IdP, и я не уверен, как реализовать одну функцию в SP-инициированном входе в систему.

У меня есть служба, которая традиционно использовала для отображения информации о состоянии SP на своей странице входа в систему (например, версия приложения, статус). После перехода на страницу входа в IdP я бы хотел отображать такую ​​дополнительную информацию для каждого SP на странице входа в IdP. Я заинтересован в обмене данными, а не в создании шаблонов самой страницы входа.

Позволяет ли спецификация SAML 2.0 отправлять произвольные данные в IdP для входа в систему? Если нет, какие еще варианты можно использовать для оформления страницы входа IdP с использованием данных, созданных SP?

Answer 1

Вроде. Запрос аутентификации от SP к IdP может иметь «пользовательские» расширения (родительский элемент Extensions), содержание расширений зависит от вас. Из спецификации:

[Необязательно] Эта точка расширения содержит необязательные элементы расширения сообщения протокола, которые согласованы между общающиеся стороны. Схема расширения не требуется для того, чтобы использовать эту точку расширения, и даже если она предоставлена, слабый настройка проверки не накладывает требования на расширение быть действительным. Элементы расширения SAML ДОЛЖНЫ быть квалифицированы в пространстве имен в пространство имен, не определенное SAML.

Если вы пишете свой собственный IdP, вы, безусловно, можете использовать расширения и делать с ними все, что пожелаете. «Стандартные» (коммерческие / OSS) IdP не будут знать, что делать с вашим расширением. Было бы интересно проверить, анализируют ли библиотеки Shibboleth или Keycloak элемент Extensions и выдают его содержимое.

Другая, более стандартная возможность - использование RelayState. Это совместимый со спецификацией способ передачи информации о состоянии конкретного провайдера, в т.ч. от SP до IdP:

3.1.1 Использование RelayState Некоторые привязки определяют механизм «RelayState» для сохранения и передачи информации о состоянии. Когда такой механизм используется при передаче сообщения запроса в качестве начального шага SAML протокол, он предъявляет требования к выбору и использованию связывание впоследствии используется для передачи ответа. А именно, если SAML сообщение запроса сопровождается данными RelayState, затем SAML ответчик ДОЛЖЕН вернуть свой ответ протокола SAML, используя привязку, которая также поддерживает механизм RelayState, и он ДОЛЖЕН поместить точное Данные RelayState, полученные с запросом в соответствующие Параметр RelayState в ответе.

Опять же, все IdP или библиотеки downstack будут анализировать RelayState, но от того, как они справятся с этим, зависит их чтение спецификации. Во-первых, спецификация требует, чтобы RelayState составлял 80 байтов, и защита целостности посредством подписи или «другими средствами». Это ограничение часто игнорируется IdP и SP.

Какую информацию о SP вы пытаетесь отобразить на странице входа в IdP?

Answer 2

Единственное, что SP может отправить в IdP, это Subject (см. строки 585-589 спецификации).