<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Hello all,</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>The scenario, in short:</div>
<div><br>
</div>
<div>When a samlValidate request is sent with the headers:</div>
<div> Content-type: text/xml</div>
<div> SOAPAction: <a href="http://www.oasis-open.org/committees/security">http://www.oasis-open.org/committees/security</a></div>
<div>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.</div>
<div><br>
</div>
<div>In more detail: </div>
<div><br>
</div>
<div>A service using the Java cas-client-3.2.1 sends a samlValidate request that looks like this:</div>
<div>
<div>Content-Type:text/xml</div>
<div>Content-Length:439</div>
<div>SOAPAction:http://www.oasis-open.org/committees/security</div>
<div>User-Agent:Java/1.6.0_20</div>
<div>Host:our-shib-host.drexel.edu</div>
<div>Accept:text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2</div>
<div><br>
</div>
</div>
<div>
<div><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"></div>
<div><SOAP-ENV:Header/></div>
<div><SOAP-ENV:Body></div>
<div><samlp:Request xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion="1" MinorVersion="1" RequestID="_2de2f29f6142b6274b9f3a7773d3a039" IssueInstant="2016-05-24T20:48:18Z"></div>
<div><samlp:AssertionArtifact>ST-1464122892058-DmBG8kzQDpfBwtBQCBSaFMON7</samlp:AssertionArtifact></div>
<div></samlp:Request></div>
<div></SOAP-ENV:Body></div>
<div></SOAP-ENV:Envelope></div>
</div>
<div><br>
</div>
<div>The server responds with a RuntimeException error page, with only this in the logs:</div>
<div>
<div>---</div>
<div>2016-05-26 11:23:24,877 - ERROR [net.shibboleth.utilities.java.support.xml.BasicParserPool:50] - XML Parsing Error</div>
<div>org.xml.sax.SAXParseException: Premature end of file.</div>
<div> at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)</div>
<div>2016-05-26 11:23:24,890 - ERROR [org.opensaml.messaging.decoder.servlet.BaseHttpServletRequestXMLMessageDecoder:151] - Error unmarshalling message from input stream</div>
<div>net.shibboleth.utilities.java.support.xml.XMLParserException: Unable to parse inputstream, it contained invalid XML</div>
<div> at net.shibboleth.utilities.java.support.xml.BasicParserPool.parse(BasicParserPool.java:248)</div>
<div>Caused by: org.xml.sax.SAXParseException: Premature end of file.</div>
<div> at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)</div>
<div>2016-05-26 11:23:24,899 - ERROR [org.opensaml.profile.action.impl.DecodeMessage:73] - Profile Action DecodeMessage: Unable to decode incoming request</div>
<div>org.opensaml.messaging.decoder.MessageDecodingException: Error unmarshalling message from input stream</div>
<div> at org.opensaml.messaging.decoder.servlet.BaseHttpServletRequestXMLMessageDecoder.unmarshallMessage(BaseHttpServletRequestXMLMessageDecoder.java:152)</div>
<div>Caused by: net.shibboleth.utilities.java.support.xml.XMLParserException: Unable to parse inputstream, it contained invalid XML</div>
<div> at net.shibboleth.utilities.java.support.xml.BasicParserPool.parse(BasicParserPool.java:248)</div>
<div>Caused by: org.xml.sax.SAXParseException: Premature end of file.</div>
<div> at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)</div>
<div>2016-05-26 11:23:24,927 - WARN [org.opensaml.profile.action.impl.LogEvent:76] - An error event occurred while processing the request: UnableToDecode</div>
<div>2016-05-26 11:23:24,937 - ERROR [java.lang.RuntimeException:76] - </div>
<div>java.lang.RuntimeException: java.lang.IllegalStateException: CAS protocol request not found</div>
<div> at net.shibboleth.idp.profile.impl.RethrowingFlowExecutionExceptionHandler.handle(RethrowingFlowExecutionExceptionHandler.java:40)</div>
<div>Caused by: java.lang.IllegalStateException: CAS protocol request not found</div>
<div> at net.shibboleth.idp.cas.flow.impl.AbstractCASProtocolAction.getCASRequest(AbstractCASProtocolAction.java:57)</div>
</div>
<div>---</div>
<div><br>
</div>
<div>I experimented extensively with different combinations in Postman, and found that those two HTTP headers were the only relevant factors. The behavior is reliable. </div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>Sincerely,</div>
<div>
<div id="MAC_OUTLOOK_SIGNATURE">
<div>Jeffrey L. Kelly</div>
<div>Sr. Web/Portal Administrator</div>
<div>Information Resources and Technology</div>
<div>Drexel University</div>
<div><br>
</div>
</div>
</div>
</body>
</html>