SAML logout not destroying oxAuth state

By: Petr Hroudny user 23 Jun 2019 at 3:07 p.m. CDT

4 Responses
Petr Hroudny gravatar
Gluu server's IDP metadata list a few URLs for SLO logout: ``` SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://server.name/idp/profile/SAML2/Redirect/SLO" SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://server.name/idp/profile/SAML2/POST/SLO" .... ``` When such URL is accessed by the SP initiating logout, SAML logout is correctly propagated to other SPs which support SLO logout. However, it seems that oxAuth is not notified and thus user-logged-in state is not destroyed. The user remains logged in at Gluu server and any service (SP) can be accessed without going through Gluu's login page. Gluu 3.1.6 docs mention the following SAML logout page: https://server.name/idp/Authn/oxAuth/logout however, this URL is not present in Gluu server's IDP metadata (i.e. no SP knows about it) and that single page is most probably not usable for all available SLO methods (HTTP-Redirect, HTTP-POST, ...) Thanks in advance for you help.
CentOS 7.0
closed

Answers

By Michael Schwartz Account Admin 24 Jun 2019 at 2:10 a.m. CDT

Copy
Michael Schwartz gravatar
This is a known issue. Track on [oxShibboleth-52](https://github.com/GluuFederation/oxShibboleth/issues/52)

By Petr Hroudny user 24 Jun 2019 at 2:36 a.m. CDT

Copy
Petr Hroudny gravatar
Hmm, oxShibboleth-52 is about back-channel (SOAP) logout, which is not yet supported in Shibboleth. However, the issue I'm seeing is about front-channel (e.g. HTTP-Redirect) logout, which works in standalone Shibboleth since version 3.2.0 Gluu 3.1.6. is using Shibboleth as an extension - i.e. during login it forwards authentication work to oxAuth. All login endopoints are doing this fine: ``` https://server.name/idp/profile/SAML2/Redirect/SSO https://server.name/idp/profile/SAML2/POST/SSO ...etc... ``` However, it seems that logout endpoints are not yet notifying oxAuth to destroy the user session on Gluu server. I believe all Shibboleth's logout endpoints, i.e. ``` https://server.name/idp/profile/Logout https://server.name/idp/profile/SAML2/Redirect/SLO https://server.name/idp/profile/SAML2/POST/SLO ...etc.. ``` need to call oxAuth logout procedure as the first step - to destroy user session at Gluu server. Otherwise SAML SPs are unable to execute SSO Logout properly.

By Michael Schwartz Account Admin 24 Jun 2019 at 3:34 a.m. CDT

Copy
Michael Schwartz gravatar
Added [oxShibboleth-61](https://github.com/GluuFederation/oxShibboleth/issues/61)

By Vreixo Luis Gonzalez Caneda user 27 Feb 2022 at 4:16 p.m. CST

Copy
Vreixo Luis Gonzalez Caneda gravatar
Hi, Do you have any updates on this? It's confirmed at this point to 5.0 as stated in Github? We managed to have apparently working the Logout from Office 365 to oxShibboleth after some troubleshooting, mainly changing logout endpoint adding a metadata to SAML Trust which includes certificates from Microsoft (logout requests are signed). Unfortunately users is still be authenticated in oxauth even when oxShibboleth replies with a 200 to the call sent by Microsoft at https://my-tenant/idp/profile/SAML2/Redirect/SLO.

Post an answer