Как мне следует реализовать привязку протокола HTTP POST для профиля SAML WebSSO? - PullRequest
13 голосов
/ 03 февраля 2011

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

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

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

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

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

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

UPDATE

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

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


UPDATE

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

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

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

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

Ответы [ 3 ]

19 голосов
/ 03 февраля 2011

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

  1. Ресурс анонимного пользователя (страница) в SP.
  2. SP определяет, что пользователь должен пройти аутентификацию в IdP.
  3. SP создает AuthnRequest и отправляет IdP.
  4. IdP выполняет какую-то аутентификацию, создает SAML-ответ и отправляет SP.
  5. SP проверяет ответ и, если он действителен, делает все необходимоечтобы идентифицировать пользователя в SP и доставить его к первоначально запрошенному ресурсу.

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

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

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

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

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

3 голосов
/ 03 февраля 2011

Джон,

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

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

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

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

1 голос
/ 03 февраля 2011

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...