Add flexibility to the slo implementation so compression isn't required.

[jeremyschiff]

We don't currently have a way of switching off compression in SLO, please give us the flexibility. Some providers aren't compressing, and it's throwing an error and there is no way to compensate.

[coveralls]

Coverage remained the same at 96.029% when pulling 3dc216e on jeremyschiff:master into a246326 on onelogin:master.

[coveralls]

Coverage remained the same at 96.029% when pulling 3dc216e on jeremyschiff:master into a246326 on onelogin:master.

[coveralls]

Coverage remained the same at 96.029% when pulling 3dc216e on jeremyschiff:master into a246326 on onelogin:master.

[pitbulk]

From SAML standard, SAML bindings - 3.4.4

A query string parameter named SAMLEncoding is reserved to identify the encoding mechanism used. If
this parameter is omitted, then the value is assumed to be urn:oasis:names:tc:SAML:2.0:bindings:URL-Encoding:DEFLATE.

All endpoints that support this binding MUST support the DEFLATE encoding

Can you share an example of what you are receiving from IdPs?

Rather than pass that parameter to the process_slo method, toolkit should verify if there is a SAMLEncoding parameter, check that it is different than the urn:oasis:names:tc:SAML:2.0:bindings:URL-Encoding:DEFLATE value and in this case, use the ignore_zip flag.

Similar should be applied to the OneLogin_Saml2_Logout_Request where I don't know why the ignore_zip flag is always enabled.

Can you confirm the IdPs are sending SAMLEncoding parameter?

[jeremyschiff]

The IdP is Okta. Here is my configuration:

{
    "strict": true,
    "debug": true,
    "sp": {
        "entityId": "http://localhost:8000/saml/metadata",
        "assertionConsumerService": {
            "url": "http://localhost:8000/saml/external/acs",
            "binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
        },
        "singleLogoutService": {
            "url": "http://localhost:8000/saml/external/sls",
            "binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
        },
        "NameIDFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
        "x509cert": <Redacted>,
        "privateKey": <Redacted>
    },
    "idp": {
        "entityId": "http://www.okta.com/<Redacted>",
        "singleSignOnService": {
            "url": "https://<Redacted>.oktapreview.com/app/<Redacted>/sso/saml",
            "binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
        },
        "singleLogoutService": {
            "url": "https://<Redacted>.oktapreview.com/app/<Redacted>/slo/saml",
            "binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
        },
        "x509cert": <Redacted>
    }
}

Here is the req object:
{'https': 'off', 'http_host': 'localhost', 'script_name': '/saml/external/sls', 'server_port': '8000', 'get_data': <QueryDict: {}>, 'post_data': <QueryDict: {'SAMLResponse': ['<Redacted (encoded, but not compressed)>'], 'RelayState': ['http://localhost:8000/backend/saml/logout']}>}

I have reviewed the documentation in Okta, and it has mentioned a challenge in that the response is in the POST body, not the get body. That was easily handled by setting the 'get_data' to be 'post_data', in the "req" object returned from prepare_django_request example in your demo project, but when it calls auth.process_slo, on line 144, it's still trying to decompress the response, which was why I requested these additional flags (so I can prevent the assert in utils.decode_base64_and_inflate from triggering and not ignoring the raise exception.

I'm glad to use any solution that resolves the problem. Where would the SAMLEncoding parameter be specified? It doesn't seem that one is set.

[pitbulk]

I see

On HTTP-POST binding, the data is not compressed.
But you are tricking the toolkit by injecting the POST data into the GET.

I will do the toolkit flexible and no raise an error when data is not compressed.

[jeremyschiff]

After this discussion, the other option is you to check the POST if it's not in the GET. This seems slightly better, as I won't have to "trick" the toolkit at all. I presume that's easy to do?

[pitbulk]

Is not that easy.

A Message is signed by the IdP and validated on the SP side.

The way signature is added on the HTTP-POST binding (Signature embedded) is different than the HTTP-Redirect binding (Signature as a GET parameter).

Even if you do the trick of send GET data to POST data, you will not be able to verify signatures.

So if you want to support Logout flows on HTTP-POST binding, you will need to extend this toolkit and implement that.

BTW, that said, I will relax the encoding part as you suggested so If you don't need to support Signature Validation, the trick will work.