[Bug 1833299] [NEW] lasso includes "Destination" attribute in SAML AuthnRequest populated with SP AssertionConsumerServiceURL when ECP workflow is used which leads to IdP-side errors

Dmitrii Shcherbakov 1833299 at bugs.launchpad.net
Tue Jun 18 20:42:26 UTC 2019


Public bug reported:

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

** Affects: lasso (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: cpe-onsite

** Attachment added: "18-06-2019-lasso-ECP-patch.diff"
   https://bugs.launchpad.net/bugs/1833299/+attachment/5271469/+files/18-06-2019-lasso-ECP-patch.diff

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to lasso in 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

Status in lasso package in Ubuntu:
  New

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lasso/+bug/1833299/+subscriptions



More information about the Ubuntu-openstack-bugs mailing list