In which I summarize recent Unicon participation in and contributions to the Jasig CAS open source Java single sign-on product project, for a rather long meaning of “recent”.
I last wrote in this forum at the end of 2010 regarding Unicon-involving progress in the Jasig CAS open source project. Oops! This post is intended to catch up to June 2012, that is, to the beginning of this quarter. There’s a lot to talk about. I’ll do a follow-on post picking up from there through the current quarterly development cycle ending this month, where there’s even more to talk about.
CAS Server maintenance and development
One focus of Unicon’s ongoing participation in the Jasig CAS open source single sign on project is in the maintenance and development of the CAS server product itself. Unicon has contributed to maintenance of the CAS 3.4 product line, to development of the 3.5 new release, and now to maintenance of that 3.5 product line.
CAS 3.4 maintenance
Unicon contributed to maintenance efforts on the CAS 3.4 branch up through the CAS 3.5 release (when focus turned to maintenance of 3.5). Unicon now recommends that all adopters upgrade to the more actively maintained CAS 3.5 product version and focuses maintenance development efforts there (though Unicon continues to support and assist with CAS 3.4 implementations.)
For CAS Server 3.4.6
The CAS Server 3.4.6 release included several fixes Unicon underwrote, including a fix to the “gateway” feature to ensure that service authorization to use CAS is enforced and correctly adding the ticket parameter when a fragment exists in the service URL. Uniconers also helped a couple modest functionality improvements into CAS for this release, namely making single sign-out callbacks differentially optional in the case where the single sign-on session expires without explicit user logout action and adding audit log logging of changes to service registrations. Unicon also upgraded the versions of the Inspektr, Perf4J, and Hibernate dependency libraries.
For CAS Server 3.4.7
The CAS server 3.4.7 release included a Unicon-contributed fix for a NullPointerException in the Service Theme resolver, added logging of the user attributes of the authenticated principal, and fixed LoginTicket implementation compliance with the CAS specification.
For CAS Server 3.4.9
Unicon’s Jacob Lichner contributed a fix for goofed up layout and for a jQuery problem in the default CAS login view in CAS Server 3.4.9. Unicon also helped to test a fix improving login page load speed.
For CAS Server 3.4.10
Unicon’s Bill Thompson contributed a more sophisticated TicketGrantingTicket expiration policy incorporating both a hard timeout and a sliding window idle timeout to the CAS Server 3.4.10 release, which turns out to be the expiration policy you’d usually want to have. Previously the sliding idle timeout window option was renewable forever, which almost certainly isn’t the single sign-on session length policy you’d want to have. The implementation of this was improved for CAS 3.4.11 and is also included in CAS 3.5.
For CAS Server 3.4.11
Unicon’s Jacob Lichner tweaked the default login page’s markup to better use available styles and moved Internet Explorer 6 styles to the Internet Explorer stylesheet. Which is to say, Unicon helped with modest maintenance of the default login user experience in the 3.4.11 release.
Unicon also assisted in reviewing the fix included in this release for an asserted CRLF vulnerability.
For CAS server 3.5.0
Unicon contributed to the development of the CAS 3.5 new features release, and ongoingly participates in maintaining the CAS 3.5 product line.
Unicon spearheaded evolving the contributed LDAP account and password status reflection extension (password soon-to-expire, password expired, account locked, etc.) known as “LPPE” and including this functionality in the CAS 3.5 release, with Unicon’s Misagh Moayyed and Bill Thompson doing much of the work on this.
Misagh also improved the language for defining patterns for service registration matching, improving upon the existing “Ant-style” pattern matching support to add regex pattern matching.
Unicon also assisted with several little fixes, such as ensuring that proxy tickets are no longer vended to outstanding proxy granting tickets for services disallowed from proxying via a change to their service registry registration and reconciling the just-in-time renew=true behavior with the service-registry-configured opting a service out of participating in SSO, both contributed by Unicon’s Dmitriy Kopylenko.
Unicon underwrote Drew Mazurek’s quality assurance testing of the CAS 3.5 code as it approached release.
CAS Client Library maintenance
A CAS single sign-on server is only useful if you can use it to log into things. CAS client software libraries are handy for integrating applications to rely upon CAS for single sign-on. Unicon’s Cooperative Support program provides technical support for several integration libraries, Unicon is grateful to have these libraries available for integration work in our CAS implementation projects, and Unicon applies some efforts to maintenance development upon them.
Java CAS Client
The Java CAS Client is perhaps the most featureful CAS client library, and is one Unicon’s done a fair amount of work upon.
For 3.1.10 release
Unicon underwrote a fix for a bug in the SingleSignOutFilter involving creating extraneous sessions.
For 3.2.1 release
Unicon assisted in maintaining and preparing the version 3.2.1 Jasig Java CAS client release including fixing a NullPointerException in the host name verifier and avoiding an extra parameter being added to ticket validation URLs accidentally. Unicon also underwrote assistance with adding Tomcat authentication Realm support for Tomcat 7.0.8, and improving SAML 1.1 implementation.
Besides working on the CAS server software and on integration libraries, Unicon’s developed a few external components for use with CAS.
Unicon has led maintenance of this CAS extension for optionally capturing and selectively securely releasing the end user’s password from CAS to trusted applications. Unicon originally developed and released ClearPass on behalf of California State University - Sacramento. Maintenance has included things like adding active removal of cached password when the user’s single sign-on session ends, rather than waiting for cache expiration.
As of the CAS 3.5.0 release, ClearPass is included (turned off and entirely optional) in the CAS product release itself rather than being maintained as a separate extension. Unicon will continue to maintain this module as a part of the CAS product itself.
EhCache Ticket Registry
Unicon has led maintenance of the EhCacheTicketRegistry module for CAS, allowing replication of the CAS ticket registry via the popular EhCache Java caching solution, supporting as it does various configurations and implementations for the cache. Unicon’s Adam Rybicki originally developed this registry on behalf of the University of New England (in Australia). Unicon’s been pleased to be a part of this module gaining adoption and uptake, using it in several projects since and noting other CAS adopters making use of it. The EhCacheTicketRegistry is included in the CAS 3.5 release and Unicon will continue to maintain this module as part of the CAS product itself.
CAS IdPAuthExternal plugin for Shibboleth
Unicon’s Dmitry Kopylenko led development of an IdPAuthExternal plugin for the Shibboleth IdP that delegates delivery of the login experience to CAS in a more nuanced way than does the naive solution of configuring the IdP to accept REMOTE_USER and providing REMOTE_USER by applying and configuring the Java CAS Client servlet filters (or the mod_auth_cas httpd module, I suppose). This integration allows Shibboleth IdP to delegate to the CAS server for implementation of the single sign-on session, which means that CAS and the IdP share a functional SSO session (CAS and Shib IdP behave as if they’re part of the same single sign-on “domain” and end-users won’t notice whether an application they’re using happens to be integrated using SAML through the IdP or using the CAS protocol directly). These single sign-on sessions can be ended though CAS logout, and this will have the immediate effect of ending the Shibboleth IdP single sign-on session as well, since the redirect to CAS will no longer return immediately, stopping instead to prompt the end user for username and password to create a new single sign-on session.
Bridging to Shibboleth is a pretty good way to marry CAS’s flexible end-user-facing login flow capability with Shibboleth IdP’s rigorous and highly configurable SAML capabilities. This shib-cas-authenticator module is a good implementation of this bridging.
CAS server depends on the Inspektr open source library for audit trail logging. Unicon’s been involved in some modest maintenance of this library, including improving the error message logging, following up on a support experience in which this better logging would have been helpful.
CAS Addons has some interesting code in it, some of which predates June 2012, but I’ll pick up on CAS Addons in a subsequent post.