Это правильная реализация SAML SSO? - PullRequest
3 голосов
/ 22 марта 2012

У меня есть сайт, который говорит www.e1.com . www.e1.com является поставщиком услуг . Всякий раз, когда я нажимаю на сервис в нем, я перенаправляюсь к провайдеру идентификации, например, www.e2.com . Перед этим в сервис-провайдере (www.e1.com) я проверю, установлен ли какой-либо файл cookie для пользователя. В первый раз не будет куки, поэтому он отправит пустое значение SessionId. Таким образом, я отправляю запрос SAML на www.e2.com без идентификатора (поскольку файл cookie не установлен. Файл cookie содержит идентификатор)

Теперь на сайте www.e2.com, т. Е. В провайдере идентификации, я проверю, отправил ли www.e1.com значение Id. Если он не задан, я создам идентификатор сессии и сохраню его в базе данных (на www.e2.com). Затем я перенаправлю браузер на свою страницу аутентификации, где будет запрошено имя пользователя и пароль, и соответственно он будет аутентифицирован. Если аутентификация прошла успешно, я перенаправлю браузер на сервис-провайдера (www.e1.com) с ответом SAML, который содержит идентификатор сеанса.

Теперь в сервис-провайдере значение SessionId будет сохранено в Cookie, и браузер будет перенаправлен на страницу обслуживания клиентов (сервисную страницу, к которой хочет получить доступ пользователь) .

Теперь, если тот же пользователь хочет получить доступ к какой-либо другой услуге от того же поставщика услуг (в рамках сеанса) браузер, очевидно, отправит SessionId в Cookie вместе с запросом SAML. Identity Provider проверит значение SessionId в своей базе данных. Если оно присутствует в его базе данных, то он предоставит прямой доступ к услуге пользователю без ввода учетных данных для входа, поскольку пользователь уже аутентифицирован для сеанса.

Является ли это правильным способом достижения единого входа с SAML? или
Если этот метод имеет недостатки, Можете ли вы объяснить эти недостатки?

Заранее спасибо:)

1 Ответ

15 голосов
/ 19 апреля 2012

Ваше понимание не совсем верно:)

Вот поток:

  1. Пользователь пытается получить доступ к защищенному ресурсу на SP. SP проверяет, У пользователя есть локальный (и аутентифицированный сеанс). Если нет, то генерируется SAML <AuthRequest>, который включает в себя случайный идентификатор. ИП затем перенаправляет пользователь в IDP с этим AuthnRequest.

  2. IDP проверит, имеет ли пользователь локальный сеанс аутентификации. Если не аутентифицирует пользователя IDP отправит AuthResponse вернуться к SP с атрибутом inReplyTo, который соответствует идентификатору, отправленному ИП в нем AuthnRequest

  3. Затем SP создаст локальный сеанс. Последующие запросы к SP не будет привлекать IDP, если а) сессия не заканчивается или б) SP получает сообщение SingleLogout от IDP

...