IDP 3 CAS samlValidate failing with certain headers

[Cantor, Scott]

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

-- Scott