The CAS Roadmap provides a common understanding regarding the what, why, and how of future CAS releases. Adopters use the roadmap to understand when a new version may be released, the changes they can expect, and based on the type of release, the difficulty or ease with which to upgrade. CAS developers use the roadmap to communicate with each other and the community the types of features, bug fixes, and improvements they are individually committed to working on.
The roadmap is not the wish list. Adding a proposal to the roadmap is an implicit commitment to work on it. Please only add proposals to the roadmap if you intend to work on them. If you have a great idea, but are not able to commit to work on it, please add it to the wish list.
In order to fully understand the CAS Roadmap, one has to also understand the project release strategy. CAS follows the uPortal Release Strategy in determining the kinds of changes different releases can accommodate and how lines of development are managed. In addition to the expectations outlined in uPortal Release Strategy, CAS adopters can also expect the following for each release type:
- SECURITY - security releases are a critical minimal change on a release to address a serious confirmed security issue. That is, 18.104.22.168 would be 2.5.0 with a minimal change to patch a vulnerability. All adopters are strongly urged to upgrade to a SECURITY releases as soon as possible. CAS maven overlays should build with no changes, unless required and highlighted in the release notes.
- PATCH - a conservative incremental improvement that includes bug fixes, enhancements and new features and is absolutely backward compatible with previous PATCH releases of the same MINOR release. (i.e. 2.4.15 is a drop in replacement for 2.4.14, 2.4.13, 2.4.12, etc.). Adopters can expect that major APIs, integration points, default behavior, and general configuration is mostly the same. CAS maven overlays should build with little to no changes, unless required and highlighted in the release notes.
- MINOR - an evolutionary incremental improvement that includes all PATCH release improvements along with fixes and enhancements that could not easily be accommodated without breaking backward compatibility or changing default behavior. Adopters can expect general improvements that require moderate changes in APIs, integration points, default behavior, and general configuration. Overall the CAS server code along the MINOR development line looks pretty much the same from release to release with clear moderate evolutionary changes. MINOR releases may have a theme or focus that helps coordinate development. CAS maven overlays may require minor to moderate changes, some APIs may have changed or been deprecate, default behavior and configuration may have changed. However, CAS Public APIs will remaining unchanged between MINOR versions.
- MAJOR - a revolutionary change accommodating sweeping architecture, approach, and implementation changes. Significant changes in APIs, default behavior, and configuration can be expected. Maven overlays may require significant changes and possibly a complete reworking. Overall the CAS server code line may looked markedly different and integration points may require reworking.
All new improvements, fixes, enhancements, and changes are weighed against the release strategy for consideration in future release.
CAS 3.4.x PATCH Releases
3.4.x releases are conservative incremental changes for backward compatible bug fixes, enhancements and new features. CAS 3.4.12 is the latest 3.4.x release and was made available in May, 2012. This will likely be the last patch release for the 3.4.x series since 3.5 was released July 2012. CAS deployers are encouraged to upgrade to the 3.5.x series.
CAS 3.5.x PATCH Releases
3.5.x releases are conservative incremental changes for backward compatible bug fixes, enhancements and new features. CAS 3.5.0 was released in July 2012. Deployers can expected on-going patch releases to the 3.5.x series.
Active developers maintaining this release:
- Marvin Addison, Virginia Tech
- Scott Battaglia, independent developer
- Jérôme Leleu, SFR (french telecom company)
- Misagh Moayyed, Unicon via Open Source Support
- Andrew Petro
- Bill Thompson, Unicon via Open Source Support
CAS 4.0 MAJOR Release
- 2013-06-10: CAS 4.0 RC1, CAS 3.0 Protocol Revision RC1
- 2013-06-10 - 2013-07-12: Community testing and feedback. Additional release candidates as necessary.
- 2013-12: CAS 4.0 RC3
- 2014Q1: CAS 4.0 GA, CAS 3.0 Protocol Revision GA
CAS committers who attended the Jasig-Sakai 2012 conference in Atlanta arrived at rough consensus around a 4.0 release candidate with the following scope:
- improved authN APIs to support multiple credentials (forces Major release per release strategy)
- new skin and better support for mobile devices
- Improvements to the Ldap Password Policy enforcement that are described here.
- potentially other minor evolutionary improvements that would have been targeted for 3.6.
- move out the services management webapp from CAS server webapp -> Jérôme : CAS-1183 - Move out the services management webapp Resolved
- make SAML support optional in a specific module -> Marvin / Jérôme : CAS-1188 - Make SAML support as an optional module for CAS server Resolved
- improve client protocols support -> Jérôme : CAS-1286 - Extract the OAuth client support in its own module and upgrade to pac4j Resolved
- improve OAuth server support -> Jérôme & Joe McCall : CAS-1288 - Leverage OAuth server support on Spring Security OAuth library and add missing grant types Closed , CAS-1282 - Leverage confirmation screen timeout on web session timeout, not on service ticket timeout Closed and CAS-1287 - Return profile attributes according to the associated service configuration Closed
Refactor Authentication APIs
Developer: Marvin S. Addison
The present AuthenticationHandler/AuthenticationManager API components have served us well for approximately a decade. With a relatively small amount of engineering effort, we can build on these components to achieve some notable features in an elegant fashion:
- Generic authentication messaging API. The intent is to leverage this API to extend the LPPE work for LDAP handlers to arbitrary authentication backends and provide implementations for RDBMS and X.509 certificates at a minimum.
- Support for salted passwords.
- Multi-factor authentication support.