Add HTTP-POST binding support for IdP SingleSignOnService

[waynewoodfield]

Created a simple self-submitting form to POST a SAMLRequest to the IdP when HTTP-POST binding is required.

[coveralls]

Coverage decreased (-0.4%) to 94.685% when pulling 8bfe16c on waynewoodfield:post-binding into 9274e6b on onelogin:master.

[pitbulk]

Support HTTP-POST binding is more than just send the SAML message using POST instead GET, for example, signatures need to be embedded.

[waynewoodfield]

Okay. You can reject this PR, since I don’t have this binding fully supported, and I’ll resubmit later if I get this implemented better. Since my company doesn't sign our SAMLRequests, this simple post meets my company’s needs for now, so I’ll just keep this on my local fork and use it here as-is for now. Wayne Woodfield

…

On Jul 17, 2017, at 8:09 AM, Sixto Martin ***@***.***> wrote: Support HTTP-POST binding is more than just send the SAML message using POST instead GET, for example, signatures need to be embedded.

[docwarems]

Hi, we are also evaluating this Java toolkit for adding SAML support into our product. We would definitely need signed auth requests with POST binding.
Is there any schedule regarding adding POST binding support?

Please don't be offended by this question. In know this is free software developed eventually by persons in their spare time. It's just that we need it and have to check out other toolkits in case. We would also pay for a commercial product.

[pitbulk]

There is no plan to implement it.

Based on SAML specification (See reference at the bottom), all IdPs MUST support the HTTP-Redirect binding so that is the selected way we implemented to manage AuthNRequests, LogoutRequests and LogoutResponses.

Adding other binding will make the toolkit more complex and is not our goal.

There are other alternatives that support those bindings that you should review:

• spring-security-saml
• OpenSAML 3
• OIOSAML

Reference: Conformance Requirements for the OASIS Security Assertion Markup Language (SAML) V2.0 Page 9

[docwarems]

Thanks a lot for this clear statement and pointing me to other toolkits.
I know that the size limitation of GET requests could become real problem in certain situations, eventually depending on the browser. As signed requests might exceed this limitation, I see a practical problem in using the Redirect binding. I also found this statement at other places. Without having any practical SAML experience right now, I expect a problem here.

[pitbulk]

I know that the size limitation of GET requests could become real problem

Only SAMLResponses can be that big since them can contain Assertions. In that scenario we support the HTTP-POST binding.

On AuthNRequest, LogoutRequest and LogoutResponse, the size of the Message isn't that big, and can be perfectly managed (take in mind also that the SAML protocol defines a gzip method to be used on SAML Messages to compress them) so the size limitation of GET requests is just an excuse of those IdPs that only implemented the POST binding (since they required it for process the SAMLResponse) .

[waynewoodfield]

I’m the author of this fork. Although the OneLogin team doesn’t want to support POST binding at this time, you are welcome to use the code in this fork that implements a primitive form of POST binding. Specifically, instead of redirecting to the SingleSignOnService URL with SAMLRequest and RelayState as query parameters, it just generates a self-posting form and provides the same SAMLRequest and RelayState as POST parameters. The SAMLRequest would still include whatever signature or encryption that it would if it were sent in the URL as a redirect. If this doesn’t follow the SAML spec for post binding, I would welcome any feedback or documentation about how to implement the spec better, and may be willing to update this fork too. Should alleviate your sizing concerns at least, and may satisfy a stubborn IdP that only accepts POST binding, in spite of the documented requirement that they should accept Redirect too. Not everyone plays by the rules :-) Wayne Woodfield

…

On Oct 25, 2017, at 2:53 AM, docwarems ***@***.***> wrote: Thanks a lot for this clear statement and pointing me to other toolkits. I know that the size limitation of GET requests could become real problem in certain situations, eventually depending on the browser. As signed requests might exceed this limitation, I see a practical problem in using the Redirect binding. I also found this statement at other places. Without having any practical SAML experience right now, I expect a problem here. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#116 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATrPcGZMx3QEX-uzl3PgSoPaJHpdn-a4ks5svvb0gaJpZM4OZJHp>.

[docwarems]

Thanks a lot you both. First of all I will ask the IdP about this strict POST requirement. I also was of the opinion that the IdP should handle it dynamically, also because the SP metadata generated by the toolkit doesn't contain information about SSO Auth binding support (but metadata XML validation fails - I have no further details here currently!).

[docwarems]

This link is probably not the worst source for reliable SAML information:
https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf. I quote from chapter 5.1.3
"The HTTP POST binding may be necessary for an message in cases where its length precludes the use of the HTTP Redirect binding (which is typical)".
My english is eventually not good enough, but I understood that length problem are not that uncommon.

[pitbulk]

Th document that you mentioned is just a Draft, if you review the 10th version of this document:
https://www.oasis-open.org/committees/download.php/20645/sstc-saml-tech-overview-2%200-draft-10.pdf

you will see that the sentence was modified and the "(which is typical)" disappeared, but again, just a draft, not official doc.

I can assure you that the AuthNRequest messages that you can build with this toolkit never will experience the GET size parameter limitation.

[docwarems]

Hm, strange that your document from 2006 is newer than mine from 2008...

Other question; This should be the current binding spec:
https://www.oasis-open.org/committees/download.php/35387/sstc-saml-bindings-errata-2.0-wd-05-diff.pdf
I could not find a statement which bindings MUST be implemented and which are optional. I found a mandatory support for Redirect Binding at other sources, but not in this spec. Can you point me there?

[pitbulk]

I already did in a previous message:

Reference: Conformance Requirements for the OASIS Security Assertion Markup Language (SAML) V2.0 Page 9

Official docs are listed here:
http://docs.oasis-open.org/security/saml/v2.0/

[docwarems]

Thank you!

[docwarems]

Hi again, forgive me if this discussion becomes a little off topic. If you prefer I could start a more specific thread.
Further investigation revealed the IdP product "F5" supports Redirect binding for signed auth requests only with (quote) "enveloped signatures". I understand this means the signature shall be included in the auth XML (and the missing signature was also the error reason the IdP admin told me).
Does the spec leaves open, whether the signature comes with extra GET parameter (as for the OneLogin toolkit), or shall be included in the XML?
If this is the only problem and the spec allows this, I should be able to modify the toolset code to support this. What do you mean?

[coveralls]

Coverage decreased (-0.6%) to 94.556% when pulling 94eb327 on waynewoodfield:post-binding into 9274e6b on onelogin:master.

[coveralls]

Coverage decreased (-0.6%) to 94.556% when pulling 94eb327 on waynewoodfield:post-binding into 9274e6b on onelogin:master.