Как мне следует реализовать привязку протокола HTTP POST для профиля SAML WebSSO?
Я реализовал свой сервис-провайдер и провайдер идентификации, следуя профилю SAML для единого входа в Интернет, используя привязку протокола HTTP POST. Однако меня немного смущает вопрос о том, как поставщик удостоверений будет предоставлять <AuthnStatement> если HTTP POST, исходящий от поставщика услуг, не привязан к сеансу на поставщике удостоверений.
Может ли кто-нибудь просветить меня, как можно это сделать?
Другой подход, который я мог бы использовать, - это привязка перенаправления HTTP, но для этого требуется вмешательство агента пользователя (т. Е. Браузера), при котором пользователь-агент часто используется просто в качестве промежуточного посредника для облегчения обмена сообщениями запрос-ответ. Я бы предпочел использовать HTTP POST по этой причине, потому что обмен сообщениями происходит на стороне сервера, поэтому пользователь не видит ничего на своем экране.
Однако использование HTTP Redirect имеет для меня больше смысла в том, как я могу связать сеанс с запросом. Поскольку перенаправление HTTP облегчается через User-Agent, запрос к IdP будет иметь сеанс (если ранее был аутентифицирован). Но я не получаю, как отправить <AuthnRequest> на перенаправлении HTTP. Ответ от JST
Поэтому я немного растерялся и хотел бы услышать, что делают другие люди. Вот мои вопросы снова:
- Использование привязки протокола HTTP POST с
IsPassiveвариант<AuthnRequest>как связать запрос, сделанный поставщиком услуг, с сеансом на поставщике удостоверений? Другими словами, как провайдер идентификации узнает, кто делает запрос, если POST исходит от провайдера услуг, который технически является анонимным сеансом? -
С помощью привязки протокола перенаправления HTTP, как я могу отправить<AuthnRequest>к провайдеру идентификации, если я использую HTTP Redirect?Ответ от JST
ОБНОВИТЬ
Извините за путаницу, если мне было неясно в моем объяснении выше. Я реализую как IdP, так и SP (через плагин). IdP - это существующее приложение, для которого я хочу, чтобы SP (сторонняя система) использовался для аутентификации (т. Е. Web SSO). Я разрабатываю простой PoC на данный момент. SP на самом деле является сторонним приложением Spring, для которого я разрабатываю плагин для выполнения операций SAML.
Я должен был упомянуть, что я пытаюсь сделать это, используя IsPassive Это означает, что пользователь-агент не вступает в игру во время обмена сообщениями. Это просто катализатор, который запускает SAML-вечеринку. Правильно? Имея это в виду, учитывая, что пользователь является анонимным на шаге 1, что SP отправляет IdP, чтобы позволить IdP выяснить, аутентифицирован ли уже пользователь? Из-за IsPassive HTTP POST не отправляется через User-Agent
ОБНОВИТЬ
Пересмотрен вопрос 1: Как IdP разрешает Принципала, когда AuthnRequset отправлено с IsPassive вариант на?
Прямо из документа "Профили SAML 2.0", стр. 15, строки с 417 по 419:
На шаге 4 принципал идентифицируется посредством идентификатора, предоставляемого некоторыми средствами, выходящими за рамки этого профиля.
Что мне действительно нужно, так это объяснение того, как реализовать some means,
3 ответа
Нужно иметь в виду, что нет никакой связи между сеансом на IdP и сеансом на SP. Они не знают друг о друге и общаются только через сообщения SAML. Основные шаги для SSL SAML, инициируемой SP:
- Анонимный пользователь посещает ресурс (страницу) на SP.
- SP определяет, что пользователь должен пройти аутентификацию в IdP.
- SP создает AuthnRequest и отправляет в IdP.
- IdP выполняет своего рода аутентификацию, создает ответ SAML и отправляет SP.
- SP проверяет Ответ и, если он действителен, делает все необходимое, чтобы идентифицировать пользователя в SP и доставить его к первоначально запрошенному ресурсу.
Да, должен быть какой-то способ соединить AuthnRequest SP с Ответом IdP. Это охватывается спецификацией SAML: AuthnRequest SP включает в себя значение идентификатора, и соответствующий ответ IdP ДОЛЖЕН включать атрибут InResponseTo (в его элементе SubjectConfirmationData) с этим значением идентификатора. Протокол запроса аутентификации также позволяет SP передавать параметр RelayState в IdP, который затем IdP ОБЯЗАТЕЛЬНО должен передавать без изменений в ответе SAML. Вы (в роли SP) можете использовать это значение RelayState для сбора информации о состоянии, позволяющей ретранслировать пользователя на первоначально запрошенный ресурс.
Это подразумевает, что при реализации SP вам понадобится какой-то механизм для записи значений ID и RelayState, а для обработки ваших ответов необходимо проверить полученные значения InResponseTo и RelayState. Как вы решите создавать и интерпретировать значения RelayState, зависит только от вас, но имейте в виду, что существует ограничение длины. (Мы используем случайные значения GUID, соответствующие локально сохраненным данным состояния, что имеет дополнительное преимущество, заключающееся в том, что они не дают никакого намека на значение для значений RelayState.)
Как IdP узнает, кто делает запрос? AuthnRequest должен включать элемент Issuer, который идентифицирует SP. Он также может содержать AssertionConsumerServiceURL (URL-адрес, на который должен быть отправлен ответ), или IdP может иметь локальное сопоставление эмитента с соответствующим URL-адресом.
Как вы отправляете AuthnRequest с помощью HTTP Redirect? Единственное различие между AuthnRequest, отправляемым с использованием POST и Redirect, помимо использования GET, а не POST, заключается в том, что XML-файл AuthnRequest необходимо сжать (используя кодировку DEFLATE).
Надеюсь, что это отвечает на большинство ваших вопросов.
Джон,
Я мог бы предложить сделать шаг назад и провести дополнительные исследования, прежде чем вы решите написать собственную реализацию SAML IDP/SP. Похоже, вы смешиваете привязки с профилями, Unsolicited vs Solicited Web SSO, а также тот факт, что SAML требует, чтобы User Agent (он же Browser) являлся носителем почти всех сообщений между IDP и SP. В спецификации также содержится тонна информации, которую нужно будет внедрить, чтобы убедиться, что ваше решение действительно безопасно.
Я бы предложил начать с нашей базы знаний SAML, а затем перейти к техническому обзору OASIS SAML 2.0 для получения информации об этих потоках.
В качестве альтернативы, если вы решите стать лучшим в своем классе, вы можете проверить наш продукт PingFederate, который может включить ВСЕ варианты использования SAMP IDP / SP в течение <дня.
Надеюсь, это поможет - Ян
В отличие от Яна, я не связан с компанией, производящей продукты, связанные с SAML. Тем не менее, я бы дал несколько похожий совет: отойдите и выясните, почему вы используете SP или IdP. Вы действительно действуете как SP и IdP, или вы действительно просто один или другой? Если вы реализуете / действуете только как IdP, то вполне вероятно, что такой продукт, как PingFederate или что-то подобное, предлагает все, что вам нужно, через конфигурацию, а не требует написания собственного кода. Если вы внедряете SP, то такой продукт МОЖЕТ помочь вам, но он во многом зависит от характеристик системы, в которую вы его интегрируете. Я говорю как разработчик, который выполнил как IdP, так и SP, и оценил несколько инструментов, прежде чем определить, что из-за нашей конкретной системы, клиентов и требований заказная реализация была нашим лучшим вариантом. Он существует уже более года, его используют несколько клиентов (в том числе некоторые используют различные коммерческие инструменты IdP).
Если вы сможете определить свои варианты использования с точки зрения профилей / привязок SAML, то вы будете лучше подготовлены к принятию решения о покупке-сборке.