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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
