Deprecated

This document is not longer maintained or valid. Please refer to the official CAS documentation at apereo.github.io/cas/ to learn more.

CAS Roadmap

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.

Release Strategy

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, 2.5.0.1 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
William G. Thompson, Jr., Unicon via Open Source Support

CAS 4.0 MAJOR Release

Schedule

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

Scope

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.

Other tasks planned for 4.0 :

move out the services management webapp from CAS server webapp -> Jérôme : CAS-1183 - Getting issue details... STATUS
make SAML support optional in a specific module -> Marvin / Jérôme : CAS-1188 - Getting issue details... STATUS
improve client protocols support -> Jérôme : CAS-1286 - Getting issue details... STATUS
improve OAuth server support -> Jérôme & Joe McCall : CAS-1288 - Getting issue details... STATUS , CAS-1282 - Getting issue details... STATUS and CAS-1287 - Getting issue details... STATUS

Refactor Authentication APIs

Developer: Marvin 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.