The following items are proposed to fit the scope of the CAS 4.3 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. 

Open Items

Surrogate Principal

Provide the ability  for the CAS authn subsystem to allow one to login as another. This would be useful for troubleshooting purposes via special service accounts. Consider how the surrogate principal can be audited at the CAS server level, and how the proxy principal can be communicated back to the app in the CAS validation response. 

Proposed by William G. Thompson, Jr.

Consenting to Attribute Release

Provide an optional webflow to allow CAS to display a list of attributes that may be released to the application. This is similar to what uApprove does. Provide an option for the user to accept the release and a way to CAS to remember the user's choice. 

Proposed by Misagh Moayyed

OpenID Connect

Deliver OIDC functionality. Focus on AuthZ Code profile, and then move onto additional config. 

Proposed by Jérôme LELEU

Front Channel SLO

The existing front-channel SLO feature in CAS4 is still experimental. Improvements could be made in terms of UI or client integration. 

Rather than dancing with the client, we could directly call apps from the CAS logout page/flow to logout. This can securely done in parallel invocations (via hidden images, iframes, etc) and possibly may require the creation of a new field in the service registry for "logout urls". We would need a specific url for logout that would be used for front channel SLO, with logout message that is SAML-like, which is to include the service ticket. The message can be hashed and zipped and sent along as a GET request. This would allow the CAS server to present 3 SLO options:

1. Back channel
2. front-channel with specific logout URL; also useful in cases where the app does not have proper client support for SLO
3. front-channel with no logout URL; in this case we simply call the service url as before which is useful for cases where there is no specific url for logging out on the app side.

This may require mods to the protocol.

We have to be VERY careful with the wording of front-channel SLO on the UI. We cannot never guarantee a logout from the app POV, but can emphasize that a logout message has been sent to the application. It is still up to the application to decide how to handle the logout.

Proposed by Jérôme LELEU

Oauth server support

CAS server can be customized to act as an OAuth server. Presently the OAuth implementation requires that the client receives the TGT to pass to the profile as an access token. Also, the implementation attempts to release all attributes rather than those are allowed due to the limitations in current design. The following alternatives may be used instead:

1. Rather than passing the TGT directly to the client, we simply encrypt the entire CAS validation response at the time of authorization using a technology such as JWT. The encrypted response is sent to the client, and submitted back again to the profile endpoint at which point it is decrypted again and attributes are released.
2. Alternatively, rather than encrypting the whole response we could just simply encrypt the TGT and the service and pass it along to the client, which when received again as the access token, would be decrypted to release user attributes.
3. Or, we could design a new ticket type, that is a true access token made up of random strings that is passed to the client. This would replace the TGT as the token, and does not require any kind of decryption.
    

Spring Security's OAuth support may be a candidate to review.

Proposed by Jérôme LELEU

Done Items

Authentication Per Service

In some cases, it may be required of the CAS server to select the authentication scheme on a per-app level, something that may be configured inside the registry. Upon selection, CAS may try to find all handlers that support that scheme, and delegate the authn request to those only that claim support.

Proposed by Misagh Moayyed

MFA Support

Extend the existing capabilities of the CAS server to provide authentication flows for MFA. Consider MFA triggers that are per service or per user group. Consider support for MFA providers such as Duo Security and Toopher. For this release, we may simply just end up doing the groundwork, paving the way for future extensions to connect to Duo, etc. Unicon has developed a cas-mfa extension that can be used to inspire ideas and design guidelines. 

Consider:

• Trusted device/browsers
• Tracking metadata about the authn event (i.e. ip, location, browser, device, etc)
• Risk-based authn and assessment

Proposed by Misagh Moayyed, William G. Thompson, Jr., Jeremy Jeremy, Sean Baker

Java 8 Support

Since JDK 7 has become EOL, an effort should be made to consider building CAS on top of JDK 8. We'll need to take a closer look at our javadocs and resolves issues that the JDK compiler may complain about with a much more strict policy around javadoc gen. 

Proposed by Misagh Moayyed

Gradle Build

Allow CAS to be built via Gradle. The current build and release process is very sluggish with Maven, and we could take advantage of Gradle's declarative configuration and daemon to expedite things much faster. 

Proposed by Misagh Moayyed

Containerize CAS via Docker

Provide official CAS docker images as an alternative to the Maven overlay deployments. 

Proposed by Misagh Moayyed

JWT/StormPath AuthN via Pac4j

Implement JWT/Stormpath functionality via Pac4j. Ensure configuration is automatically available. Document. 

Proposed by Jérôme LELEU,Misagh Moayyed

SAML2 WebSSO Profile

Implement SAML2 WebSSO profile for SAML SPs, thereby making CAS a SAML IDP provider. Ignore all other profiles. 

Proposed by Jérôme LELEU,Misagh Moayyed