IDP 3 CAS samlValidate failing with certain headers
jlk64 at drexel.edu
Thu May 26 13:05:37 EDT 2016
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 22.214.171.124, 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.
More information about the users