IDP 3 CAS samlValidate failing with certain headers
cantor.2 at osu.edu
Thu May 26 12:46:12 EDT 2016
> When a samlValidate request is sent with the headers:
> Content-type: text/xml
> SOAPAction: http://www.oasis-open.org/committees/security
> the server throws a RuntimeException because it fails to parse the XML in
> the request. However, the very same request with a different content type
> (e.g. text/html or application/xml), or without the SOAPAction header, will
> parse properly.
That seems backwards, but the error is probably the one that was breaking ECP when the content type was *not* sent or was set to the form-encoded type. Jetty will end up consuming the body and trying to parse it for parameters before the IdP runs, and setting the content type to text/xml is the fix. I don't really see how the opposite is possible.
> The server responds with a RuntimeException error page, with only this in
> the logs:
Right. This is literally the opposite of what we've observed.
> I experimented extensively with different combinations in Postman, and
> found that those two HTTP headers were the only relevant factors. The
> behavior is reliable.
The header that matters is the content type. And yes, it matters.
> Given that the Java CAS clients all seem to use these headers, I’m expecting
> this to be a show-stopper for a large swath of our services. Any ideas about
> what might be going on?
I know what, but I can't see how what you're saying can be true when the opposite is what has been observed in other similar cases.
More information about the users