Warning
This document is currently in draft state. Anything is subject to change. Wording may not be precise as it needs to be, etc. Look at it at your own risk

CAS Vision and Roadmap (All Versions)

This page attempts to detail the current visions and roadmap for future versions of the major CAS branches. This is an evolving document.

CAS Server 3.x

Vision: The CAS 3.x architecture has been in production usage since June 2005, and is fast approaching its third birthday without any major architectural changes (the actual architecture design was started in December 2004). While the current architecture has served CAS well, and can continue to support new features (see below), it cannot support many of the emerging use cases. Thus, while the CAS Server 3.x software should continue to evolve and adopt new features when it can, it should not try and "force" in any of the major emerging use cases that require a different architecture. Essentially, the current vision for the "mature" code base is to continue to support features where possible, and defer any major architectural changes to the CAS 4 release.

Current Status: Under Development
Current Version: 3.2.1
Upcoming Version: 3.2.2

Goal	Description	Interested Parties	Work Effort	Status
Registration Page for Services	Offer a registration page/workflow to allow people to request access to CAS. Ties in with Services Management tool and eliminates the need for deployers to handle workflow manually or create their own tool.	Rutgers	Medium	Requirements Gathering
Library Upgrades	Continue to upgrade minor point releases of libraries to gain new features and bug fixes. Includes Spring Security 2 and JBossCache 2	Rutgers	Small	In Development
Service Priority for Services Management Tool	Allow services to be ordered, or have a default "most specific" matches to allow for "catch-all" Services.	Rutgers, VCU	Medium	Requirements Gathering
RESTful API	Expose a RESTful API to allow for non-browser interaction with the CAS server such that services without a human can still authenticate and participate in an SSO session.	Rutgers	Medium	In Development
InfoCard/CardSpace Support	Add support for CardSpace and InfoCard to the list of authentication methods supported.	DICTAO	Medium	Research Phase
LDAP ServiceRegistry DAO	Support an alternative method for storing services via LDAP instead of the database.	UC-Berkeley	Small	In Development
"Second-Level" Trust CAS Servers	Allow one CAS server to delegate initial authentication to another CAS server.	UC-Berkeley, Unicon, Rutgers	Small	Under Consideration

CAS Server 4.x

Vision: The CAS 4.x server will be designed from the ground up to support emerging use cases and developing standards as well as advanced administration features. It will strive for compatibility with public APIs from the 3.x branch, but makes no guarantees where those public APIs would not support the emerging use cases. It is understood that where it makes sense, features from CAS Server 3.x branch will be available in CAS 4. For example, the CAS 2 protocol would be supported, but legacy support for the CAS2 PasswordHandler may not be. CAS 4 should strive to be as feature complete as CAS 3 (thus considered to be a step forward, and as production-ready as CAS 3, with the understanding that certain considerations in the CAS 3 design do not make sense in CAS 4).

Current Status: Features Under Consideration
Current Version: N/A
Upcoming Version: N/A

Goal	Description	Interested Parties	Work Effort
Internationalization	Continue to improve support for Internationalization including more languages, as well as more messages being internationalized, including log messages.	Rutgers - English	Medium
Re-architecture to support emerging use cases	The CAS core has served it well for a plethora of years. However, emerging use cases and standards are stretching the architecture. The Server 4.x architecture should support these emerging use cases. Even if the use cases aren't added in the first release, the architecture should be designed such that they can be added later.	Rutgers	Huge
Integration with Existing Account Management Systems	Provide integration points and flow disruptions for events such as password expiration, account locking, etc. to be conveyed to the user, or allow for another application to handle.		Larger
Functional Tests	Include functional tests to test CAS use cases on each commit.	DICTAO	Medium
Minimize XML configuration	Utilize sensible defaults, convention-over-configuration, annotations, etc. to reduce the amount of XML that is required to just what is necessary for deployers to set up.		Medium
Configuration Wizard	Allow CAS to be configured by a web interface, possibly including a configuration wizard.		Huge
Administration Summary Views	Expose internal state of the CAS system to administration views (possibly via a web interface or via JMX) so that administrators can monitor the system.		Medium
Advanced Remember Me Support	Advanced Remember Me Support expands on the basic support in CAS3.x and offers the ability to change cookie identifiers per request, better notify applications about remember me (combined with LOA?), etc. This could also include support for variable expiration policies and used selected expiration policies.	Symentis	Medium
Levels of Assurance, Specifying Authentication Type	Allows services to specify a minimum level of authentication (essentially, renew with multiple levels of security). A service can say I need a minimum of One Time Use Card and if the SSO session was created using that, then everything is okay, otherwise CAS will prompt for a one time use password. This information should also be passed back to the service for validation on their end.	Rutgers
Federation	CAS should support the Federation use case. The architecture should support both the federation use case where a group is involved (i.e. InCommon) or ad-hoc federation, such as OpenId.	Rutgers	Enormous
Emerging Standards	The CAS architecture should support communicating with client applications (service providers) over varying protocols, and able to negotiate each one separately (instead of forcing all apps to use the same protocol). This could lead to different applications supporting various options (i.e. some will be able to do single sign out, and some won't). Emerging standards include SAML2, OpenId, OAuth, etc.	Rutgers	Enormous
Support Non-CASifiable Apps	Currently CAS can negotiate with applications that do not support the CAS protocol. This support should be extended, documented, and supported.	Rutgers
Improve PGT callback protocol performance/scalability	The PGT callback in the CAS2 protocol fails under excessive load, as well as when services are located in a cluster (unless the CAS client app understands clustering).	Rutgers
Hardening/Anti-Phishing	CAS should support emerging use cases involving CAPTCHA, the image/text prompt associated with a specific user, etc.	Rutgers	Large
Display Warnings from backend systems	Be able to display warnings such as "password expiration in 10 days", etc. or other messages	Rutgers	Medium
Ability for a SP to Programmatically determine if an SSO Session Still Exists	Similar to the gateway feature, but programmatically. May be negated by support for single sign out (which notifies when a session no longer exists).
Return User Attributes	Return User Attributes (biodemographic data, authentication information, etc.) to the service requesting it. Can either be configured via a server tool or negotiated between user and application.	Rutgers
Multi-factor authentication	Support requesting multiple types of credentials from a user.
Better clustering support	Improved clustering support for both clients and servers.		Large
Password Encoding with Salt	Support the use case of examining passwords encoded with a salt.		Small

CAS Server 5.x

You didn't actually think there'd be anything here yet, did you?