IDP 3 CAS samlValidate failing with certain headers

[Kelly,Jeffrey]

On 5/26/16, 12:46 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

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

Yeah, I read that thread and thought the same thing. Nevertheless, here I am. I forgot to mention that we’re running this in Tomcat 8.0.30.0, for what that’s worth. The idea of the container pre-processing the body seems plausible, but I’m not sure what would cause that to trigger in such specific circumstances. I’ll investigate further down this line.

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

Well, this might be a slightly different issue, since the error only occurs when both the SOAPAction is sent *and* the content-type is text/xml. Changing the content type “fixes" it, and removing the SOAPAction header does, as well, regardless of the content type. 

jef

>