Question: Configuration to verify that signed response originates from IDP

[Rob1080]

Code Version

pysaml 4.5

Expected Behavior

When the idp changes their certificate, and we we have the old cert configured in the metadata, I'd expect a failure to occur.

Current Behavior

The response passes and the signed responses is confirmed to be valid, I'm assuming from the cert that's included in the response.

Question

Am I missing something in my configuration or should it by default be checking that the cert in the metadata is the same as the cert in response?

Thanks
Rob

[jkakavas]

Hi Rob,

The only way to observe this behavior is either if your pysaml2 based SP is configured without metadata for the IDP ( CONFIG object missing the metadata key), or if the metadata file of the IDP does not contain any keys (with use="signing").

You can always make sure that the certificates that are sent in <ds:KeyInfo><ds:X509Data><ds:X509Certificate> will never end up being trusted, by setting

only_use_keys_in_metadata: True

in your config. This is probably be changed to be the default value for this parameter eitherway.

[Rob1080]

Thanks @jkakavas.
In my config I have:
'metadata': { 'inline': [xml], }
where xml is the metadata for the IDP.
The use="signing" cert is set in that metadata.

I don't have only_use_keys_in_metadata=True set. Where about in the config file should one set this? Is it at the same level as metadata key e.g. { "entityid": entity_id, "name": "example", 'metadata': { 'inline': [xml], }, only_use_keys_in_metadata:True

Thanks
Rob

[jkakavas]

'metadata': { 'inline': [xml], }

is strange, do you programmatically read the xml file and load it in the xml string? It might be helpful to share the whole config ( maybe scrubbing any sensitive info ). The working assumption here is that the above is and have been wrong, so that your Service Provider was always trusting the certificate that was contained in the SAML Response, disregarding the one in metadata.

Where about in the config file should one set this? Is it at the same level as metadata key e.g. { "entityid": entity_id, "name": "example", 'metadata': { 'inline': [xml], }, only_use_keys_in_metadata:True

Yes, that should do the trick

[Rob1080]

Thanks @jkakavas
I followed the example here: https://github.com/jpf/okta-pysaml2-example/blob/master/app.py
with a few changes.

xml = """<?xml version="1.0" encoding="UTF-8"?><md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://auth........../isam/sps/SAML/saml20">
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>cert...</X509Certificate>
</X509Data>
</KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>cert...</X509Certificate>
</X509Data>
</KeyInfo>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
</md:KeyDescriptor>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://auth......./isam/sps/SAML/saml20/slo"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://auth........../isam/sps/SAML/saml20/slo"/>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://auth............../isam/sps/SAML/saml20/login"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://auth..................../isam/sps/SAML/saml20/login"/>
</md:IDPSSODescriptor>
<md:Organization>
<md:OrganizationName xml:lang="en">IBM Quick Connect</md:OrganizationName>
<md:OrganizationDisplayName xml:lang="en">IBM Quick Connect</md:OrganizationDisplayName>
<md:OrganizationURL xml:lang="en"/>
</md:Organization>
</md:EntityDescriptor>"""

return {
        "entityid": entity_id,
        "name": "example",      
        'metadata': {
            'inline': [xml],
        },
        'service': {
            'sp': {
                'endpoints': {
                    'assertion_consumer_service': [
                        (https_acs_url, BINDING_HTTP_POST)
                    ],
                    "single_logout_service": [(https_slo_url,
                                               BINDING_HTTP_POST)]
                },
               'allow_unsolicited': True,               
                'authn_requests_signed': True,
                'logout_requests_signed': True,
                'want_assertions_signed': True,
                'want_response_signed': True,
            },

        },

        "xmlsec_binary": xmlsec_path,
        "key_file": "./keys/key.pem",
        "cert_file": "./keys/cert.pem"
    }

[jkakavas]

That should work fine, as in it should be able to read the certificates from the metadata and thus disregard the one in the SAML Response. I don't have a testing environment to replicate this right now, will try and do later unless other folk beat me to it.

Can you look at your logs and/or use a browser plugin like SAMLTracer (https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/) to verify that the certificate that is included in the SAML response has changed from what you actually have in your metadata ( thus indicating that the private key the IDP uses to sign the SAML message has indeed changed ) ?

[peppelinux]

Don't know if the things went definitely fine and hope so.
My first impression... Or better my first action on this kind of problem is always a check and a resync of the respective metadata, when possibile, by both sides.

Anyway that's something that can be handled with some documentation hints and probably we'll continue this topic here:
#706