Comment 0 for bug 1833299

Revision history for this message
Dmitrii Shcherbakov (dmitriis) wrote :

See comments on the bug:
https://bugs.launchpad.net/charm-keystone-saml-mellon/+bug/1833134

Lasso is used by libapache2-mod-auth-mellon to create SAML messages. When ECP profile (http://docs.oasis-open.org/security/saml/Post2.0/saml-ecp/v2.0/cs01/saml-ecp-v2.0-cs01.pdf) is used it populates an AuthnRequest with the "Destination" attribute as follows:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_798F26F73776E684A463559CDB77D080" Version="2.0" IssueInstant="2019-06-18T16:54:25Z" Destination="https://keystone.maas:5000/v3/OS-FEDERATION/identity_providers/samltestid/protocols/saml2/auth/mellon/paosResponse" Consent="urn:oasis:names:tc:SAML:2.0:consent:current-implicit" SignType="0" SignMethod="0" ForceAuthn="false" IsPassive="false" AssertionConsumerServiceURL="https://keystone.maas:5000/v3/OS-FEDERATION/identity_providers/samltestid/protocols/saml2/auth/mellon/paosResponse">
    <saml:Issuer>https://keystone.maas:5000/v3/OS-FEDERATION/identity_providers/samltestid/protocols/saml2/auth</saml:Issuer>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

This triggers the Destination attribute validation logic relevant for "HTTP Redirect Binding" only (per the spec, section 3.4.5.2), not SOAP or PAOS bindings (sections before 3.4).
http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

For example, Shibboleth IdP (samltest.id) errors out as follows as the Destination attribute was populated with an SP URL:

2019-06-18 16:54:25,435 - ERROR [org.opensaml.saml.common.binding.security.impl.ReceivedEndpointSecurityHandler:?] - Message Handler: SAML message intended destination endpoint 'https://keystone.maas:5000/v3/OS-FEDERATION/identity_providers/samltestid/protocols/saml2/auth/mellon/paosResponse' did not match the recipient endpoint 'https://samltest.id/idp/profile/SAML2/SOAP/ECP'

For ECP it makes sense to avoid inclusion of the "Destination" attribute to AuthnRequest (see https://bugs.launchpad.net/charm-keystone-saml-mellon/+bug/1833134/comments/3).

The attached patch is merely an illustration that not using Destination with ECP results in a successful authentication:
https://bugs.launchpad.net/charm-keystone-saml-mellon/+bug/1833134/comments/2