IDP 3 CAS samlValidate failing with certain headers

[Kelly,Jeffrey]

Hello all,

We’re transitioning from the JASIG CAS server to the CAS server in IDP 3.2.0. We have it set up, and we’re currently in the process of testing our voluminous amount of services. It’s working fine for a number of different CAS clients, but I’ve run across a scenario that causes it to break in a way that I can’t seem to troubleshoot…and it’s not an uncommon scenario, unfortunately.

The scenario, in short:

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.

In more detail:

A service using the Java cas-client-3.2.1 sends a samlValidate request that looks like this:
Content-Type:text/xml
Content-Length:439
SOAPAction:http://www.oasis-open.org/committees/security
User-Agent:Java/1.6.0_20
Host:our-shib-host.drexel.edu
Accept:text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<samlp:Request xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"  MajorVersion="1" MinorVersion="1" RequestID="_2de2f29f6142b6274b9f3a7773d3a039" IssueInstant="2016-05-24T20:48:18Z">
<samlp:AssertionArtifact>ST-1464122892058-DmBG8kzQDpfBwtBQCBSaFMON7</samlp:AssertionArtifact>
</samlp:Request>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The server responds with a RuntimeException error page, with only this in the logs:
---
2016-05-26 11:23:24,877 - ERROR [net.shibboleth.utilities.java.support.xml.BasicParserPool:50] - XML Parsing Error
org.xml.sax.SAXParseException: Premature end of file.
        at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
2016-05-26 11:23:24,890 - ERROR [org.opensaml.messaging.decoder.servlet.BaseHttpServletRequestXMLMessageDecoder:151] - Error unmarshalling message from input stream
net.shibboleth.utilities.java.support.xml.XMLParserException: Unable to parse inputstream, it contained invalid XML
        at net.shibboleth.utilities.java.support.xml.BasicParserPool.parse(BasicParserPool.java:248)
Caused by: org.xml.sax.SAXParseException: Premature end of file.
        at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
2016-05-26 11:23:24,899 - ERROR [org.opensaml.profile.action.impl.DecodeMessage:73] - Profile Action DecodeMessage: Unable to decode incoming request
org.opensaml.messaging.decoder.MessageDecodingException: Error unmarshalling message from input stream
        at org.opensaml.messaging.decoder.servlet.BaseHttpServletRequestXMLMessageDecoder.unmarshallMessage(BaseHttpServletRequestXMLMessageDecoder.java:152)
Caused by: net.shibboleth.utilities.java.support.xml.XMLParserException: Unable to parse inputstream, it contained invalid XML
        at net.shibboleth.utilities.java.support.xml.BasicParserPool.parse(BasicParserPool.java:248)
Caused by: org.xml.sax.SAXParseException: Premature end of file.
        at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
2016-05-26 11:23:24,927 - WARN [org.opensaml.profile.action.impl.LogEvent:76] - An error event occurred while processing the request: UnableToDecode
2016-05-26 11:23:24,937 - ERROR [java.lang.RuntimeException:76] -
java.lang.RuntimeException: java.lang.IllegalStateException: CAS protocol request not found
        at net.shibboleth.idp.profile.impl.RethrowingFlowExecutionExceptionHandler.handle(RethrowingFlowExecutionExceptionHandler.java:40)
Caused by: java.lang.IllegalStateException: CAS protocol request not found
        at net.shibboleth.idp.cas.flow.impl.AbstractCASProtocolAction.getCASRequest(AbstractCASProtocolAction.java:57)
---

I experimented extensively with different combinations in Postman, and found that those two HTTP headers were the only relevant factors. The behavior is reliable.

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?

Sincerely,
Jeffrey L. Kelly
Sr. Web/Portal Administrator
Information Resources and Technology
Drexel University

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160526/640729fe/attachment.html>