sp инициировал saml sso аутентификацию - PullRequest
0 голосов
/ 22 января 2019

Я работаю над SP, инициированным saml sso, и это совершенно новое для меня.Я просмотрел множество статей и видео (википедия, центрифуга, средние посты), но не могу понять некоторые вещи:

  1. Является ли утверждение SAML токеном SAML?если нет, то как он генерируется?

  2. Предположим, у меня есть IdP на основе saml и два SP с поддержкой saml.Теперь в чисто пост-привязке, когда я вхожу в один из SP, а затем вхожу во второй SP, как второй SP входит в систему?Чтобы быть более точным, как второй SP знает, что пользователь уже вошел в первый SP?Что это за параметр, который решает это?(Могу ли я получить более низкое объяснение уровня этого).Сохраняет ли IdP данные о cookie в сеансе или что-то еще, что я упускаю.

Если есть какие-либо статьи, основанные на этом, пожалуйста, опубликуйте их.

Спасибо.

Ответы [ 2 ]

0 голосов
/ 08 марта 2019

Позвольте мне сначала ответить на ваши конкретные вопросы:

1) Является ли утверждение saml токеном SAML?если нет, то как это сгенерировано?

- Это всего лишь терминология для одного и того же.Утверждение SAML и токен SAML - это одно и то же.Существуют 2 различных утверждения / токена SAML, на которые важно обратить внимание.Запрос SAML и ответ SAML.Запрос SAML - это то, что отправляется от SP к IDP в SSL, инициированном SP.Ответ SAML - это то, что отправляется из IDP в SP в качестве заключительной части инициируемого SP или во время инициированного IDP SSO SAML.SP инициируется, когда пользователь запускает приложение SP, перенаправляется в IDP для аутентификации, а затем отправляется обратно в приложение SP IDP.IDP инициируется, когда пользователь начинает с IDP и идет прямо к SP.Утверждение SAML - это просто XML, который был подписан, преобразован в строку и закодирован в формате base 64.они перенаправляются с пользователя из SP в IDP и обратно.

2) Предположим, у меня есть IdP на базе saml и два SP с поддержкой saml.Теперь в чисто пост-привязке, когда я вхожу в один из SP, а затем вхожу во второй SP, как второй SP входит в систему?Чтобы быть более точным, как второй SP знает, что пользователь уже вошел в первый SP?Что это за параметр, который решает это?(Могу ли я получить более низкое объяснение уровня этого).Хранит ли IdP данные о cookie в сеансе или есть что-то еще, что я пропускаю.

- Это характерно для вашего IDP.Как Centrify SME, я могу рассказать вам, как работают Centrify и аналогичные ВПЛ.Когда пользователь входит в IDP, независимо от того, является ли он перенаправлением, инициированным SP, IWA на своей корпоративной машине или непосредственно на сам IDP, в браузер добавляется cookie.В случае Centrify этот файл cookie называется .ASPXAUTH.Каждый раз, когда пользователь попадает в IDP после входа в систему, ему не предлагается снова войти в систему.Таким образом, если пользователь начинает с SP1, перенаправляется в IDP, входит в систему и перенаправляется обратно, файл cookie был установлен IDP.Теперь, если они перейдут к SP2, по умолчанию этот SP также перенаправит на IDP, но IDP не будет запрашивать авторизацию снова из-за установленного cookie.Таким образом, пользователь не заметит перенаправление, и IDP просто отправит их обратно в SP2 с соответствующим SMAL-ответом.Вот так:

SP1> Запрос SAML и перенаправление в IDP> Войдите в систему IDP, и cookie установлены> Ответ SAML и перенаправьте обратно в SP1> Перейдите в SP 2> Запрос SAML и перенаправьте в IDP> Cookieустановите его так, чтобы немедленно перенаправить обратно к SP с помощью ответа SAML.

У Centrify также есть API, которые могут использоваться SP.Например, SP может выполнить клиентский API-вызов к / security / whoami, чтобы проверить, существует ли действительный файл cookie ASPXAUTH.Таким образом, SP2 может проверить действительный файл cookie и принять решение о перенаправлении вообще, поскольку файл cookie уже установлен.https://developer.centrify.com/reference-link/securitywhoami

Надеюсь, это поможет.Я написал очень простой пример этого в c # в то время как в Centrify.Вы можете найти код здесь https://github.com/centrify/CentrifySAMLSDK_CS. Не стесняйтесь обращаться сюда с дополнительными вопросами или найти меня в твиттере https://twitter.com/NickCGamb

0 голосов
/ 22 января 2019
  1. Да, подтверждение обычно само по себе является полностью переносимым токеном, но есть способы связать его, например, с ключами запрашивающей стороны.

  2. Второй SP делает теперь, когда пользователь уже вошел в систему. SP перенаправит пользователя к IDP с запросом аутентификации к IDP.IDP обычно сохраняет cookie для пользователя при первой аутентификации, это не указано в SAML, но обычно это делается.Когда пользователь приходит в IDP, IDP просматривает cookie-файл, и если аутентификация пользователя все еще действительна, IDP автоматически отправляет действительное подтверждение / токен в SP.SP может переопределить это поведение, указав атрибут ForceAuthn в запросе аутентификации.

Что касается ресурсов, я бы порекомендовал Технический обзор SAML от OASIS http://www.oasis -open.org / committees / download.php / 27819 / sstc-saml-tech-Overview-2,0-CD-02.pdf

...