Warning

This document is no longer being maintained. Please see CAS Roadmap for current information.

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.3.1
Upcoming Version: 3.3.2

Goal	Description	Interested Parties	Work Effort	Dependencies	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, USF	Medium	None	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	None	Ongoing
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	Database Schema Modification	Requirements Gathering
InfoCard/CardSpace Support	Add support for CardSpace and InfoCard to the list of authentication methods supported.	DICTAO	Medium	None	Research Phase
Second-Level CAS Server	Allow one CAS server to delegate initial authentication to another CAS server.	UC-Berkeley, Unicon, Rutgers	Small	None	Under Consideration

CAS Server 4.x

Vision: CAS4 aims to simplify federation and attribute exchange in the same-fashion that CAS1 and CAS2 simplified single sign on authentication. From an architectural standpoint, CAS will be designed to support emerging use cases and developing standards including OpenId, OAuth, SAML, and others. In addition, recognizing SSO and authentication's significance as part of the overall infrastructure of an organization, CAS4 will be designed to be more easily administered, monitored, audited, etc.

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

Goal	Description	Interested Parties	Work Effort	Dependencies	Status
Internationalization	Continue to improve support for Internationalization including more languages, as well as more messages being internationalized, including log messages.	Rutgers - English ESUP-Portail - French	Medium	CAS4 Architecture Language Experts
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	CAS4 Architecture
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.	TAMU/CIS, USF	Larger	CAS4 Architecture
Functional Tests	Include functional tests to test CAS use cases on each commit.	DICTAO	Medium	None
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	CAS4 Architecture
Configuration Wizard	Allow CAS to be configured by a web interface, possibly including a configuration wizard.	LSU	Huge	None (though a design done in CAS3 might not work in CAS4)
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. This could include display/management of currently valid tickets.	Rutgers LSU TAMU/CIS USF	Medium	None (though a design done in CAS3 might not work in CAS4)
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	CAS4 Architecture
Levels of Assurance, Specifying lowest Level of Assurance at login in service	Allows services to specify a minimum level of assurance (essentially, renew with multiple levels of security). For example a personalized page may just need an simple self asserted identity (I say that it's me), a student portal need an proofed identity with a username and password login and a web page where examiner report the students results may need a onetime password (OTP) or certificate login. A service can say I need a minimum of LoA2 (proofed identity with username and password login) for the service. If the SSO session was created using at with an authentication that mets up to LoA2 and the user administration of the user mets up to at least to LoA2, then everything is okay, otherwise CAS will prompt for a new login with a list of autentication handlers that support LoA2 or higher. The level of assurance should also be passed back to the service for validation on their end. Fore more information on this please see "Support for LoA in CAS" in CAS wish list. There is also a work on level of assurance in eduPerson at present (May 28 2008) it's a draft put will be published later this year in the next version of eduPerson (2008xx).	Rutgers Uppsala universitet (together with more universities in Sweden) Virginia Tech		CAS4 Achitecture
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 LSU	Enormous	CAS4 Architecture
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	CAS4 Architecture
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. Support for non-CASifiable applications includes the ability to pass the password back to applications that don't support CAS proxying capabilties. Andrew Petro has nicely document this use case: Sneak Password Back to Trusted Applications	Unicon, Inc. Rutgers Sacramento State	Medium	None	Discussion
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		CAS4 Architecture (OAuth replacement?)
Hardening/Anti-Phishing	CAS should support emerging use cases involving CAPTCHA, the image/text prompt associated with a specific user, etc.	Rutgers	Large	None
Display Warnings from backend systems	Be able to display warnings such as "password expiration in 10 days", etc. or other messages	Rutgers USF	Medium	CAS4 Architecture
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).			CAS4 Architecture
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		None for Server Configuration CAS4 Architecture for User Negotiated
Multi-factor authentication	Support requesting multiple types of credentials from a user.
Better clustering support	Improved clustering support for both clients and servers.	LSU	Large	CAS4 Architecture
Password Encoding with Salt	Support the use case of examining passwords encoded with a salt.		Small	None (other than its an API change)
Improved Documentation	More complete documentation detailing entire system including obscure configuration options that are hard to find, but potentially useful.	Everyone	Large	None (other than time )
Governance Model	A more formal, but lightweight, procedure for guiding the evolution of the CAS Server and Client projects.	Everyone	Large	Approval from Community
Application SuperUser	Allow SuperUsers for specific applications to be able to select a user to become after authenticating. Would need a way to determine who is superuser for what app, possibly via attributes listed in whitelist entries. Would possiby also need to break SSO	Rutgers	Medium	CAS4 Architecture
Authorization/Access Control via Second CAS Server	See Howard Gilbert's CAS-NG Talk	Yale	Medium
Terms of Agreement Sign on flow after authentication	Ability to plugin a new subflow - related to agreement sign in before redirection to requesting service. Validation of credentials should not be in createTicket method but a separate method must be created for this - so that other users can plug in a behavior before ticket is created.	ST	Small

CAS Server 5.x

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