ECP issue with current opensaml-soap-impl

[Kim, Allan]

OK then a filter it is - thanks for the explanation Brent and Scott!

From: dev [mailto:dev-bounces at shibboleth.net] On Behalf Of Brent Putman
Sent: Monday, November 07, 2016 2:48 PM
To: dev at shibboleth.net
Subject: Re: ECP issue with current opensaml-soap-impl




On 11/7/16 4:54 PM, Kim, Allan wrote:
At UCSD we've run into some unexpected behavior while testing ECP with IdP 3.3.0-SNAPSHOT. The latest opensaml-soap-impl has added content type validation for SOAP requests in HTTPSOAP11Decoder, and accepts only text/xml as a valid type. I'm sure this is technically correct for SOAP 1.1

It's not just technically correct, it's an RFC MUST, see [1] part 6:

" HTTP applications MUST use the media type "text/xml" according to RFC 2376 [3] when including SOAP entity bodies in HTTP messages."

Per RFC 2119, the MUST means it's an absolute requirement, there's no wiggle room at all. Clients sending anything else are just broken.  I'm not terribly inclined to make our code more complex to deal with broken clients, especially if there's a relatively easy workaround.


- however various ECP reference client implementations have gotten away with using other content types in the past and now seem to fail validation. For example ShibHttpClient from https://github.com/DARIAH-DE/shib-http-client sends text/plain,

That seems trivially wrong.


and I think SwiftECP sends application/vnd.paos+xml.

That just doesn't even make any sense.  The request to the IdP is NOT reverse SOAP (PAOS), it's SOAP, period.



Is it possible to turn either content type validation or SUPPORTED_MEDIA_TYPES into configurable options? This would allow IdP deployers to support slightly out-of-spec clients while allowing other OpenSAML users to enforce strict validation when desired.



I'd suggest to go with Scott's filter solution, to just force the Content-Type as seen by the application to text/xml.

Even if we did expose such options on the decoder to allow workarounds for broken clients, in the IdP it would be problematic to set them.  The decoders are all defined under system/ which isn't designed to be user-modifiable.  I suppose we could expose a property or something.  It would have to mean an enumeration of the allowed types, not a boolean.  If you just turned off validation, you'd be broken and the request would fail if the client sent 'application/x-www-form-urlencoded', which was the original problem here. [2] [3]  curl does that by default on a POST if you don't tell it otherwise.



[1] https://www.w3.org/TR/2000/NOTE-SOAP-20000508/

[2] https://issues.shibboleth.net/jira/browse/OSJ-155

[3] https://issues.shibboleth.net/jira/browse/IDP-708
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20161107/f960d672/attachment.html>