On Wed., Jul. 17, 2019, 01:35 Christian Ehrhardt , <
<email address hidden>> wrote:
> @Dmitriis - I'd expect this testing and verification is on you as you
> have done so before, so give it a go once you have some time.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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
>
> Status in lasso package in Ubuntu:
> Fix Released
> Status in lasso source package in Bionic:
> Fix Committed
> Status in lasso source package in Disco:
> Fix Committed
>
> Bug description:
> [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).
>
> [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.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/lasso/+bug/1833299/+subscriptions
>
Will do.
On Wed., Jul. 17, 2019, 01:35 Christian Ehrhardt , <
<email address hidden>> wrote:
> @Dmitriis - I'd expect this testing and verification is on you as you /bugs.launchpad .net/bugs/ 1833299 erServiceURL when ECP workflow is used which /dev.entrouvert .org/issues/ 34409; /bugs.launchpad .net/charm- keystone- saml-mellon/ +bug/1833134; mod-auth- mellon to create SAML messages. docs.oasis- open.org/ security/ saml/Post2. 0 v2.0/cs01/ saml-ecp- v2.0-cs01. pdf) is used it populates an "urn:oasis: names:tc: SAML:2. 0:protocol" "urn:oasis: names:tc: SAML:2. 0:assertion" 76E684A463559CD B77D080" Version="2.0" "2019-06- 18T16:54: 25Z" Destination=" /keystone. maas:5000/ v3/OS-FEDERATIO N/identity_ providers/ samltestid/ protocols/ saml2/auth/ mellon/ paosResponse" "urn:oasis: names:tc: SAML:2. 0:consent: current- implicit" SignType="0" erServiceURL= " /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 www.w3. org/2000/ 09/xmldsig#"> docs.oasis- open.org/ security/ saml/v2. 0/saml- bindings- 2.0-os. pdf saml.common. binding. security. impl.ReceivedEn dpointSecurityH andler: ?] /keystone. maas:5000/ v3/OS- identity_ providers/ samltestid/ protocols/ saml2/auth/ mellon/ paosResponse' /samltest. id/idp/ profile/ SAML2/SOAP/ ECP' /bugs.launchpad .net/charm- saml-mellon/ +bug/1833134/ comments/ 3). mellon) ; /bugs.launchpad .net/ubuntu/ +source/ lasso/+ bug/1833299/ +subscriptions
> have done so before, so give it a go once you have some time.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> lasso includes "Destination" attribute in SAML AuthnRequest populated
> with SP AssertionConsum
> leads to IdP-side errors
>
> Status in lasso package in Ubuntu:
> Fix Released
> Status in lasso source package in Bionic:
> Fix Committed
> Status in lasso source package in Disco:
> Fix Committed
>
> Bug description:
> [Impact]
>
> * Usage of ECP is not possible with mod_auth_mellon because the
> AuthnRequest message has the Destination attribute set incorrectly;
> * https:/
> * Blocks the enablement of a feature
> https:/
>
> Lasso is used by libapache2-
> When ECP profile (http://
> /saml-ecp/
> AuthnRequest with the "Destination" attribute as follows:
>
> <samlp:AuthnRequest xmlns:samlp=
> xmlns:saml=
> ID="_798F26F737
> IssueInstant=
> https:/
> Consent=
> SignMethod="0" ForceAuthn="false" IsPassive="false"
> AssertionConsum
> https:/
> ">
> <saml:Issuer>
> https:/
> </saml:Issuer>
> <Signature xmlns="http://
>
> 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://
>
> 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.
> - Message Handler: SAML message intended destination endpoint
> 'https:/
>
> FEDERATION/
> did not match the recipient endpoint
> 'https:/
>
> For ECP it makes sense to avoid inclusion of the "Destination"
> attribute to AuthnRequest (see https:/
> keystone-
>
> [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-
> * 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.
>
> To manage notifications about this bug go to:
> https:/
>