SAML SSO как это работает?

Question

Допустим, у нас есть приложение поставщика услуг, которое называется A, размещенное на tomcat, пользователь щелкает ссылку на SP A. SP A не видит токена, поэтому он перенаправляет пользователя на IdP для аутентификации (с запросом SAML Authn).обеспечивается некоторыми средствами).Затем IdP перенаправляет пользователя на некоторую обычную страницу входа, где предоставляются учетные данные, при условии, что эти учетные данные верны, IdP создает ответ SAML с токеном и некоторыми утверждениями о предмете и отправляет его обратно в SP A. SP A видит этои позволяет пользователю доступ в приложение.Отлично!

У меня есть несколько вопросов, хотя

1. Как отправляется запрос / ответ на авторизацию, я понимаю, что существует привязка перенаправления и привязка POST, где кодируются SAMLResponse и запрослибо в качестве параметра запроса, либо в виде формы XHTML в случае привязки POST.Но я не уверен, где это используется?
2. Поставщик услуг - это то, что предоставляет услугу, например Office 365 или отдел продаж.Является ли каждый отдельный поставщик услуг?Я спрашиваю, когда я смотрел видео, где парень сказал, что поставщик услуг был тем, кто размещал эти услуги, поэтому я не уверен в правильном ответе здесь?
3. Как токен хранится на стороне клиента?Так, например, я теперь аутентифицировался на SP A, затем пользователь пытается использовать SP B из того же окна машины / браузера, как SP B и IdP узнают, что пользователь уже прошел аутентификацию и, следовательно, не нужно повторноаутентификации.Т.е. аспект SSO этого.
4. Нужно ли размещать SP B на одном экземпляре tomcat, чтобы это работало?

Answer 1

Из моего собственного опыта:

1. Вы можете выбрать свою собственную SAMLBinding (перенаправление или публикация) в зависимости от того, что поддерживает ваш idp и sp.Этот тип привязки будет использоваться как для 1-го шага (SP -> Idp), так и для 2-го шага (IdP -> SP).Если у вас есть работающая среда, откройте ваш браузер devtools и посмотрите на вкладку сети, чтобы увидеть, что происходит.Это просто способ отправки данных из браузера в SP / IdP.

2. И Office 365, и Salesforce.com являются облачными службами, верно?Давайте возьмем Office 365. Это означает, что за пределами служб «конечного пользователя» (таких как Word, Excel) есть некоторые технические службы единого входа, которые являются общими для платформы.Его можно рассматривать как нижний (или технический) уровень обслуживания, я думаю, что имел в виду ваш оратор.

3. Токен SAML хранится вашим SP-приложением внутри браузера, либо скрытым внутри сети.страница, cookie или веб-хранилище.Это зависит от того, как реализован ваш SP.

Ответ SAML может быть проверен каждым SP на основе общего закрытого ключа, поэтому он расшифрует токен с помощью этого ключа и сможет предоставить пользователю без перенаправления IdP.

У Tomcat есть расширение для поддержки SAML.Но SAML предназначен для работы без использования одного экземпляра, в отличие от базовых файлов cookie JSESSIONID.Итак, у вас есть несколько экземпляров, конечно.

Answer 2

Я посвятил значительное время работе SSO для меня.Самым полезным документом была эта спецификация

Ответы ниже основаны на этом опыте:

1. Переадресация или Пост-привязка используются в зависимости от соответствующего заголовка HTTP-запроса,Привязка Post рекомендуется, поскольку она не накладывает ограничений на объем передаваемых данных.
2. Поставщик услуг в этом контексте - это все, что запрашивают клиенты.Их может быть много, участвующих в одной и той же схеме единого входа.
3. Поставщики услуг должны быть осведомлены о едином входе, что включает обработку данных ответа аутентификации.Обычно вам не нужно реализовывать протокол - существуют готовые платформы, которые может использовать ваш SP.
4. Поставщики услуг могут находиться на разных серверах.