Logout not happening using /idp/logout.jsp

By: Thomas Maerz user 01 Nov 2018 at 11:09 a.m. CDT

10 Responses
Thomas Maerz gravatar
I am having a similar issue to https://support.gluu.org/log-out/4969/logout-not-happening-using-idplogoutjsp/ Since upgrading from 2.4.3 to 3.1.3, users are having to close the browser to destroy SAML SSO session fully when logging out of applications that redirect the browser to https://idp.company.com/idp/logout.jsp. Is there some configuration I must change on my idP to return this behavior to destroying entire SSO session cookies for all RPs/SPs?
Ubuntu 16.04
closed

Answers

By Thomas Maerz user 01 Nov 2018 at 11:15 a.m. CDT

Copy
Thomas Maerz gravatar
Just to clarify, it IS destroying the user session to Gluu -- if you browse to https://idp.company.com/ the user IS presented with a login screen, but if you browse back to any RP/SP login URL, the user is sent straight to application as it appears that SSO SAML session cookies are still present in browser. The only way user can fully log out currently is to get redirected to /idp/logout.jsp, then close browser completely (Not just tab or window), then open browser and browse to SP login URL again. So, to reiterate, is there something I need to configure on the SAML idP to have /idp/logout.jsp destroy all SSO session cookies/tokens? Thanks.

By Aliaksandr Samuseu staff 01 Nov 2018 at 3:49 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Thomas. >it IS destroying the user session to Gluu -- if you browse to https://idp.company.com/ the user IS presented with a login screen That's about how much you can achieve in terms of logout for SAML SSO. Gluu's IDP does its part of the job - it destroys its own and oxAuth's sessions. It can't remove cookies of another parties, or end their session - without being able to communicate with those parties and instruct them to do so. That's called Single Logout, and its support in Shibboleth IDP is limited. We don't support any of this limited implementation in Gluu's version of IDP at the moment. So the recommended approach is that SP kills its own session, and then sends user to `/logout.jsp` at Gluu Server. For OIDC flows you have much more options when it comes to SLO, if using OIDC is an option.

By Thomas Maerz user 01 Nov 2018 at 3:51 p.m. CDT

Copy
Thomas Maerz gravatar
I can demonstrate to you on Gluu 2.4.3 how this is not how the application used to work. Why has the behavior changed?

By Aliaksandr Samuseu staff 01 Nov 2018 at 4:02 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
The only thing logout.jsp did in the past is destroying Gluu's session's objects. It simply couldn't do anything with another app's objects, as they are domain-restricted, an app at a different domain cannot operate cookies from another domain, unless a complex orchestrated set of conditions is in place (usually it isn't). If anything has changed since then it's browser's or your SP's behavior. Or the later handles logout from your 2.4 instance differently from logout from 3.x instance. Please clarify how exactly it changed, and provide full network trace for both those cases you believe are different, in form of HAR files.

By Aliaksandr Samuseu staff 01 Nov 2018 at 4:06 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Just to emphasize this one point: sessions at Gluu and sessions at SP/app are totally different sessions. The only way for Gluu's IDP to somehow trigger end of session at SP is to use SLO, which isn't supported (and wasn't before).

By Thomas Maerz user 01 Nov 2018 at 4:06 p.m. CDT

Copy
Thomas Maerz gravatar
Ok, I think that is what I am talking about. Why doesn't Gluu destroy Gluu's session's objects any longer? Can I configure it to do that once again? Because the way it was working is literally if you hit the /logout.jsp page, all SSO apps were permanently logged out until you punched in a password again. Thomas

By Thomas Maerz user 01 Nov 2018 at 4:07 p.m. CDT

Copy
Thomas Maerz gravatar
Sorry I didn't mean to close, can you reopen?

By Thomas Maerz user 01 Nov 2018 at 4:10 p.m. CDT

Copy
Thomas Maerz gravatar
What I am trying to say is that my SP applications ARE destroying their own sessions, I have them configured to do log out action of their own and THEN redirect to /logout.jsp to prevent login to other SP from same SSO session. But all apps moved to 3.1.3 are letting the user right back into the app they logged into and others after hitting logout.jsp. If Gluu was destroying session's objects, then wouldn't it be impossible after hitting logout.jsp to go to a separate SP and login with no password prompt?

By Aliaksandr Samuseu staff 01 Nov 2018 at 4:11 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
One thing to keep in mind, though: if you are using a mixed environment with both SAML and OIDC SSO flows, then if an SAML SP will terminate session at Gluu by sending user to `logout.jsp`, it will also trigger front-channel logout for OIDC RPs (if it was configured in the first place, of course), killing sessions at least at some of RPs - this is because `logout.jsp` also kills oxAuth's session, what on its turn initiates front-channel logout flow. But it won't kill sessions at SAML SPs anyway, as SAML SLO isn't supported.

By Aliaksandr Samuseu staff 01 Nov 2018 at 4:13 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
>What I am trying to say is that my SP applications ARE destroying their own sessions, I have them configured to do log out action of their own and THEN redirect to /logout.jsp to prevent login to other SP from same SSO session. But all apps moved to 3.1.3 are letting the user right back into the app they logged into and others after hitting logout.jsp. Please record a HAR file showing this behaviour in action. You can use steps listed [here](https://www.inflectra.com/support/knowledgebase/kb254.aspx) - please use Firefox for that task, Chrome's HARs are flawed. Also don't forget to set "Persist log" and "Disable cache" checkboxes in the console to save everything, not just the recently loaded page.

Post an answer