Какой из этих двух методов лучше для архитектуры SAML
Способ 1
Браузер направлен на сервис-провайдера. Поставщик услуг проверяет, есть ли какой-либо набор файлов cookie. Если нет, он перенаправляет браузер на поставщика удостоверений, а поставщик удостоверений (IdP) проверяет пользователя и перенаправляет идентификатор на поставщика услуг (SP). SP берет этот идентификатор и устанавливает его как cookie сеанса в браузере и перенаправляет пользователя на обслуживание. В следующий раз, если пользователь снова запрашивает службу в том же сеансе, SP проверяет наличие cookie и перенаправляет непосредственно в службу.
Способ 2
Браузер направлен на сервис-провайдера. Поставщик услуг перенаправляет на IdP. IdP проверяет наличие своего cookie-файла, и, если cookie-файл отсутствует, IdP аутентифицирует пользователя и устанавливает cookie-файл сеанса в браузере. Перенаправляет положительный ответ на ИП. ИП перенаправляет пользователя на сервис. В следующий раз, когда пользователь запрашивает услугу в течение сеанса, браузер направляется к поставщику услуг. Поставщик услуг перенаправляет на IdP.IdP проверяет его cookie и, если он присутствует, отправляет положительный ответ SP.
2 ответа
Я вполне уверен, что реализация Shibboleth в Guanxi (профиль SAML2), и почти уверен, что Shibboleth сам по себе может быть упрощен до вашего "метода 1".
Вам лучше проверить некоторые из существующих реализаций профиля SAML2.
Я не верю ни в одну из этих реализаций SAML. Обычно в SAML идентификационная информация передается через HTTP POST или через веб-сервис SOAP (см.: http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language). Файлы cookie не используются для "аутентификации" пользователя.
У нас есть веб-приложение, которое использует XML SAML 2.0, передаваемый через HTTP POST для аутентификации пользователя. Сотрудники нашего клиента обращаются к нашему приложению через провайдера идентификации на своей стороне брандмауэра.