Q3 2012 Unicon-involving CAS Progress
In which I discuss Unicon-involving progress on Jasig CAS in the last quarter, and a bit about CAS more generally.
Materials continue to become available from the Jasig-Sakai 2012 conference and dates are announced for the January 2013 Jasig-Sakai un-conference.
Jasig-Sakai 2012 recordings available
Recordings are now available for some presentations involving identity management from Jasig-Sakai 2012, thanks to the OpenCast Matterhorn project (an open source lecture capture solution by and for higher education).
- What’s new in Jasig CAS 3.5
- High Availability in Hurricane Alley - Multi-site multi-node CAS deep in the heart of Texas
- An Introduction to Grouper - one fish two fish red fish blue fish
- Shibboleth and CAS - even more perfect together
- Columbia Goes Goo-Google for CAS - extending CAS with WIND protocol support
- Open Source Person Registries
- And more
Also, I continue to maintain that Saint Cloud State University’s uPortal 4 in Action presentation was in part a presentation about the power of CAS single sign-on.
Upcoming Jasig-Sakai UnConference 2013
It’s 2.5 days of UnConference-style organic just-in-time-planned sessions, followed by 1.5 days of collaboration.
This will be a fine opportunity to gather CAS implementers and developers, to discuss CAS, to share solutions and successes, and to collaborate on making CAS better. I intend to be there. (It will also be warmer and sunnier there near Phoenix than it will be here in Michigan in January, another aspect of the event I look forward to.) I hope you’ll join in.
Jasig CAS 3.5.0 was released on July 9th, 2012.
Highlights of this release include:
- Inclusion of previously external modules, namely ClearPass, LPPE (richer LDAP authentication error and warning experiences), and EhCache ticket registry
- OAuth support
- Regular expression service registration matching
- Improved cas.properties and logging configuration
- Web flows use Spring EL by default
- Updated dependencies throughout
See also my Jasig-Sakai conference presentation on what’s new in CAS 3.5, including its recording.
There’s a known issue in CAS 3.5.0 wherein the EhCache ticket registry and ClearPass are incompatible. Pick zero, pick one, but don’t pick both, unless you want to fix the issue locally. The issue is fixed in CAS 3.5.1.
Forthcoming CAS 3.5.1 release
A release candidate of CAS 3.5.1 is now available. Highlights of this release include:
- ClearPass and EhCache ticket registry now compatible
- Other bugfixes
- Responsive design of default login user interface
- Drag-and-drop re-ordering of service registrations
- Per-service selection of which attribute to use as username
- Refactored login webflow
New CAS Perl client
Unicon developed a new Perl language CAS integration library for the University of Kansas, who generously and wisely allowed Unicon to release this as free and open source software. This library improves upon prior popular Perl language CAS integration support by supporting obtaining user attributes via the SAML11 style ticket validation response.
CAS to LTPA bridge
A new standalone application that translates from CAS to the Lotus Third Party Authentication token API is available. This stems from a CAS customization Unicon developed for Empire State College.
Unicon work in and with CAS this quarter
The Plan Was
Unicon applies development and other maintenance effort on the CAS project on behalf of our technical support program subscribers in order to make CAS better, more supportable, and more aligned with the needs of support subscribers, in ways that serve the subscribers, the wider CAS community, and Unicon.
This quarter we set out to help take CAS 3.5.0 to completion, to continue to maintain and appropriately enhance the CAS 3.5 line, and to innovate in cas-addons towards the next CAS version beyond CAS 3.5. And this quarter, we largely succeeded in delivering what we set out to do.
CAS 3.5.0 GA release
CAS 3.5.0 successfully released, with Unicon contributing to that going to completion by underwriting Drew Mazurek’s work in QAing the release.
CAS 3.5.0 includes features Unicon worked on, notably LPPE (LDAP password / account status reflected in the login experience), ClearPass, the EhCacheTicketRegistry, and regular expression pattern matching on service identifiers against service registrations.
CAS 3.5.1 RC1 available
Unicon supported continued maintenance and appropriate incremental development of the CAS 3.5 line by contributing to the CAS 3.5.1 release, now available as a release candidate.
Like for the 3.5.0 release, Unicon is again underwriting Drew Mazurek’s efforts testing and helping with quality assurance of this release.
Dima has already posted a cas-addons release that works with CAS 3.5.1-RC1.
Unicon has contributed to this release by spearheading several features and improvements.
Responsive design of default skin
CAS 3.5.1 includes a relatively conservative, modest, simple step towards responsive design in the default skin. This is not a radically remade skin. It doesn’t look a lot different. That’s intentional. The idea is to provide a similar simple starting point to what has come before, but add to the starting point the sort of responsive design feature that many adopters will want to have, such that the UI rearranges and re-styles to accommodate different browser sizes. While CAS was usable prior to this change on mobile devices, it’s now more usable and pleasant. Credit is especially due to Uniconers Chris Paraiso, Jacob Lichner, and Misagh Moayyed for making this happen.
Here’s what the login screen looks like in a wide browser. This is much like CAS 3.5.0.
Here’s what the login screen looks like in a bit narrower browser. The languages tuck in.
And here’s what the login screen looks like in a narrow browser, such as that of a mobile device.
Per-service selection of attribute to use as username
Unicon originally developed a modification for CAS 3.4 for Empire State College implementing this feature. Empire State graciously encouraged Unicon to release this as free and open source software and incorporate it into the CAS product on their behalf, and Misagh Moayyed did that, such that now it’s included in CAS 3.5.1.
This feature allows CAS administrators to select, via service registration, which of the available user attributes CAS should present to the registered service in the place of the username in the CAS ticket validation responses. The simplest validation responses convey only the username and no user attributes. If an application only needed one attribute, say because it has a difference of opinion about usernames versus other applications on campus, it may be simpler to release the desired attribute in place of the username. This feature provides one more tool for addressing the case where applications differ in what they think the user identifier should be, so long as all these identifiers are available to CAS as user attributes.
Drag-and-drop re-ordering of service registrations
If you’re using a writeable store for service registrations (in practice, the JPA services registry), such that you’re ordering them via the services management UI, and you’re using service registrations with patterns that hypothetically overlap such that you need to ensure they’re ordered properly, then you’ve probably been frustrated at a workflow of having to detail in on each registration to set its Order field, and having to have some idea of how those numbers relate to one another to get the order you need. Ick. Reminds me of the days of those really old BASIC environments where lines had line numbers and you’d number them
10 PRINT "Hello, World!" 140 END
leaving integers between line numbers to enable adding additional lines later.
Well, be frustrated (and reminded of BASIC) no more – in CAS 3.5.1, you can better visualize and drag-and-drop re-order service registrations, without having to detail into individual registrations to view or change their Order property.
In the example in this screenshot, for instance, I’d want to be sure that the more specific registration (for http://www.unicon.net) is ordered before the broadly matching pattern registration, otherwise the pattern’s configuration would apply and the specific registration would never have any effect. With the UI improvements, it’s easier to understand the order the registrations will be evaluated and to re-order them as needed.
It’s still best to minimize overlapping registrations (to minimize confusion and opportunity for configuration error), and you may decide you don’t want to use the web-based services management UI at all or want to use it against a read-only service registry implementation, such as the growing-popularity now-more-featureful JSON services registry I’ll mention below, but nonetheless the services registry management tool is more usable in CAS 3.5.1, and that’s a good thing.
Fixed: EhCacheTicketRegistry compatibility with ClearPass
The annoying CAS 3.5.0 bug of EhCacheTicketRegistry or ClearPass but not both is fixed in 3.5.1 (also: CAS–1174). Thank Misagh for these fixes as well.
CAS addons is a public, free and open source software repository of components for use with CAS. These tend to be more cutting edge, experimental, or odd than what’s made it into the CAS release itself, but these components are intended to be available to add value to your real CAS implementation. cas-addons is also one place to incubate features that might be drawn into the CAS server distribution itself.
cas-addons 1.0-RC1 works with CAS 3.5.1-RC1.
CAS addons has some neat stuff in it, some of which Unicon advanced this quarter.
JSON service registry
The JSON service registry predates this quarter. It implements service registration definition in a plain old text file, in JSON format.
What’s new this quarter is the near-real-time honoring of updates to the text file. So, you edit the JSON file, save your change, and that fires an event for the file to be re-parsed and reflected in CAS’s understanding of the service registrations.
This means that the JSON service registry is very much read-write, just not read-write through the Services Management web-based UI (yet). It “has a UI” – your favorite text editor! And if this appeals to you, your favorite text editor is probably vi or emacs. (You can still use the web-based services management UI if you want, but it won’t be able to persist your changes back to the text file. Maybe that capability would be worth developing.)
The JSON service registry has been gaining some uptake. It retains the ability to edit the registry live (without restarting CAS), but removes the RBDMS as a dependency of the CAS server. For some adopters, eliminating the RBDMS will make the CAS server a little more reliable, with one less component to care for and connection to keep working.
JSON person attribute DAO
Dima also developed a JSON-backed person attribute DAO. This is more a testing tool than anything else, also benefiting from the near-real-time-reload-on-edit capability.
This has already proven useful in testing and troubleshooting CAS implementations and I expect it will be even more useful as the CAS community explores the new feature for per-service selection of which user attribute to use as the username for a given service.
Incidentally, Misagh has put together a handy example application for demonstrating CAS attribute behaviors.
Proof of concept JSON validation response
This is a proof of concept. It doesn’t yet support delegated authentication (proxy CAS).
cas-addons also includes a Java CAS Client component for exercising the JSON format ticket validation endpoint. So, add the JSON ticket validation protocol endpoint to your CAS server, add the JSON ticket validation endpoint exercising plugin to the Java CAS Client, and away you go, demonstrating the integration.
This is intended as a step towards exploring a next-generation lightweight CAS validation response expressed in JSON. Arguably, if CAS were being invented today, it would have used JSON rather than the lightweight XML that Shawn Bayern selected back in the day. CAS is continually being invented today and innovating with a JSON response may be a good next step for the CAS protocol.
Stormpath is a software as a service solution for managing application user identities from some of the same folks who brought you Apache Shiro, a free and open source Java solution for relatively lightweight authentication and authorization integrations. Apache Shiro supports CAS, so Dima and Misagh returned the favor and developed an integration for CAS to support Stormpath.
cas-addons contains an AuthenticationHandler to validate credentials against Stormpath. This means that any application that supports CAS supports Stormpath, by way of using a CAS server that bridges to Stormpath. This is by no means the only way you might integrate your application with Stormpath, but it’s one more way that CAS support can be worth building into applications, which is another reason to have built this integration. The more applications support CAS integrations, the better of the CAS community is in the starting points available for SSO integrations into these applications.
OATH one-time password authentication
This is code Unicon developed for Ryerson University, who has generously allowed it to be released as free and open source software. This integration is now available in cas-addons.
What is it? Among other things, a CAS AuthenticationHandler that validates against OATH (TOTP). OATH is an open standard for one-time password generation. Google Authenticator is a popular free and open source mobile device app implementation of OATH, but you can also buy physical tokens that implement OATH.
In the Ryerson project specifically, the OATH tokens are the Google Authenticator. In principle this integration should work with any other OATH token you like.
Unicon’s pulled this code into cas-addons and intends to maintain it there for adoption with CAS servers.
CAS Password Management extension
Unicon maintained the CAS Password Management extension this quarter, in part underwriting this maintenance through the Cooperative Support for CAS program. These updates brought cas-pm up to integration with CAS 3.5.
What’s next for Unicon work in and with CAS
This last quarter of 2012, Unicon will continue to contribute to maintenance of CAS 3.5, help the CAS project work towards a near-term CAS 4 release under the re-worked CAS roadmap, and prepare to collaborate and contribute effectively at the Jasig UnConference in January 2013 in scenic Mesa, Arizona (near to Unicon’s office in Gilbert, AZ).
Maintenance on CAS 3.5
CAS 3.5.1 is in release candidate status. Unicon will contribute to quality assurance and completion of this release, underwriting Drew Mazurek’s testing efforts.
Beyond the 3.5.1 release, we’ll continue to assist with maintenance and patches on the CAS 3.5 series as needed. CAS 3.5 is the CAS version to be confidently adopting today. Unicon has several clients using the 3.5 version already and expects to be assisting with CAS 3.5 for quite some time to come.
Documentation has been a pain point for some time, but it’s been a little more painful lately in some support and project contexts. More attention to the documentation is a priority for this quarter.
CAS 3.5 incorporates several led-by-Unicon features, which Unicon intends to continue to maintain. The LPPE module in particular will benefit from some additional attention and Unicon will continue to maintain the EhCache ticket registry.
Collaboration on CAS 4
Unicon will also use this quarter to continue to collaborate towards the next major new-features release of CAS, CAS 4, under the re-worked roadmap for the CAS product.
Perhaps the most important part of this will be attention to the CAS protocol and the potential for a JSON format CAS server ticket validation response supporting user attributes and proxy granting ticket acquisition at once. Unicon expects to use the UnConference as an opportunity to further discuss and collaborate upon this. CAS protocol documentation also needs maintenance to document capabilities that have come into the CAS server product since the protocol document was authored.
There’s been a fair amount of interest in the attribute-based coarse grained access control Unicon developed for Fordham University and co-presented about at the Jasig-Sakai conference. This, with other incremental new features, will be something to continue to work on in cas-addons as an incubator for capabilities that might be drawn into the CAS product, for CAS 4 or otherwise.
One request I’ve heard a few times is for fancier control over SSO session lengths. Session lengths varying per-service, per-user-attributes, per-business-rules about remote address or time of day, that kind of thing. This turns out to be nontrivial, especially if we want to avoid one-off tricks to address individual requirements specifically and go after something a little more general and flexible. This is especially nontrivial when considered against the move to push some of the session and ticket harvesting into the caching layer in solutions like EhCache. Not saying any of this is impossible. Next steps here include thinking about it, talking about it, and collaborating within the CAS community on SSO session length capabilities. This also may be a good topic for the UnConference.
Unicon also intends to continue to maintain and progress the CAS password management module and the Shibboleth plugin for high quality delegation to CAS, though these will be a low priority this quarter unless issues and struggles with what’s already there arise.
I’d like to express gratitude to Unicon’s Cooperative Support for CAS subscribers, who make much of Unicon’s direct participation in the development process around the supported open source software possible. I’d also like to thank Unicon’s consulting and custom development clients who make direct participation in open source collaboration and release of custom development work product as free and open source software part of the projects they undertake with Unicon.