Keycloak, WSO2 и некоторые другие серверы SSO IDP предлагают возможность «единого выхода» без принудительного перенаправления браузера на каждый SP, где текущий пользователь вошел в систему, отправив <LogoutRequest>
через HTTP-POST через обратный канал.
К сожалению, это не работает, если интеграция SSO в сервисе реализована с использованием библиотеки spring-security-saml2-core (мы используем Keycloack).
Все, что я мог понять из файла журнала на стороне SP, было:
[2016-01-13 12:50:56.867] [DEBUG] [org.springframework.security.saml.SAMLLogoutProcessingFilter] - Received logout request is invalid, responding with error
org.springframework.security.saml.SAMLStatusException: No user is logged in
at org.springframework.security.saml.websso.SingleLogoutProfileImpl.processLogoutRequest(SingleLogoutProfileImpl.java:168)
at org.springframework.security.saml.SAMLLogoutProcessingFilter.processLogout(SAMLLogoutProcessingFilter.java:176)
at org.springframework.security.saml.SAMLLogoutProcessingFilter.doFilter(SAMLLogoutProcessingFilter.java:102)
...
Приложение, использующее расширение Spring SAML, развернуто на Tomcat 7. Кажется, что <LogoutRequest>
при отправке через внутренний канал не имеет файла cookie сеанса браузера, и сеанс пользовательского приложения не может быть идентифицирован, поэтому пользователь не может выйти из системы и приложение сессия пользователя не будет аннулирована.
Однако <LogoutRequest>
содержит глобальный идентификатор сеанса SSO, который может однозначно идентифицировать сеанс приложения. Но этого не происходит.
Предполагается ли, что такое поведение библиотеки Spring SAML предполагает: не поддерживать внутреннюю связь во время единого выхода из системы? или мне чего-то не хватает и можно настроить желаемое поведение?
Примечание: я понимаю, что в соответствии со спецификацией SAML привязки HTTP-POST и HTTP-Redirect предназначены для передачи через User Agent (веб-браузер), однако широкая поддержка серверов SSO IDP заставила меня задать этот вопрос :)
Заранее спасибо!
ОБНОВЛЕНИЕ: Согласно комментарию Владимира Шефера в билете SES-162 похоже, это предполагаемое поведение библиотеки.