CAS 5 Roadmap

The purpose of this page is to gather all proposals and define the new design of CAS server version 5.

The idea is really to draw the design target and reach it through a succession of incremental CAS server version (4.x -> 4.y -> 4.z -> ... -> 5.0): small steps instead of a big bang (seamless transition between versions 4 and 5).

Proposed components

1) AuthenticationService

It deals exclusively with authentication concepts e.g. Credentials, Principals, producing valid Authentication objects, etc.(using our AuthenticationManager machinery underneath, etc.) (Dima)

The idea would be to have an API that could be invoked repeatedly with distinct credential type(s) (for interactive multi-staged authn flows that would authenticate at each step as opposed to gather all credentials and send them for authentication in one batch). This API would be invoked directly by UI flow components. At the end of this logical “authentication transaction” some kind of a composite object that gathers all the authentication attempts, perhaps resolved principal, and other useful authentication metadata would be created. This “authentication transaction descriptor” could then be passed on to the Ticket/Sso service (by appropriate UI component (e.g. SWF state)) so that tickets could be vended (or not vended) based on the entire authentication transaction, etc.

CAS.createTGT(final Subject subject)  where subject is a container for any number of principals and authentication metadata perhaps using  javax.security.auth.Subject directly. (Bill)

-> Use Spring Security or Shiro?

-> Support for MFA?

2) StorageService

It deals with tickets / Factor out ticket storage concerns into a high-level storage service component (Dima)

Factor out ticket storage concerns into a high-level storage service component (Marvin)

This component will allow us to have a single integration component for storage-specific backends instead of multiple as we do now; for example, a single DatabaseStorageService that could be used for both tickets and services instead of JpaTicketRegistry and JpaServiceRegistryDaoImpl. That seems beneficial from a support perspective as much as design; one fewer component to keep up with as the technology-specific integration libraries (Hibernate, spymemcached, Infinispan) change.

-> Services + Tickets?

3) UI

AuthenticationService and SsoService are high level APIs that the UI (SWF) layer could use at appropriate times to compose complex authentication transactions in a decoupled manner. (Dima)

(Misagh) Think of this in MFA terms: you want to authenticate the user at every step, invoking this facade on multiple types of credentials again and again from this and that flow and subflow and keep collecting. You can do this indefinitely until you come to a point where you decide, “I am OK. Give me the TGT” at which point CASImpl would be get involved. Your collection needs to include enough metadata about the individual authentication event so that if the TGT needs any, it would have enough to proceed.

4) Session manager

(Marvin)

It has 4 concerns:

Others

Security

I'm still catching up on most of the thread (at which point I'll reply to specific points), but I did just want to call out one of the reasons there is sometimes a slightly rigid structure/call-pattern: basically as a security product, how do we balance flexibility with ensuring you don't accidentally break/skip/avoid a critical step in the flow.

We previously did that with one entry point (with Bill calling out that createTGT took in Credentials to ensure that we had a valid person before we created a session) but with extension points. I'm not saying that's the best option going forward, but as we introduce more flexibility, just keep in mind that as a security product we want to make it hard for people to do the wrong thing (otherwise a lot of our own hardening/analysis becomes moot).

Possible high level subsystems design

https://drive.google.com/file/d/0Bw8LSvcVZrEvdVdibnVKQ2E0aWs/view?usp=sharing