yahoo-eng-team team mailing list archive

[Colleen Murphy <colleen@xxxxxxxxxxx>]

Public bug reported:

The SAML assertion produced by a keystone IdP is technically invalid.
When mod_auth_mellon is used as the SP, the SP rejects the SAMLResponse
with the error message:

Error processing ECP authn response. Lasso error: [101] Signature
element not found.

This is due to incorrectly adding the SAML-specific XML namespacing
declarations (specifically the xmlns:xmldsig one) to the SOAP envelope
instead of to the SAMLResponse within. The result is that
mod_auth_mellon can't be used as an SP in a K2K setup. mod_shib is
apparently less strict about how it parses the SOAP message.

I found this using version 0.12.0 of libapache2-mod-auth-mellon on
Ubuntu Xenial.

Here's what jdennis says about it:

-----------------------------------
You've placed all your xml namesapce 
declarations, including the SAML specific ones, on the root node of the 
SOAP message, i.e. the soap envelope. For reference here it is:

<ns0:Envelope xmlns:ns0="http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:ns1="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" 
xmlns:ns2="urn:oasis:names:tc:SAML:2.0:protocol" 
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
xmlns:xmldsig="http://www.w3.org/2000/09/xmldsig#"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

When Lasso (the SAML library Mellon uses) processes the SOAP message it 
passes the content of the SOAP body (i.e. the SAML message) to the 
signature verification code which attempts to find the signature. It 
fails because the signature element is qualified with the xmldsig 
namespace which is never declared in the SAML message, hence it can't 
find it.

SOAP is a container for other content found in the soap body. Think of 
SOAP as a transport just like TCP, SSL, or even HTTP are transports 
(possibly poor analogies but bear with me). No matter what the transport 
is a SAML message is extracted from the transport. The SAML message must 
stand alone independent of how the SAML message was transported. Hence 
SAML properties are never embedded in the transport and MUST only occur 
in the SAML message.

Consider the other SAML bindings, HTTP-Post, HTTP-Redirect, etc. In 
those bindings the XML of the SAML message is the only XML therefore 
placing the xml namespace declarations on the topmost XML element is OK 
because the topmost XML element is the SAML message. SOAP is the only 
binding (I'm aware of) that embeds the SAML message in other XML, think 
of it as a wrapper. Therefore do not put SAML xml namespace declarations 
on the wrapper, instead *always* put them on the SAML message (because 
the wrapper will be discarded).
-----------------------------------

** Affects: keystone
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1794726

Title:
  Keystone as a SAML IdP does not work when mod_auth_mellon is used as
  the SP

Status in OpenStack Identity (keystone):
  New

Bug description:
  The SAML assertion produced by a keystone IdP is technically invalid.
  When mod_auth_mellon is used as the SP, the SP rejects the
  SAMLResponse with the error message:

  Error processing ECP authn response. Lasso error: [101] Signature
  element not found.

  This is due to incorrectly adding the SAML-specific XML namespacing
  declarations (specifically the xmlns:xmldsig one) to the SOAP envelope
  instead of to the SAMLResponse within. The result is that
  mod_auth_mellon can't be used as an SP in a K2K setup. mod_shib is
  apparently less strict about how it parses the SOAP message.

  I found this using version 0.12.0 of libapache2-mod-auth-mellon on
  Ubuntu Xenial.

  Here's what jdennis says about it:

  -----------------------------------
  You've placed all your xml namesapce 
  declarations, including the SAML specific ones, on the root node of the 
  SOAP message, i.e. the soap envelope. For reference here it is:

  <ns0:Envelope xmlns:ns0="http://schemas.xmlsoap.org/soap/envelope/"; 
  xmlns:ns1="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" 
  xmlns:ns2="urn:oasis:names:tc:SAML:2.0:protocol" 
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
  xmlns:xmldsig="http://www.w3.org/2000/09/xmldsig#"; 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

  When Lasso (the SAML library Mellon uses) processes the SOAP message it 
  passes the content of the SOAP body (i.e. the SAML message) to the 
  signature verification code which attempts to find the signature. It 
  fails because the signature element is qualified with the xmldsig 
  namespace which is never declared in the SAML message, hence it can't 
  find it.

  SOAP is a container for other content found in the soap body. Think of 
  SOAP as a transport just like TCP, SSL, or even HTTP are transports 
  (possibly poor analogies but bear with me). No matter what the transport 
  is a SAML message is extracted from the transport. The SAML message must 
  stand alone independent of how the SAML message was transported. Hence 
  SAML properties are never embedded in the transport and MUST only occur 
  in the SAML message.

  Consider the other SAML bindings, HTTP-Post, HTTP-Redirect, etc. In 
  those bindings the XML of the SAML message is the only XML therefore 
  placing the xml namespace declarations on the topmost XML element is OK 
  because the topmost XML element is the SAML message. SOAP is the only 
  binding (I'm aware of) that embeds the SAML message in other XML, think 
  of it as a wrapper. Therefore do not put SAML xml namespace declarations 
  on the wrapper, instead *always* put them on the SAML message (because 
  the wrapper will be discarded).
  -----------------------------------

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1794726/+subscriptions