ECP issue with current opensaml-soap-impl

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ECP issue with current opensaml-soap-impl

Kim, Allan

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 – 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, and I think SwiftECP sends application/vnd.paos+xml.

 

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.

 

Thanks!

 

 


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: ECP issue with current opensaml-soap-impl

Cantor, Scott E.
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 much more than that, it prevents containers from doing bad things
to the body before the code can run. Tolerating it costs us support time
and money.

> 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.

If you want to support them, you can put a Java filter into your
container to override what the client sent.

-- Scott
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: ECP issue with current opensaml-soap-impl

Brent Putman
In reply to this post by Kim, Allan



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


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: 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:[hidden email]] On Behalf Of Brent Putman
Sent: Monday, November 07, 2016 2:48 PM
To: [hidden email]
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


--
To unsubscribe from this list send an email to [hidden email]