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

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