Christian, I updated the description based on the SRU template and also modified the changelogs and commit messages.
** Description changed: - See comments on the bug: - https://bugs.launchpad.net/charm-keystone-saml-mellon/+bug/1833134 + [Impact] + + * Usage of ECP is not possible with mod_auth_mellon because the AuthnRequest message has the Destination attribute set incorrectly; + * https://dev.entrouvert.org/issues/34409; + * Blocks the enablement of a feature 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" and "HTTP POST" bindings only (per the spec, sections 3.4.5.2 and 3.5.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 + [Test Case] + + * Deploy an Identity Provider with PAOS binding and ECP handling support or use a publicly available one (e.g. samltest.id shibboleth instance); + * Deploy a Service Provider (e.g. Keystone) and protect its relevant URLs via mod_auth_mellon (e.g. via charm-keystone-mellon); + * Use an ECP client (openstack keystone client with v3samlpassword authentication plugin) to access the service provider (e.g. try to obtain a Keystone token); + * Validate that the IdP did not error our based on the request provided by the ECP client; + * Validate by the IdP logs that the Destination attribute of AuthnRequest was NOT present (unset). + + + [Regression Potential] + + * The regression potential is minimal as the patch functionally adds a + simple PAOS-related code branch to avoid including the Destination + attribute. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1833299 Title: lasso includes "Destination" attribute in SAML AuthnRequest populated with SP AssertionConsumerServiceURL when ECP workflow is used which leads to IdP-side errors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lasso/+bug/1833299/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
