Проблема с одиночным выходом из SAML 2.0 - Как IdP должен завершать сеансы SP, запущенные в разных пользовательских агентах? - PullRequest
Новая
       161

Проблема с одиночным выходом из SAML 2.0 - Как IdP должен завершать сеансы SP, запущенные в разных пользовательских агентах?

0 голосов
/ 20 марта 2020

У меня проблема с SAML 2.0 однократный выход из системы .

У меня есть среда SAML 2.0 с IdP (поставщик удостоверений) и веб-приложением, действующим как SP (поставщик услуг) ).

Как пользователь, я запускаю сеанс веб-приложения в пользовательском агенте (браузере). Пользователь проходит проверку подлинности с использованием IdP.

В другом браузере (запущенном на том же клиентском компьютере) я запускаю другой сеанс под тем же пользователем в том же веб-приложении, т.е. в том же SP с точки зрения SAML.

Теперь у меня есть два независимых сеанса веб-приложения, где один и тот же пользователь проходит проверку подлинности.

Когда я затем выполняю один выход из системы, инициированный IdP в одном из браузеров, IdP выдает только один запрос на выход из системы, который завершает сеанс, который выполняется в этом браузере. Элемент запроса на выход из системы, выданный IdP, равен элементу, который был отправлен IdP в атрибуте SessionIndex объекта AuthnStatement подтверждения, отправленного SP с помощью этого браузера (пользовательский агент).

Не будет действительно ли необходимо, чтобы IdP отправлял запросы на выход из системы для всех открытых сеансов, чтобы добиться истинного «единого выхода»?

1 Ответ

0 голосов
/ 24 марта 2020

Краткий ответ: SAML spe c позволяет Single Logout (SLO) вести себя так, как вы хотите, но типичная реализация не такая уж сложная.

Из SAML Profiles spe c, раздел 4.4 (Single Logout Profile):

Как только принципал аутентифицирован для провайдера идентификации, аутентифицирующий объект может установить sh сеанс с принципалом (обычно с помощью «Повар» ie, перезапись URL-адреса или другое, определяемое реализацией c означает). Поставщик удостоверений может впоследствии выдавать утверждения поставщикам услуг или другим проверяющим сторонам на основании этого события аутентификации; доверяющая сторона может использовать это для установления sh своего собственного сеанса с принципалом. В такой ситуации провайдер идентификации может действовать как администратор сеанса , а проверяющие стороны - участники сеанса .

Если последовательность SLO должна была быть По инициативе одного из участников сессии все это обсуждение будет спорным. Спецификация c требует, чтобы участник сеанса идентифицировал, что «общий» сеанс завершается с помощью уникального идентификатора (он же индекс сеанса ), который был первоначально отправлен участнику сеанса провайдером идентификации. В соответствии с требованием spe c, этот идентификатор будет отличаться в вашем сеансе SP № 1 от сеанса SP № 2.

... но когда последовательность SLO инициируется IdP, ваш сценарий возможен , В разделе 4.4.4.1 говорится о правилах выдачи и обработки <LogoutRequest>:

Если запрашивающая сторона является участником сеанса, она ДОЛЖНА включить в запрос как минимум один элемент <SessionIndex>. [...] Если запрашивающая сторона является администратором сеанса (или действует от его имени), то МОЖЕТ опустить любые такие элементы, чтобы указать прекращение всех применимых сеансов принципала

Перевод: если Вы могли бы как-то сказать IdP выдать <LogoutRequest> без <SessionIndex> и , ваш SP достаточно опытен, чтобы правильно интерпретировать такой запрос и SP может завершить все сеансы для определенного пользователь через свой бэкэнд, значит, вы выиграли.

На самом деле комбинация условий выше - очень высокий порядок. Из коробки большинство IdP не будет выдавать <LogoutRequest> без <SessionIndex>. Очень немногие SP, которые даже беспокоятся о реализации SLO, не примут запрос без <SessionIndex>. В крайне редком случае, когда вы сможете найти правильный <LogoutRequest>, и SP не захлебнется им, вам очень, очень повезет, если SP правильно определит все сеансы, инициированные IdP, и будет возможность завершить их через бэкэнд.

...