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
See comments on the bug: /bugs.launchpad .net/charm- keystone- saml-mellon/ +bug/1833134
https:/
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="_798F26F737 76E684A463559CD B77D080" Version="2.0" IssueInstant= "2019-06- 18T16:54: 25Z" Destination="https:/ /keystone. maas:5000/ v3/OS-FEDERATIO N/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" AssertionConsum erServiceURL= "https:/ /keystone. maas:5000/ v3/OS-FEDERATIO N/identity_ providers/ samltestid/ protocols/ saml2/auth/ mellon/ paosResponse"> /keystone. maas:5000/ v3/OS-FEDERATIO N/identity_ providers/ samltestid/ protocols/ saml2/auth</saml:Issuer> www.w3. org/2000/ 09/xmldsig#">
<saml:Issuer>https:/
<Signature xmlns="http://
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). docs.oasis- open.org/ security/ saml/v2. 0/saml- bindings- 2.0-os. pdf
http://
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.ReceivedEn dpointSecurityH andler: ?] - Message Handler: SAML message intended destination endpoint 'https:/ /keystone. maas:5000/ v3/OS-FEDERATIO N/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: /bugs.launchpad .net/charm- keystone- saml-mellon/ +bug/1833134/ comments/ 2
https:/