Comment 3 for bug 1833134

Revision history for this message
Dmitrii Shcherbakov (dmitriis) wrote :

#2 leads me to believe that the original commit to Mellon module was not correct because it quotes the spec as "... This is documented in the SAML Bindings Specification, Section 3.4.5.2 "Security Considerations"", meanwhile, this section is only related to "3.4 HTTP Redirect Binding", not "3.2 SAML SOAP Binding" or "3.3 Reverse SOAP (PAOS) Binding" which come before that.

http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

In other words, IdP-side validation of the "Destination" attribute of AuthnRequest is only described for the HTTP Redirect workflow, not SOAP or PAOS. A client implementing ECP cannot modify this value because requests are signed and I have not managed to find any references to such behavior.

The profiles spec suggests that ECP determines the IdP and Mellon documentation does the same (https://git.io/fjVIz):
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
"4.2.2 Profile Overview ...
3. ECP determines Identity Provider to use (methods vary, details not shown)"

Therefore, I think the fact that the "Destination" attribute is populated for the ECP workflow with an SP URL (AssertionConsumerServiceURL) is a bug in lasso.

Also, in support of that claim I found a post which includes an example of AuthnRequest when Shibboleth SP module is used with apache and authentication is performed against Shibboleth IdP - it does not contain the "Destination" attribute in it:
http://idmoim.blogspot.com/2015/02/