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

[Colleen Murphy]

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).
-----------------------------------

[John Dennis (jdennis-a)]

There was a bug in Lasso that caused the SIGNATURE_NOT_FOUND result with ECP. Having the namespace declarations on the soap envelope was not the root cause. However, that does not mean you shouldn't fix the location of the SAML namespace declarations, just that it wasn't the primary culprit.

I have opened this upstream bug: https://dev.entrouvert.org/issues/26828.

I have a patch prepared but need to do some more testing before submitting it.

[John Dennis (jdennis-a)]

FYI, there was a bug in Lasso which I fixed and supplied a test build to the reporter to verify the fixed worked. That was several weeks ago. I will follow-up to see what transpired.

I don't think there is anything Keystone must fix in it's code. Provided the result of the testing is successful this bug can probably be closed as "not a bug".

[John Dennis (jdennis-a)]

Ah, now I remember. The fix was tested and this specific problem was resolved. However, they were encountering other problems once that issue went away and I was waiting for diagnostic information on the new issue (likely a configuration issue with ECP).

So this specific bug can probably be closed.

[Kristi Nikolla (knikolla)]

It appears that the other issue was because we currently default to setting "relay_state_prefix" to "ss:mem:". That is what Shibboleth generally uses to prefix the relay state that it sends.

Mellon on the other hand, expects relay state to be a URL, therefore when receiving a message that start with "ss:mem:" will error out. Setting "relay_state_prefix" to be "<schema>://<hostname_of_sp>/" resolved the issue as Mellon is now correctly able to parse a valid url.

I will investigate further whether it's enough for this to be a documentation change, and OSC update to support `--relay-state-prefix` when creating and updating service providers, or if it warrants changes to the way keystone generates the relay state (prefix + random uuid). [0]

[0]. https://github.com/openstack/keystone/blob/26911744c05669b748a09dae5016291070a4d1e5/keystone/federation/idp.py#L647

[Flavio (flavp87)]

sorry my last comment was for #1648580