...

Open Items

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

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

Management App Facelift

The CAS services management webapp is in dire need of attention. Improvements to UI, display of fields as well as support for OAuth services, attribute filters, and other service settings and types would be considered. 

...