SLO: redirectTo parameter for the logout URL

[soudis]

Szenario

I have a nextcloud server and a discourse server. The discourse server authenticates through it's own SSO mechanism with nextcloud using the discoursesso app for nextcloud (maintained by me). Nextcloud itself authenticates using SAML against a SimpleSAMLPhp IDP.

Everything works just fine, except the logout. When the user hits logout in discourse it redirects to the logout endpoint of the discoursesso app, which then redirects to the SAML logout URL of the user_saml app. Then the SLO process is taking place, but at the end the user is redirected to the nextcloud URL.

Expected behaviour

The user should be redirected to the discourse URL (where the logout request came from).

Actual behaviour

After the SAML SLO procedure is finished the user is redirected to '/', meaning the cloud base URL.

Explaination

This can of course not be done by the user_saml app, because the logout request comes from discourse to the discoursesso app, which the redirects to the logout URL, so user_saml does not know about the origin. But the discoursesso app would be able to pass a redirectTo parameter to the user_saml app with the logout URL.

e.g.: https://cloud.habidat.local/apps/user_saml/saml/sls?requesttoken=aY.......D&returnTo=https://discourse.example.org

With a simple patch the SAMLController.php could then pass the returnTo as a RelayState to $auth->logout and after the SLO response from the Idp is received it can redirect to the url using the RelayState parameter the Idp passes along.

I'm not 100% sure about side effects, as my knowledge of all the SAML use cases is limited and some my be affected by this. Maybe you guys have the knowledge to assess the side affects?

[PrivatePuffin]

SAML logout shouldn't put your user in some sort of cascade of different logout urls's for different SP's.
It should de SLO in the background and each SP should invalidate their own sessions.

[soudis]

as far as i understand that's what SAML SLO is supposed to do, here is a comprehensive explanation of SAML SP-initiatited SLO:

https://www.portalguard.com/blog/2016/06/20/saml-single-logout-need-to-know/

I'm not an expert though, so let me know if I understood it wrong

[PrivatePuffin]

Yes, but those requests and responses are backchannel for the most part. Not a forward.

[soudis]

OK, i did not know there was a backchannel method.. I did some research and could not find proper documentation on how to set something like this up. Seems to be more complicated and there is quite some software out there who supports SAML but only with frontchannel SLO.

But there is definitely a method that uses frontchannel redirects to implement SAML SLO (as we are doing in our setup) and for that I would still appreciated if my pull request could be considered.

[PrivatePuffin]

@soudis A SLO request from the IDP, isn't "just a forwarded get/post request" to a certain url... It's actually a specific datapackage, that contains more than just a token.

[soudis]

I know that there is a data package, but what I could see is that SAML backchannel SLO works with SAML artifacts which may not be implemented at every SP.

If you have any link or resource that may clear things up for me, pls let me know. I may be too much of a noob to get anything meaningful out of your short replies.

Here's the excerpt of the resource which describes the frontchannel method, which really seems to be the more commonly used SAML SLO method:

SAML Single Logout – How It Works

There are different modes of operations within SLO. What follows describes the “Asynchronous” or “Front Channel” model which uses HTTP redirection through the end-user’s browser. This is the model supported in our very own PortalGuard product. There is also a “Synchronous” or “Back Channel” model which only involves server-to-server communication that does not utilize the user’s web browser as a conduit. The synchronous model is not covered in this article.

SP-initiated SAML Single Logout

1. The Initiating SP generates a digitally signed LogoutRequest SAML message and returns it to the end-user’s browser. This validates the request to the IdP.
2. The IdP’s SLO endpoint is appended with the LogoutRequest, which is a dedicated URL that expects to receive SLO messages. This entire URL is returned to the user’s browser via a 302 HTTP redirection response.
3. The browser follows the redirect and requests the IdP’s SLO URL with the LogoutRequest in the query string.
4. The IdP determines the other SPs that support SLO to which the end-user received SSO during the current logon session. The IdP then iteratively does the following for each participating SP:

• Generates a new, digitally signed LogoutRequest
• Redirect user’s browser to that SP’s SLO endpoint
• Waits for a LogoutResponse from the SP via the user’s browser

5. Each SP terminates its own logon session for the end user after receiving and validating the LogoutRequest from the IdP.
6. The IdP terminates its own logon session and sends a final LogoutResponse message that to the initiating SP. This matches the original LogoutRequest it sent it step Add support for application specific passwords #1. The response includes a flag telling the originating SP whether SAML Single Logout was either fully or partially completed.
7. The SP displays a logout page to the end-user

[PrivatePuffin]

Ahh yes, thats possible, but very non-standard.
But yes it is a great-but-hacky way to get it done :)

Certainly considering the fact the user_saml devs are ignoring the fact SLO is broken for ages now.
See #455