CAS 4.2 Roadmap
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