CAS Vision and Roadmap
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 |
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 | Medium | CAS4 Architecture |
|
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) |
|
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 | 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 |
| 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 | 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. | 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 | 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 |
|
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 |
|
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. | ST | Small |
|
|
CAS Server 5.x
You didn't actually think there'd be anything here yet, did you?