Глобальный выход с использованием Shibboleth путем удаления файла cookie IDP

У меня есть продукт, который аутентифицируется с помощью Shibboleth.

Когда пользователь инициирует выход на веб-сайте

  1. Веб-сервер отправляет запрос на выход из системы на Shibboleth SP.
  2. SP удаляет сообщение о файлах cookie при получении запроса.
  3. Однако, если пользователь возвращается на веб-сайт, страница входа не запрашивается.

Для конфигурации, показанной ниже, я использую поставщика услуг Shibboleth, указанный здесь https://www.testshib.org/install.html#SP. Он настроен на использование IdP testshib.org, сведения о котором можно прочитать здесь.

Выход из Shibboleth

Я считаю, что IdP не удаляет файл cookie сеанса и повторно входит в систему на шаге 3.

Подробнее о файлах cookie IdP:

Этот вики-источник указывает, что IdP использует два файла cookie _idp_authn_lc_key, которые удаляются после аутентификации. а второй - это файл cookie сеанса '_idp_session', для которого указано, что:

После аутентификации пользователя у него будет продолжительный сеанс с IdP, который отслеживается с помощью файла cookie с именем _idp_session. Этот файл cookie содержит только информацию, необходимую для идентификации сеанса IdP пользователя. Этот файл cookie создается как «сеансовый» файл cookie и будет удален, когда браузер решит удалить такие файлы cookie (часто при закрытии браузера).

мой вопрос

  • Какие изменения мне нужно внести в SP, чтобы запросить у IdP их удаление и фактически создать ГЛОБАЛЬНЫЙ ВЫХОД?

authentication shibboleth
person frictionlesspulley    schedule 05.04.2013    source источник
comment
Посмотрите это wiki.shibboleth.net/confluence/display/SHIB2/   -  person Michael    schedule 06.04.2013
comment
Я добился того, чего вы хотите, перейдя по URL-адресу выхода моего поставщика удостоверений личности. Ваш поставщик удостоверений личности должен предоставить его вам. Я не уверен, есть ли он у TestShib или есть ли какая-либо документация по нему. Изменить: похоже, что TestShib не поддерживает это.   -  person dperjar    schedule 02.11.2013

Ответы (1)


arrow_upward
2
arrow_downward

Как бы то ни было, вам будет очень трудно заставить IdP отключить пользователя. Подход к файлам cookie — это деталь реализации, и не все IdP используют его, и он может измениться. Некоторые поставщики удостоверений могут предлагать URL-адрес выхода из системы, но, честно говоря, это потенциально плохо для пользователей (вы можете себе представить, если бы вы могли найти способ постоянно деавторизовать пользователя не только с вашего сайта, но и с его сеансов с любыми другими поставщиками услуг?). Вы действительно имеете контроль только над своими сеансами у поставщика услуг.

Почему бы не принудительно выполнить повторную аутентификацию, когда ваш пользователь возвращается / возвращается к вашему SP? Если они не были недавно аутентифицированы у IdP после посещения (это поле, которое вы получаете обратно от обмена SAML), просто отправьте их обратно IdP еще раз и передайте флаг принудительной повторной аутентификации.

Если вы используете программное обеспечение Shibboleth, оно даже встроено: https://wiki.cac.washington.edu/display/infra/Configure+a+Service+Provider+to+Force+Re-Authentication

person Martin    schedule 11.09.2014
comment
У меня тоже есть эта проблема, и на самом деле IdP, к которому я подключаюсь, требует, чтобы мы использовали ForceAuthn на Shibboleth, однако эта функция не работает должным образом. Это вызывает повторную аутентификацию, но в систему вошел не тот пользователь. Пример: пользователь A входит в систему, выходит из SP, возвращается в SP, пользователь B вводит учетные данные, но сеанс инициируется с идентификатором пользователя A. У вас есть предложения по этому поводу? - person rink.attendant.6; 28.09.2016