[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

[Launchpad Bug Tracker]

This bug was fixed in the package lasso - 2.5.1-0ubuntu1.1

---------------
lasso (2.5.1-0ubuntu1.1) bionic; urgency=high

  * d/p/PAOS-Do-not-populate-Destination-attribute.patch: Do not populate
    "Destination" attribute (LP: #1833299)

 -- Dmitrii Shcherbakov <dmitrii.shcherbakov at canonical.com>  Thu, 04 Jul
2019 18:42:56 -0500

** Changed in: lasso (Ubuntu Bionic)
       Status: Fix Committed => Fix Released

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

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