SLO HTTP-Redirect endpoint with query-string parameters (/?sls).

[Cameron Kerr]

I'm trying to get the python3-saml demo-django project (https://github.com/onelogin/python3-saml/tree/master/demo-django) working nicely (including logout) with Shibboleth IdP version 3.2.1 (currently).

I've got login working (had to make some changes to their SP settings such as name ID format, signing/encryption settings and adding the NameID to the logout request, and now Logout is starting to work (the IdP seems to think that it does at least), but the application never gets the LogoutResponse.

Note that the destination has a query-string argument of ?sls    (really not my choice...)



2018-08-31 07:40:44,533 - DEBUG [PROTOCOL_MESSAGE:121] - 
<?xml version="1.0" encoding="UTF-8"?>
<samlp:LogoutRequest
    Destination="https://test-internal-shibboleth.otago.ac.nz/idp/profile/SAML2/Redirect/SLO"
    ID="ONELOGIN_45d83bdf21a1a9af410d5a2f7d2cea1182e26116"
    IssueInstant="2018-08-30T19:40:44Z" Version="2.0"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
        xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer>https://ckerr-python3-saml-demo.lab/metadata/</saml:Issuer>
    <saml:NameID
        Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
        NameQualifier="https://test-internal-shibboleth.otago.ac.nz/idp/shibboleth" SPNameQualifier="https://ckerr-python3-saml-demo.lab/metadata/">AAdzZWFsZXIxymkoKS9bAc+iMf8tQeHx66CUNViIW8O6WJc6sty6vlx8GwbaCrzY7bjvVlPqXtq4AILJdavHx3gRn6DsLvBME3+v48L5cghdfmlQoRrn9mL+WALGtEGa6GoOOiN0qHqQDMKyOfmcVnla9thKKucFH4KB5rs=</saml:NameID>
    <samlp:SessionIndex>_1d8aaf27ad4857817394ff945c256eeb</samlp:SessionIndex>
</samlp:LogoutRequest>



2018-08-31 07:40:44,932 - DEBUG [net.shibboleth.idp.saml.profile.impl.SpringAwareMessageEncoderFactory:100] - Looking up message encoder based on binding URI: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
2018-08-31 07:40:44,942 - DEBUG [PROTOCOL_MESSAGE:70] - 
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:LogoutResponse
    Destination="https://ckerr-python3-saml-demo.lab/?sls"
    ID="_04b12d4755c8c6d8e7905baca4515f17"
    InResponseTo="ONELOGIN_45d83bdf21a1a9af410d5a2f7d2cea1182e26116"
    IssueInstant="2018-08-30T19:40:44.930Z" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://test-internal-shibboleth.otago.ac.nz/idp/shibboleth</saml2:Issuer>
    <saml2p:Status>
        <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </saml2p:Status>
</saml2p:LogoutResponse>

My understanding is that the IdP is doing an asynchronous logout in response to the SP-initiated logout (so the user flow terminates at the IdP logout completed page).

Looking at my browser developer tools and SP application logs, I see the SAMLResponse being received as

https://ckerr-python3-saml-demo.lab/?SAMLResponse=...&RelayState=...&SigAlg=...&Signature=...

Note that the sls query-string argument is missing as received by the SP (although it is there in the Destination attribute), which means the application session is not logged out (the handler does not get hit)

I've since changed their demo application to use a logout endpoint of /sls instead of /?sls (and adjusting the metadata to match), and the problem goes away (once you fix up some other issues...)

Trying to determine if this could be considered buggy behaviour, I had a look at the latest SAML 2.0 spec + Errata

    SAML 2.0 Spec w/ Errata
    https://www.oasis-open.org/committees/download.php/35387/sstc-saml-bindings-errata-2.0-wd-05-diff.pdf
     
    Section 3.4.4 Message Encoding (HTTP-Redirect binding)
 
        A URL encoding MUST place the message entirely within the URL query string, and MUST
        reserve the rest of the URL for the endpoint of the message recipient.


It doesn't seem to say that the entirely of the query-string argument is reserved for the SAML message, and it does refer to a 'Reserved' query-string parameters such as SAMLEncoding, which would seem to imply that other query-string parameters would be legal; one could even read it that Shibboleth is clearly doing the wrong thing by stripping not including any query-string argument (and fragment, I suppose) in the endpoint URL.

So given the above, it seems that this is a bug in Shibboleth IdP version 3.2.1 (or perhaps OpenSAML). I don't see any mention of this in the issues given in the release notes for later versions.

Cheers,
Cameron


Cameron Kerr 
Systems Engineer