Keystone as a SAML IdP does not work when mod_auth_mellon is used as the SP
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Triaged
|
Medium
|
Unassigned |
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-
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://
xmlns:ns1=
xmlns:ns2=
xmlns:saml=
xmlns:xmldsig="http://
xmlns:xsi="http://
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).
-------
Changed in keystone: | |
status: | New → Triaged |
importance: | Undecided → Medium |
tags: | added: federation saml |
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.