Session active at SP after IdP-initiated SLO
search cancel

Session active at SP after IdP-initiated SLO

book

Article ID: 279021

calendar_today

Updated On:

Products

SITEMINDER

Issue/Introduction

SSO is done from IdP site and a session is established at the SP site.

One can see that a SMSESSION cookie is being created and placed in the browser at the SP site.

Next, SLO is initiated at the IdP, and even though configuration is fine, when accessing the SP site a valid session is still present.

This behavior may change depending on the browser used, namely it may work in some browsers but not other

Environment

CA SiteMinder with WAOP or SPS, all versions

Cause

The process of carrying out SLO implies that the SMSESSION cookie must be passed in the SLO call so that it gets invalidated.This will  prevent a session replay at SP.

Following a Web developer tools trace or a Fiddler trace, once the SLO is initiated, one would see a call like the following in the traces

GET https://<sp_domain>/affwebservices/public/saml2slo?SAMLRequest=<SSO_SAML_Request>&RelayState=<Relay_state>&SigAlg=<Signature_algorithm>&Signature=<Signature> HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br
Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
Cache-Control: no-cache
Connection: keep-alive
Cookie: SMSESSION=<SM_SESSION cookie here>; _cs_c=1; _cs_id=<cs_id> _cs_s=<cs_s>
Host: <SP_URL>
Pragma: no-cache
Referer: <IDP_URL>
Sec-Fetch-Dest: iframe
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
sec-ch-ua: "Not_A Brand";v="8", "Chromium";v="120", "Google Chrome";v="120"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"

Since there are both a Web Agent and the Federation or WAOP running  at the SP, the first thing is to invalidate the SMSESSION cookie, and then the WAOP will set the SMSESSION and SESSIONSIGNOUT cookies to LOGGEDOFF

So the response to the previous request will be the following

HTTP/1.1 302 Found
Connection: close
Content-Length: 0
Date: Wed, 17 Jan 2024 09:17:35 GMT
Location: https://<IdP_site>/sso/SLO.saml2?SAMLResponse=<SSO_SAML_Response>&RelayState=<Relay_state>&SigAlg=<Signature_algorithm>&Signature=<Signature>
Server: Unknown
Set-Cookie: SMSESSION=<SM_SESSION cookie here>; path=/; domain=<SP_cookie_domain>; secure; HTTPOnly; SameSite=none
Set-Cookie: SMSLOGUID=<SMS_LOGUID>; Domain=<SP_cookie_domain>; Path=/; secure; HTTPOnly; SameSite=none
Set-Cookie: SMSLOGUID=; Domain=<SP_cookie_domain>; Path=/; max-age=0; expires=Thu, 01-Jan-1970 00:00:10 GMT; secure; HTTPOnly; SameSite=none
Set-Cookie: SMSESSION=LOGGEDOFF; Domain=<SP_cookie_domain>; Path=/; secure; HTTPOnly; SameSite=none
Set-Cookie: SESSIONSIGNOUT=LOGGEDOFF; Domain=<SP_cookie_domain>; Path=/; secure; HTTPOnly; SameSite=none

and following SLO the SP site should receive SMESSION ans SESSIONSIGNOUT cookies with value LOGGEDOFF

GET https://<SP_site_url> HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br
Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
Cache-Control: no-cache
Connection: keep-alive
Cookie: Profil_client=undefined; consentuser=<consent_user>; consentiab=<consent_tab>; varcp2=<varcp2>; utag_main=<utag_main>; _gid=<gid>; _ga=<_ga>; _cs_c=1; SMSESSION=LOGGEDOFF; SESSIONSIGNOUT=LOGGEDOFF; _cs_id=<cs_id>; _cs_s=<cs_s>
Host: <SP_host>
Pragma: no-cache
Referer: <IdP_host>
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
sec-ch-ua: "Not_A Brand";v="8", "Chromium";v="120", "Google Chrome";v="120"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"

So there are two conditions that must be met

  • On SLO the IdP must do a request passing the SMSESSION together with the SAML assertion request to the SLO service
  • In the response the Web Agent will invalidate the SMSESSION cookie and the WAOP will set SESSIONSIGNOUT and SMSESSION to LOGEDOFF. This will be done even if no SMSESSION is passed in the request, and there will be lines in FWSTrace.log showing this is so

This mechanism should work independently of the browser and it can be verified by capturing the Web traffic traces by means of Web Developer tools and by checking the the same means the cookie stores (Storage in Firefox or Cookies in Chrome, for instance) to see the evolution.

If the SMSESSION or SESSIONSIGNOUT cookies with value LOGGEDOFF are not appearing at the SP site, this will cause it to still use the previous SMESSSION cookie and the session will still be active.

To troubleshoot this check the cookie flow between IdP and SP during SLO and  observe the previous cookie exchange. If this is not happening  troubleshooting is needed to know why this is so.

A typical use case that may occur is that the cookies are set to LOGGEDOFF by WAOP or Federation, but once they get to the SP site they are ignored. This will be evident  by following the cookies in the Web developer tools.

As of lately, many different browsers have heavily restricted third party cookies or passing cookies across sites

See for instance

https://knowledge.broadcom.com/external/article/277299/siteminder-and-the-intended-chrome-cooki.html

for Chrome

And

https://support.mozilla.org/en-US/kb/total-cookie-protection-and-website-breakage-faq

for Firefox

These may be possible reasons why SLO is not working across the sites

 

 

 

 

Resolution

As indicated above, make sure the previous mechanism for correctly setting the cookies holds. If it does not, it is recommended to test with different browsers. The flow is exactly the same and therefore all browsers should behave in the same manner

If this works properly in one browser (e.g. Chrome) but not another (e.g. Firefox) find out what is different between them in terms of settings, protection, options in headers, etc.

First step is to try the latest version of the browser(s) which are not working fine.

If this does not help,  try some debugging in the failing browser(s)  as for instance for Firefox

start /B firefox -jsconsole in Firefox

to try to reach some conclusion while reproducing the problem, or engage the browser technical support if needed.

Please  check beforehand how the browser deals with cross site cookies as indicated in the previous section.

In any case, if SiteMinder is providing the right flow and the SMESSION and SESSIONSIGNOUT cookies are set to LOGGEDOFF in FWSTrace.log and in the browser trace using Web Developer tools or an equivalent application, the problem lies solely with the browsers and it should be brought to their attention

Powered by Wolken Software