IdP v3.0.0 CAS Support

[Walter Forbes Hoehn (wassa)]

I corresponded with Marvin a few weeks back and promised to do some integration testing of the CAS profile support in IdP v3.0.0.  For the most part, things seem to be working fine, but I came across a few issues.  I’m happy to to add these to JIRA (as bugs or feature requests) or ignore them depending on the thoughts of others.


1:  Some servlet containers attempt to do URL-based session management until a cookie is received back from the browser.  This causes the CAS service URL to vary between login and validation.

The result is the following error and an INVALID_SERVICE message being sent to the client.

2015-02-14 16:55:05,835 - DEBUG [net.shibboleth.idp.cas.flow.ValidateTicketAction:101] - Service issued for https://beisdev.memphis.edu:443/ssomanager/c/SSB;jsessionid=T0CKTW7nYkR3jimTVMJt8Q5APfcKK_yhqO7nxQWeYkaMvJ5I1ebH!2125672019?pkg=bwpkebst.P_DispIDSelect does not match https://beisdev.memphis.edu:443/ssomanager/c/SSB?pkg=bwpkebst.P_DispIDSelect

Subsequent requests will then work, as cookie-based session management has been fully established.

Since CAS server 3.0.5 (2008?) the behavior has been to strip the JSESSIONID out of the URL before creating the service ticket.  The relevant CAS JIRA report can be found here:

https://issues.jasig.org/browse/CAS-360

2. Some older CAS clients don’t properly parse SOAP messages.  For instance, in the CAS Java Client 3.1.3, you get this insanity:

final String removeStartOfSoapBody = response.substring(response.indexOf("<SOAP-ENV:Body>") + 15);
final String removeEndOfSoapBody = removeStartOfSoapBody.substring(0, removeStartOfSoapBody.indexOf("</SOAP-ENV:Body>"));
final SAMLResponse samlResponse = new SAMLResponse(new ByteArrayInputStream(removeEndOfSoapBody.getBytes()));

The assumption here is that a specific XML namespace prefix will always appear.  This is obviously a client bug, but it does seem to be the case that the Jasig CAS Server has always used the same prefix since the “samlValidate” feature was implemented and some clients came to expect it.

3. This is more of a feature proposal, but it sure would be nice if the ServiceRegistry was a ReloadableSpringService.

Thoughts?

-WFH (Walter Hoehn)