Deprecated

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

The following items are proposed to fit the scope of the CAS 4.2 release. We are just focusing on the big picture here. Other smaller issues may also be fit candidates depending on the nature of the change. Items discussed on this list are in no particular order of priority.

Scope

This document specifically addresses the scope for the CAS Server 4.2. Features for official CAS clients that would want to take advantage of 4.x features should be documented and discussed elsewhere.

All about draftness!

This is just a draft and may be heavily edited as development moves on. Items that will not fit the release schedule and timeline will be removed from this list. We are just trying to gather and collect proposals for the release.

Done Items

Pac4j Integration

Allow CAS to take advantage of Pac4j Authenticators to deliver functionality such as JWT and Stormpath integration, as well as a rest client for CAS Rest API.

Proposed by Misagh Moayyed, Jérôme LELEU

REST API for Services

Provide a REST API for applications to dynamically register applications with CAS. Provide authZ rules based on attributes.

Proposed by Misagh Moayyed

Encryption of ticket registry data

Encrypt/Hash the ticket registry as appropriate to avoid people either stealing or tampering with the registry, either in the wire, in memory or on disk. Proposed by Proposals to mitigate security risks under SEC-9.

Proposed by Jérôme LELEU

ADFS Support

Allow CAS to act as ADFS proxy, accepting ADFS claims from an ADFS IdP and translating those assertions to something that CAS clients can understand.

The extension developed by John Gasper should be perfectly plausible here.

Proposed by Misagh Moayyed, John Gasper

CAS SSO Session Info

Allow CAS the ability to list the following info for all SSO Sessions:

Ability to kill the TGT, thus logging the user out
Display a list of applications that the TGT has authorized access to.
Consider how the functionality of the existing SSO Sessions Report can be leveraged here
Also consider how the functionality can be differentiated from an admin perspective, having access to all sessions vs. one that an individual user may be allowed to view and adjust. (i.e. A user may want to kill a danlging sso session commenced in a different browser/device)

Proposed by William G. Thompson, Jr., Misagh Moayyed

SAML/Social SP Support

Allow CAS to act as SAML SP proxy, accepting SAML assertions from an external SAML IDP and translating those assertions to something that CAS clients can understand. Same goes for all other social providers such as Facebook, Twitter, etc.

The pac4j library should be of service here, developed and sponsored by Jérôme LELEU

Proposed by Misagh Moayyed

Feature Auto-configuration

Presently, adopters are forced to configure a multitude of XML/properties files in order to deliver CAS functionality. Much of this configuration can be hidden from the deployer, and we could only expose settings that are relevant for the feature that is to be turned on. CAS could take advantage of scanning the context to see what settings are defined, and based on that decision turn on additional functionality with the configured properties.

Allow CAS configuration to dynamically detect which features and modules are enabled, so it can start to auto-configure the required application context without requiring the CAS deployer to modify XML configuration. Changes expected of the deployer should be solely limited to configuration of properties where possible.

Proposed by Misagh Moayyed

DuoSecurity/YubiKey Support

Allow CAS to leverage DuoSecurity and YubiKey for authentication. This should be viewed as the first leg to the MFA implementation.

Proposed by Misagh Moayyed

Time-based Access Control

Extend the current CAS access control policy for services to support enabling/disabling service access based on a given date/time.

Proposed by Misagh Moayyed