Как я должен реализовать привязку протокола HTTP POST для профиля SAML WebSSO?

Я реализовал свой Поставщик услуг и Идентификатор провайдера, следуя профилю SAML для веб-единого входа, используя HTTP POST Protocol Binding. Тем не менее, я немного смущен относительно того, как поставщик удостоверений предоставит <AuthnStatement>, если HTTP POST, исходящий от поставщика услуг, не привязан к сеансу в поставщике удостоверений.

Может ли кто-нибудь просветить меня, как можно это сделать?

Другим подходом, который я мог бы использовать, является переадресация HTTP-перенаправления, но для этого требуется вмешательство пользователя-агента (то есть браузер), часто используя User-Agent просто как посредник-посредник для упрощения обмена сообщениями Request-Response, Я предпочел бы использовать HTTP POST по этой причине, потому что обмен сообщениями происходит на стороне сервера, поэтому пользователь не видит ничего на экране.

Однако использование HTTP Redirect имеет больше смысла для меня в отношении того, как я смогу связать сеанс с запросом. Поскольку HTTP-перенаправление облегчается через User-Agent, запрос IdP будет иметь сеанс (если он был ранее аутентифицирован). Я не понимаю, как отправить <AuthnRequest> в HTTP-перенаправление. Отвечено на JST

Итак, я немного смущен и хотел бы услышать, что делают другие люди. Вот еще мои вопросы:

  • Используя привязку протокола HTTP POST с опцией IsPassive <AuthnRequest>, как мне привязать запрос, сделанный Поставщиком услуг к сеансу в Identity Provider? Другими словами, как поставщик удостоверений знает, кто делает запрос, если POST приходит от поставщика услуг, который является технически анонимным сеансом?
  • Используя привязку протокола перенаправления HTTP, как отправить <AuthnRequest> поставщику удостоверений, если я использую перенаправление HTTP? Отвечено на JST

UPDATE

Извините за путаницу, если я был неясен в моем объяснении выше. Я реализую как IdP, так и SP (через плагин). IdP - это существующее приложение, для которого я хочу, чтобы SP (сторонняя система) использовал для аутентификации (то есть Web SSO). На данный момент я разрабатываю простой PoC. SP фактически является сторонним приложением Spring, для которого я разрабатываю плагин для выполнения операций SAML.

Я должен был упомянуть, что я пытаюсь сделать это, используя опцию IsPassive, что означает, что User-Agent не вошел в игру во время обмена сообщениями. Это просто катализатор, который запускает SAML-party. Правильно? Имея это в виду, учитывая, что пользователь является анонимным на шаге 1, что SP отправляет в IdP, чтобы позволить IdP выяснить, является ли пользователь уже аутентифицирован? Из-за IsPassive HTTP POST не отправляется через User-Agent


UPDATE

Вопрос 1 Пересмотренный: как IdP разрешает Принципала, когда AuthnRequset отправляется с опцией IsPassive на?

Прямо из документа SAML 2.0 Profiles, стр. 15, строки с 417 по 419:

На шаге 4 определяется главный с помощью удостоверения личности некоторыми способами вне сферы действия этого профиля.

То, что мне действительно нужно, - это объяснение того, как реализовать some means.

Ответ 1

Следует иметь в виду, что нет никакой связи между сеансом на IdP и сеансом на SP. Они не знают друг о друге и общаются только через сообщения SAML. Общие шаги для SSO, инициированного SP, - это:

  • Анонимный пользователь посещает ресурс (страница) в SP.
  • SP идентифицирует, что пользователь должен быть аутентифицирован на IdP.
  • SP создает AuthnRequest и отправляет в IdP.
  • IdP выполняет некоторую аутентификацию, строит ответ SAML и отправляет в SP.
  • SP проверяет ответ и, если он действителен, делает все, что необходимо для идентификации пользователя в SP и получения их на первоначально запрошенный ресурс.

Да, необходимо связать SP AuthnRequest с ответом IdP. Это охвачено спецификацией SAML: SP AuthnRequest включает значение ID, и соответствующий ответ IdP ДОЛЖЕН включать в себя атрибут InResponseTo (в элементе SubjectConfirmationData) с этим значением ID. Протокол запроса на аутентификацию также позволяет SP передавать параметр RelayState в IdP, после чего ИДП ТРЕБУЕТСЯ пройти без изменений с ответом SAML. Вы (в роли SP) можете использовать это значение RelayState для захвата информации о состоянии, позволяющей пользователю быть ретранслированным на первоначально запрошенный ресурс.

Это означает, что при реализации SP вам потребуется какой-то механизм для записи значений ID и RelayState, а обработка ответа должна проверять значения InResponseTo и RelayState, которые он получает. Как вы решите создавать и интерпретировать значения RelayState, зависит от вас, но имейте в виду, что существует ограничение по длине. (Мы используем случайные значения GUID, соответствующие локально сохраненным данным состояния, что имеет дополнительное преимущество не давать никакого значения значениям RelayState.)

Как IdP знает, кто делает запрос? AuthnRequest должен включать элемент Эмитента, который идентифицирует SP. Он также может содержать AssertionConsumerServiceURL (URL-адрес, на который должен быть отправлен ответ), или IdP может иметь локальное сопоставление Эмитента с соответствующим URL-адресом.

Как вы отправляете AuthnRequest с помощью HTTP-перенаправления? Единственная разница между AuthnRequest, отправленной с использованием POST vs. Redirect, помимо использования GET, а не POST, заключается в том, что XML файл AuthnRequest должен быть сжат (используя кодировку DEFLATE).

Надеюсь, что ответит на большинство ваших вопросов.

Ответ 2

Джон

Я мог бы предложить сделать шаг назад и сделать еще несколько исследований, прежде чем вы решите написать собственную реализацию SAML IDP/SP. Кажется, что вы смешиваете Bindings с профилями, Unsolicited vs Solicited Web SSO, а также тот факт, что SAML требует, чтобы User Agent (aka Browser) был носителем почти всех сообщений между IDP и SP. В спецификации также есть тонна информации, которая будет реализована для обеспечения того, чтобы ваше решение действительно было безопасно.

Я бы предложил начать с нашей базы знаний SAML, а затем перейти к Технический обзор OASIS SAML 2.0 для информации об этих потоках.

В качестве альтернативы, если вы решите пойти лучше всех в своем классе, вы можете проверить наш продукт PingFederate, который может включить ВСЕ случаи использования SAML IDP/SP для вас в < день.

Надеюсь, что это поможет - Ian

Ответ 3

В отличие от Яна, я не связан с компанией, производящей продукты, связанные с SAML. Тем не менее, я бы дал несколько аналогичный совет: отступите и узнайте, почему вы используете SP или IdP. Вы действительно действуете как SP, так и IdP, или вы действительно один или другой? Если вы выполняете/действуете только как IdP, то довольно вероятно, что такой продукт, как PingFederate или что-то подобное, предлагает все, что вам нужно, через конфигурацию, а не требует, чтобы вы писали собственный код. Если вы внедряете SP, то такой продукт МОЖЕТ быть в состоянии помочь вам, но во многом зависит от характеристик системы, в которую вы ее интегрируете. Я выступаю в качестве разработчика, который реализовал как реализацию IdP, так и SP, и оценил несколько инструментов, прежде чем определять, что из-за нашей конкретной системы, клиентов и требований наша собственная реализация была наилучшим вариантом. Он существует уже более года, и несколько клиентов используют его (включая некоторые из них, используя различные коммерческие инструменты IdP).

Если вы можете определить свои варианты использования с точки зрения профилей/привязок SAML, тогда вы будете лучше подготовлены к решению buy-vs-build.