400 on invalid Logout request

[rcritten]

I've seen cases where a Logout requests fails because the requested logout session doesn't exist in mod_auth_mellon. I don't have a great reproducer but I saw this with some frequency when developing logout support in the Ipsilon IdP.

The problem with the 400 is that it causes SLO Redirect to blow up and is a pretty bad user experience.

I'm not completely sure what it should do here though. I don't think there is any downside in returning a valid LogoutResponse other than masking the fact that the user wasn't actually logged in. I'm not sure what benefit a user gets from the 400 though. Since there was no LogoutResponse the IdP will still think the user has that session and probably try to log them out again, and the LogoutResponse for the SP that initiated the logout might be lost in the mix too.

[olavmrk]

Hi,

I had a look at the code for logout request handling, at as far as I can tell, it should never abort with a "400 Bad Request"-error as long as the logout request is valid. There are two places where it can fail with a "400 Bad Request":

• Invalid logout request message
• Missing NameID in logout request

Both of these errors would indicate that the IdP is doing something wrong when it sent the request.

It can also return a "500 Internal Server" error if it is unable to process the logout request message or unable to build the LogoutResponse message. These errors should in general indicate that something is wrong inside mod_auth_mellon.

I don't see that being unable to find the session should lead to a failure to respond to the IdP. (It may result in the LogoutResponse sent to the IdP indicating some sort of error -- I'm not sure what the proper behavior should be here.)

Do you have some more information about what circumstances it fails in your case?

[rcritten]

Unfortunately no, it was always hit or miss. It was also an older version of mod_auth_mellon so perhaps it has been addressed. I tried forcing bad session logouts and wasn't able to reproduce this so I guess this can be closed until I come up with a reproducer.

[tweiand-10m2]

I am able to reproduce this consistently.

Configuration:
OS - Debian 8.2
mod_auth_mellon - Latest from github
IdP - WSO2 IS 5.0.0 SP1 & 5.1.0

Happens with stock builds and rebuilds of both apache2 and mod_auth_mellon (to get debug info).

I have GDB setup and going. The SAML Logout request happens fine. But, when the SAML Logout Response is processed auth_mellon_handler.c:682 (am_return_logout_response) has a null deference of 'logout->parent.remote_providerID'. I am able to get a 400 from auth_mellon_handler.c:791 (am_handle_logout_response).

This is on my local development system and a configuration I deployed to a sandbox environment.

Please let me know what I can provide to help with this!

[olavmrk]

Any chance you could share the exact LogoutRequest that your IdP sends to the SP? I.e. the full URL-encoded SAMLRequest query parameter.

[tweiand-10m2]

Of course! Gathering.

[tweiand-10m2]

All values captured with Firefox SAML tracer.

Logout response HTTP Information:

POST https://192.168.50.41/mellon/logout HTTP/1.1
Host: 192.168.50.41
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: https://localhost:9443/samlsso?sessionDataKey=7fc56411-a253-4bf9-b083-1ed3708db554
Cookie: mellon-edp-cookie=2fb24ddefbb1da857b5f142f8643bf6b
Content-Type: application/x-www-form-urlencoded
Content-Length: 3044

HTTP/?.? 400 Bad Request
Date: Mon, 18 Jan 2016 15:41:38 GMT
Server: Apache/2.4.10 (Debian)
Cache-Control: private, max-age=0, must-revalidate
Content-Length: 306
Connection: close
Content-Type: text/html; charset=iso-8859-1

Logout response HTTP parameters (long lines):

POST
SAMLResponse: PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNhbWwycDpMb2dvdXRSZXNwb25zZSBJRD0ia2JtZmRtamFlaWRkYm9vYWhnaWduZmVubm1vaGlwYW5ia2htcGZkZyIgSW5SZXNwb25zZVRvPSJfRjJBOTY0MjRCQ0M0NUNCRDI1QTczOUU0MUZGRTk5RUUiIElzc3VlSW5zdGFudD0iMjAxNi0wMS0xOFQxNTo0MTozOC44MjZaIiBWZXJzaW9uPSIyLjAiIHhtbG5zOnNhbWwycD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIj48c2FtbDI6SXNzdWVyIEZvcm1hdD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm5hbWVpZC1mb3JtYXQ6ZW50aXR5IiB4bWxuczpzYW1sMj0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+bG9jYWxob3N0PC9zYW1sMjpJc3N1ZXI+PGRzOlNpZ25hdHVyZSB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+PGRzOlNpZ25lZEluZm8+PGRzOkNhbm9uaWNhbGl6YXRpb25NZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzEwL3htbC1leGMtYzE0biMiLz48ZHM6U2lnbmF0dXJlTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI3JzYS1zaGExIi8+PGRzOlJlZmVyZW5jZSBVUkk9IiNrYm1mZG1qYWVpZGRib29haGdpZ25mZW5ubW9oaXBhbmJraG1wZmRnIj48ZHM6VHJhbnNmb3Jtcz48ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3BlZC1zaWduYXR1cmUiLz48ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+PC9kczpUcmFuc2Zvcm1zPjxkczpEaWdlc3RNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjc2hhMSIvPjxkczpEaWdlc3RWYWx1ZT54QWpyRXVPeTU0TTBNR3RkUXlZQWpoZWFiR1U9PC9kczpEaWdlc3RWYWx1ZT48L2RzOlJlZmVyZW5jZT48L2RzOlNpZ25lZEluZm8+PGRzOlNpZ25hdHVyZVZhbHVlPkNTSW8ybFFIVHpiVDF6Z1gxU2NnQ1RYWTdiNzJoNU15dHdUbUR3NVhwRm96OGZodmpTQkVIU1JqSGpHT2w5VDNaQ1haSStpUUZhTkIvU2RTT2NZNk5MUlR6WWFpM2VZOU1IV3F1RE96U3BvOWowbjA5NVM0ZWZIVTU3WjFneEJEUEVmZUFRZzZ1azNQUzNqTDdzYWNnckF0WkVVMjRuRDFUU2NLMmxwOStFUT08L2RzOlNpZ25hdHVyZVZhbHVlPjxkczpLZXlJbmZvPjxkczpYNTA5RGF0YT48ZHM6WDUwOUNlcnRpZmljYXRlPk1JSUNOVENDQVo2Z0F3SUJBZ0lFUzM0M2dqQU5CZ2txaGtpRzl3MEJBUVVGQURCVk1Rc3dDUVlEVlFRR0V3SlZVekVMTUFrR0ExVUVDQXdDUTBFeEZqQVVCZ05WQkFjTURVMXZkVzUwWVdsdUlGWnBaWGN4RFRBTEJnTlZCQW9NQkZkVFR6SXhFakFRQmdOVkJBTU1DV3h2WTJGc2FHOXpkREFlRncweE1EQXlNVGt3TnpBeU1qWmFGdzB6TlRBeU1UTXdOekF5TWpaYU1GVXhDekFKQmdOVkJBWVRBbFZUTVFzd0NRWURWUVFJREFKRFFURVdNQlFHQTFVRUJ3d05UVzkxYm5SaGFXNGdWbWxsZHpFTk1Bc0dBMVVFQ2d3RVYxTlBNakVTTUJBR0ExVUVBd3dKYkc5allXeG9iM04wTUlHZk1BMEdDU3FHU0liM0RRRUJBUVVBQTRHTkFEQ0JpUUtCZ1FDVXAvb1YxdldjOC9Ua1FTaUF2VG91c016T000YXNCMmlsdHIyUUtvem5pNWFWRnU4MThNcE9MWklyOExNblR6V2xsSnZ2YUE1UkFBZHBiRUNiKzQ4RmpiQmUwaHNlVWRONUhwd3ZuSC9EVzhaY2NHdms1M0k2T3JxN2hMQ3YxWkh0dU9Db2tnaHovQVRyaHlQcStRa3RNZlhuUlM0SHJLR0pUenhhQ2NVN09RSURBUUFCb3hJd0VEQU9CZ05WSFE4QkFmOEVCQU1DQlBBd0RRWUpLb1pJaHZjTkFRRUZCUUFEZ1lFQVc1d1BSN2NyMUxBZHErSXJSNDRpUWxSRzVJVENaWFk5aEkwUHlnTFAyckhBTmgrUFlmVG14YnVPbnlrTkd5aE02RmpGTGJXMnVaSFFUWTFqTXJQcHJqT3JteUs1c2pKUk80ZDFEZUdIVC9ZbklqczlKb2dSS3Y0WEhFQ3dMdElWZEFiSWRXSEV0VlpKeU1Ta3RjeXlzRmN2dWhQUUs4UWMvRS9XcTh1SFNDbz08L2RzOlg1MDlDZXJ0aWZpY2F0ZT48L2RzOlg1MDlEYXRhPjwvZHM6S2V5SW5mbz48L2RzOlNpZ25hdHVyZT48c2FtbDJwOlN0YXR1cz48c2FtbDJwOlN0YXR1c0NvZGUgVmFsdWU9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpzdGF0dXM6U3VjY2VzcyIvPjwvc2FtbDJwOlN0YXR1cz48L3NhbWwycDpMb2dvdXRSZXNwb25zZT4=
RelayState: /

Response XML (from Firefox):

<saml2p:LogoutResponse ID="kbmfdmjaeiddbooahgignfennmohipanbkhmpfdg"
                       InResponseTo="_F2A96424BCC45CBD25A739E41FFE99EE"
                       IssueInstant="2016-01-18T15:41:38.826Z"
                       Version="2.0"
                       xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
                       >
    <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
                  xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                  >localhost</saml2:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
            <ds:Reference URI="#kbmfdmjaeiddbooahgignfennmohipanbkhmpfdg">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
                <ds:DigestValue>xAjrEuOy54M0MGtdQyYAjheabGU=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>CSIo2lQHTzbT1zgX1ScgCTXY7b72h5MytwTmDw5XpFoz8fhvjSBEHSRjHjGOl9T3ZCXZI+iQFaNB/SdSOcY6NLRTzYai3eY9MHWquDOzSpo9j0n095S4efHU57Z1gxBDPEfeAQg6uk3PS3jL7sacgrAtZEU24nD1TScK2lp9+EQ=</ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>MIICNTCCAZ6gAwIBAgIES343gjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJVUzELMAkGA1UECAwCQ0ExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxDTALBgNVBAoMBFdTTzIxEjAQBgNVBAMMCWxvY2FsaG9zdDAeFw0xMDAyMTkwNzAyMjZaFw0zNTAyMTMwNzAyMjZaMFUxCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzENMAsGA1UECgwEV1NPMjESMBAGA1UEAwwJbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCUp/oV1vWc8/TkQSiAvTousMzOM4asB2iltr2QKozni5aVFu818MpOLZIr8LMnTzWllJvvaA5RAAdpbECb+48FjbBe0hseUdN5HpwvnH/DW8ZccGvk53I6Orq7hLCv1ZHtuOCokghz/ATrhyPq+QktMfXnRS4HrKGJTzxaCcU7OQIDAQABoxIwEDAOBgNVHQ8BAf8EBAMCBPAwDQYJKoZIhvcNAQEFBQADgYEAW5wPR7cr1LAdq+IrR44iQlRG5ITCZXY9hI0PygLP2rHANh+PYfTmxbuOnykNGyhM6FjFLbW2uZHQTY1jMrPprjOrmyK5sjJRO4d1DeGHT/YnIjs9JogRKv4XHECwLtIVdAbIdWHEtVZJyMSktcyysFcvuhPQK8Qc/E/Wq8uHSCo=</ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <saml2p:Status>
        <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </saml2p:Status>
</saml2p:LogoutResponse>

WSO2 IS redirect HTML (long lines):

<html>
    <body>
            <p>You are now redirected back to https://192.168.50.41/mellon/logout 
            If the redirection fails, please click the post button.</p>

            <form method='post' action='https://192.168.50.41/mellon/logout'>
                <p>
                    <input type='hidden' name='SAMLResponse' value='PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNhbWwycDpMb2dvdXRSZXNwb25zZSBJRD0ia2JtZmRtamFlaWRkYm9vYWhnaWduZmVubm1vaGlwYW5ia2htcGZkZyIgSW5SZXNwb25zZVRvPSJfRjJBOTY0MjRCQ0M0NUNCRDI1QTczOUU0MUZGRTk5RUUiIElzc3VlSW5zdGFudD0iMjAxNi0wMS0xOFQxNTo0MTozOC44MjZaIiBWZXJzaW9uPSIyLjAiIHhtbG5zOnNhbWwycD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIj48c2FtbDI6SXNzdWVyIEZvcm1hdD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm5hbWVpZC1mb3JtYXQ6ZW50aXR5IiB4bWxuczpzYW1sMj0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+bG9jYWxob3N0PC9zYW1sMjpJc3N1ZXI+PGRzOlNpZ25hdHVyZSB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+PGRzOlNpZ25lZEluZm8+PGRzOkNhbm9uaWNhbGl6YXRpb25NZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzEwL3htbC1leGMtYzE0biMiLz48ZHM6U2lnbmF0dXJlTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI3JzYS1zaGExIi8+PGRzOlJlZmVyZW5jZSBVUkk9IiNrYm1mZG1qYWVpZGRib29haGdpZ25mZW5ubW9oaXBhbmJraG1wZmRnIj48ZHM6VHJhbnNmb3Jtcz48ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3BlZC1zaWduYXR1cmUiLz48ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+PC9kczpUcmFuc2Zvcm1zPjxkczpEaWdlc3RNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjc2hhMSIvPjxkczpEaWdlc3RWYWx1ZT54QWpyRXVPeTU0TTBNR3RkUXlZQWpoZWFiR1U9PC9kczpEaWdlc3RWYWx1ZT48L2RzOlJlZmVyZW5jZT48L2RzOlNpZ25lZEluZm8+PGRzOlNpZ25hdHVyZVZhbHVlPkNTSW8ybFFIVHpiVDF6Z1gxU2NnQ1RYWTdiNzJoNU15dHdUbUR3NVhwRm96OGZodmpTQkVIU1JqSGpHT2w5VDNaQ1haSStpUUZhTkIvU2RTT2NZNk5MUlR6WWFpM2VZOU1IV3F1RE96U3BvOWowbjA5NVM0ZWZIVTU3WjFneEJEUEVmZUFRZzZ1azNQUzNqTDdzYWNnckF0WkVVMjRuRDFUU2NLMmxwOStFUT08L2RzOlNpZ25hdHVyZVZhbHVlPjxkczpLZXlJbmZvPjxkczpYNTA5RGF0YT48ZHM6WDUwOUNlcnRpZmljYXRlPk1JSUNOVENDQVo2Z0F3SUJBZ0lFUzM0M2dqQU5CZ2txaGtpRzl3MEJBUVVGQURCVk1Rc3dDUVlEVlFRR0V3SlZVekVMTUFrR0ExVUVDQXdDUTBFeEZqQVVCZ05WQkFjTURVMXZkVzUwWVdsdUlGWnBaWGN4RFRBTEJnTlZCQW9NQkZkVFR6SXhFakFRQmdOVkJBTU1DV3h2WTJGc2FHOXpkREFlRncweE1EQXlNVGt3TnpBeU1qWmFGdzB6TlRBeU1UTXdOekF5TWpaYU1GVXhDekFKQmdOVkJBWVRBbFZUTVFzd0NRWURWUVFJREFKRFFURVdNQlFHQTFVRUJ3d05UVzkxYm5SaGFXNGdWbWxsZHpFTk1Bc0dBMVVFQ2d3RVYxTlBNakVTTUJBR0ExVUVBd3dKYkc5allXeG9iM04wTUlHZk1BMEdDU3FHU0liM0RRRUJBUVVBQTRHTkFEQ0JpUUtCZ1FDVXAvb1YxdldjOC9Ua1FTaUF2VG91c016T000YXNCMmlsdHIyUUtvem5pNWFWRnU4MThNcE9MWklyOExNblR6V2xsSnZ2YUE1UkFBZHBiRUNiKzQ4RmpiQmUwaHNlVWRONUhwd3ZuSC9EVzhaY2NHdms1M0k2T3JxN2hMQ3YxWkh0dU9Db2tnaHovQVRyaHlQcStRa3RNZlhuUlM0SHJLR0pUenhhQ2NVN09RSURBUUFCb3hJd0VEQU9CZ05WSFE4QkFmOEVCQU1DQlBBd0RRWUpLb1pJaHZjTkFRRUZCUUFEZ1lFQVc1d1BSN2NyMUxBZHErSXJSNDRpUWxSRzVJVENaWFk5aEkwUHlnTFAyckhBTmgrUFlmVG14YnVPbnlrTkd5aE02RmpGTGJXMnVaSFFUWTFqTXJQcHJqT3JteUs1c2pKUk80ZDFEZUdIVC9ZbklqczlKb2dSS3Y0WEhFQ3dMdElWZEFiSWRXSEV0VlpKeU1Ta3RjeXlzRmN2dWhQUUs4UWMvRS9XcTh1SFNDbz08L2RzOlg1MDlDZXJ0aWZpY2F0ZT48L2RzOlg1MDlEYXRhPjwvZHM6S2V5SW5mbz48L2RzOlNpZ25hdHVyZT48c2FtbDJwOlN0YXR1cz48c2FtbDJwOlN0YXR1c0NvZGUgVmFsdWU9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpzdGF0dXM6U3VjY2VzcyIvPjwvc2FtbDJwOlN0YXR1cz48L3NhbWwycDpMb2dvdXRSZXNwb25zZT4='>
                    <input type='hidden' name='RelayState' value='/'>
                    <!--$additionalParams-->
                    <button type='submit'>POST</button>
                </p>
            </form>
            <script type='text/javascript'>
                document.forms[0].submit();
            </script>
        </body>
</html>

Decoded and pretty-printed response from IDP:

<?xml version="1.0" encoding="UTF-8"?>
<saml2p:LogoutResponse xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" ID="kbmfdmjaeiddbooahgignfennmohipanbkhmpfdg" InResponseTo="_F2A96424BCC45CBD25A739E41FFE99EE" IssueInstant="2016-01-18T15:41:38.826Z" Version="2.0">
  <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">localhost</saml2:Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
      <ds:Reference URI="#kbmfdmjaeiddbooahgignfennmohipanbkhmpfdg">
        <ds:Transforms>
          <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        </ds:Transforms>
        <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
        <ds:DigestValue>xAjrEuOy54M0MGtdQyYAjheabGU=</ds:DigestValue>
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>CSIo2lQHTzbT1zgX1ScgCTXY7b72h5MytwTmDw5XpFoz8fhvjSBEHSRjHjGOl9T3ZCXZI+iQFaNB/SdSOcY6NLRTzYai3eY9MHWquDOzSpo9j0n095S4efHU57Z1gxBDPEfeAQg6uk3PS3jL7sacgrAtZEU24nD1TScK2lp9+EQ=</ds:SignatureValue>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>MIICNTCCAZ6gAwIBAgIES343gjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJVUzELMAkGA1UECAwCQ0ExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxDTALBgNVBAoMBFdTTzIxEjAQBgNVBAMMCWxvY2FsaG9zdDAeFw0xMDAyMTkwNzAyMjZaFw0zNTAyMTMwNzAyMjZaMFUxCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzENMAsGA1UECgwEV1NPMjESMBAGA1UEAwwJbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCUp/oV1vWc8/TkQSiAvTousMzOM4asB2iltr2QKozni5aVFu818MpOLZIr8LMnTzWllJvvaA5RAAdpbECb+48FjbBe0hseUdN5HpwvnH/DW8ZccGvk53I6Orq7hLCv1ZHtuOCokghz/ATrhyPq+QktMfXnRS4HrKGJTzxaCcU7OQIDAQABoxIwEDAOBgNVHQ8BAf8EBAMCBPAwDQYJKoZIhvcNAQEFBQADgYEAW5wPR7cr1LAdq+IrR44iQlRG5ITCZXY9hI0PygLP2rHANh+PYfTmxbuOnykNGyhM6FjFLbW2uZHQTY1jMrPprjOrmyK5sjJRO4d1DeGHT/YnIjs9JogRKv4XHECwLtIVdAbIdWHEtVZJyMSktcyysFcvuhPQK8Qc/E/Wq8uHSCo=</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
  </ds:Signature>
  <saml2p:Status>
    <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </saml2p:Status>
</saml2p:LogoutResponse>

[tweiand-10m2]

Thank you for the help on this! I hoped to have enough time to do all the root-cause-analysis. But, time got away from me.

[KevinDuringWork]

I have also been able to reproduce this consistently to the point where I'm unable to log out entirely.

IDP: Ipsilon 1.1
OS: CentOS 7.1
Apache 2.4
latest: auth_mod_mellon

I've been getting seeing the following two messages regularly in Apache:

"Error processing logout request message. No session found for NameID ..."
"Error validating logout request. Lasso error: [304] Unknown principal on logout, referer: ..."

I noticed that after immediately after 'am_get_request_session_by_nameid' in 'auth_mellon_handler.c'
the session was showing NULL where in 'auth_mellon_cache.c' it's not NULL.

it looks like adding
'apr_global_mutex_unlock(mod_cfg->lock);' right before the 'return e' seems to fix it in 'auth_mellon_cache.c' and at least made Apache throw the second error.

[KevinDuringWork]

Apologies more hack fixes and jump to conclusions analysis,

I've commented out the 'lasso_logout_validate_request' block and it seems logout appears to be working again for me. This little snipplet seems to be the part that's giving me trouble in lasso [lasso_saml20_logout_validate_request]

lasso_foreach(i, logout_session_indexes) {
            lasso_foreach(j, local_session_indexes) {
                if (lasso_strisequal((char*)i->data, (char*)j->data)) {
                    ok = 1;
                }
            }
        }

Ipsilon is passing in which I'm assuming is logout_session_indexes. But what's creating local_session_indexes? How does the IDP know about session_id of the cache?

[rcritten]

Each login session returns an ID. This ID is returned in the logout request and AFAIU they need to match otherwise the logout request blows up. If you put Ipsilon into debug mode it has fairly verbose output of the logout sequence which will show the session ID at login and those on logout. I forget if mod_auth_mellon also logs these when the Apache LogLevel is Debug but I think it does. You should be able to use those to correlate and determine if Ipsilon is sending a bad request.

[KevinDuringWork]

Hey Rob,

Can I just use the Firefox SAML tracker to sniff out the samlp:SessionIndex ?

[Off-Topic] I just tried to logout directly from the IDP (Ipsilon) and SAML tracker it is sending a DIFFERENT username than my own.

[rcritten]

Sure, the SAML tracker should work. As for the username it depends on what NameID is configured. It could be replaced by a UUID, for example.

[KevinDuringWork]

Hey Rob,

I'm looking at the the sqllite session database. I see over 800+ entries for may username alone. Maybe it's just my weird login behavior but how often does it get cleaned? Can I just nuke the sqllite file every week?

[rcritten]

It is probably best to not confuse this issue with Ipsilon-specific questions. I'd look at https://fedorahosted.org/ipsilon/wiki/Development

[olavmrk]

Hi,

sorry for not being able to follow up on this issue.

First of all, a clarification as to how SessionIndex & NameID is supposed to work:

When the IdP supporst logout, it must return a NameID and a SessionIndex in its authentication response. The NameID is carried in the <saml:Subject>-element, while the SessionIndex is an attribute on the <saml:AuthnStatement>-element.

During logout, the IdP must send the same NameID as in the authentication response. In addition it can send zero or more <samlp:SessionIndex>-elements. If no <samlp:SessionIndex>-elements are sent, all sessions matching the NameID should be terminated. However, if the IdP specifies one or more <samlp:SessionIndex>-elements, only the session matching those session indexes should be terminated.

So, the important parts to check is that the NameID in the LogoutRequest matches the NameID in the authentication response and that the SessionIndex from the AuthnStatement in the authentication response mathces the SessionIndex in the LogoutRequest.

If they don't, that would cause logout not to work. However, it probably shouldn't return a 400 Bad Request, but rather a LogoutResponse with an error code.

(As I side note, I haven't yet seen any IdP sending more than one <samlp:SessionIndex>-element in the logout request.)

[KevinDuringWork]

Hey Olav and Rob,

Thanks for the replies. Quick update; we've accepted a recent Ipsilon patch (sqlite cleanup) that resembles this issue and are testing with that patch in place.

I've managed to reproduce the original issue with a phantomjs script that logs in -> waits(random minutes) -> logs outs. Especially when ran concurrently. I haven't found the time to do a more in depth analysis as I need to examine both ipsilon logs and mellon logs.

Best,
Kevin

[KevinDuringWork]

Can this ticket be closed? The issues appears to have originated in Ipsilon
https://ipsilon-project.org/advisory/CVE-2016-8638.txt

[tweiand-10m2]

I am not in a spot to test this. Sorry I cannot be of help.

[olavmrk]

@KevinDuringWork: Thanks for the reminder. Since there have been changes to Ipsilon related to this, I'm inclined to assume that it has fixed the error unless someone steps forward with a error. I'm closing this issue for now. If someone has the same error after updating Ipsilon, please let us know, and we can reopen this ticket.

[rcritten]

I don't think the issue was related to the CVE but we sure haven't seen this in a long time so it was likely our issue in one way or the other. +1 on closing.

[tuxcrafter]

[Fri Mar 22 23:48:59.800217 2019] [auth_mellon:warn] [pid 4310] [client 92.111.168.246:48332] User attempted to initiate logout without being loggged in., referer: https://mail.test.nl/h/logout
[Fri Mar 22 23:49:04.627237 2019] [auth_mellon:warn] [pid 4310] [client 92.111.168.246:48332] Error validating logout request. Lasso error: [304] Unknown principal on logout

I am still having similar or the same issues with
centos7: mod_auth_mellon-0.14.0-2.el7.x86_64
f28: ipsilon

I am having a really hard time debugging SLO issues and can use some help, and can provide access to the systems.

https://pagure.io/ipsilon/issue/316

steffow/meteor-accounts-saml#33

[tuxcrafter]

I am still getting a beautiful Internal Server Error with "Error validating logout request. Lasso error: [304] Unknown principal on logout, referer:...."

Can somebody help out?

[ddarling85]

@tuxcrafter We are experiencing a similar issue. Were you ever able to resolve yours?

[schmidty]

Hi @olavmrk... we are experiencing a similar issue with the SAML "logout" using Apache 2.2.5 for webserver, mod_auth_mellon for SP and Forgerock OpenAM 13.5 for IDP. When we logout the logout appears to communicate with the SP to IDP and logs out the user but the redirect shows a 400 "Bad Request" in the browser? Here is our logout url on client side: https://dev-site.org/saml/logout?ReturnTo=/secret/

In using the Chrome SAML inspector I noticed this in the JSON dump;

   "response": {
      "status": 200,
      "statusText": "OK",
      "httpVersion": "http/1.1",
...
      "redirectURL": "",
      "headersSize": -1,
      "bodySize": 0,
      "_transferSize": 0
  }
...
   "response_data": [
      {
        "name": "status",
        "value": 200,
        "$$hashKey": "1XM"
...
    {
        "name": "redirectURL",
        "value": "",
        "$$hashKey": "1XV"
      },