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

[Christian Ehrhardt ]

All test builds completed and the Eoan transition is done.
I added B/D tasks and sponsored your upload to the -unapproved queue of these releases.

** Also affects: lasso (Ubuntu Disco)
   Importance: Undecided
       Status: New

** Also affects: lasso (Ubuntu Bionic)
   Importance: Undecided
       Status: New

** Changed in: lasso (Ubuntu Bionic)
       Status: New => In Progress

** Changed in: lasso (Ubuntu Disco)
       Status: New => In Progress

-- 
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:
  Fix Released
Status in lasso source package in Bionic:
  In Progress
Status in lasso source package in Disco:
  In Progress

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