ECP issue with current opensaml-soap-impl

[Brent Putman]

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/2fe45406/attachment-0001.html>