Multi-Factor Authentication

Due to regulatory considerations (among other things), multi-factor authentication is becoming an increasingly important use case for CAS to consider. Closely tied to the notion of multi-factor authentication is the fact that different CAS clients may have different authentications needs that the CAS server must satisfy.

CAS currently supports every type of authentication that HTTP allows (password in a form, X.509 Certificate, SPNEGO, container managed). Passwords can be authenticated through a JAAS plugin, or by LDAP, JDBC, Radius, and so on. However, in the current implementation CAS stops when any available credential succeeds in establishing an identity. Thus if you have a valid X.509 Certificate, you never see the form prompting you for your password. This has been a convenience in the past, but in muliti-factor authentication you login with more than one credential. Typically one credential is something you have (like an X.509 Certificate installed in the browser) and something you know (like your password).

Multi-factor authentication is not meaningful if the two credentials presented are interchangeable. For example, if you have a CAS-enabled Public Key Infrastructure that will issue User X.509 Certificates to anyone who can authenticate to CAS with his password, then such a certificate is not a second factor because it proves nothing more than the password itself. However, a certificate that is issued through an independent process separate from the normal password could be a second factor.

Since everyone has a cell phone these days, a common second factor of authentication would be an application that runs on the cell phone that generates an ID string that changes every few minutes and has a value specific to your identity. If this string can be authenticated through one of the existing password validation mechanisms (JAAS, LDAP, JDBC, Radius) then the existing CAS Authentication Handlers can be reused for this purpose. In other cases (for example if the string must be validated through a Web Service or a call to a vendor supplied JAR) a new Authentication Handler will have to be provided.

Multi-factor CAS will process more than one credential when it has reason to believe that you want this behavior. Typically, CAS will try to acquire more than one credential when it is trying to log someone in for the purpose of issuing a Service Ticket for a service that requires an additional factor of authentication, but the exact trigger for this behavior will be a configuration option.

When you login successfully, CAS generates a browser Cookie to identify your login ticket which contains your Principal (userid, netid) and an Authentication object indicating the mechanism you used to login. Multi-factor CAS must extend this mechanism to keep track of more than one Authentication, each representing a different factor.

For multi-factor CAS to work every credential presented must resolve to the same Principal name. If this is not true, some type of error will be generated.

Use Cases

Current CAS Default

The current CAS any-single-factor authentication model is the default CAS behavior.

Specific Authentication Type required

An application requires a specific type of authentication and interacts with CAS so that a user acquires the necessary level of authentication to access the application.  The application does not require proxy authentication.

Specific Authentication Type required - application needs to proxy

An application requires a specific type of authentication and interacts with CAS so that a user acquires the necessary level of authentication to access the application.  The application does not require proxy authentication.

Specific Authentication Type required - multiple proxies

Specific Type of Authentication Needed

In this use case, a user attempts to access an application that requires a specific type of authentication (i.e. Safeword or RSA). This is not a case of multiple factors since only one specific factor is required, but it will utilize the same logic to be more specific in selecting the authentication credential than the current "use the first one that works" approach. The default type of Authentication is "NetidPassword" which is assumed when no other type is specified, and all existing services are assumed to require "NetidPassword" Authentication unless configured otherwise.

Specific Level of Authentication Needed

In this use case, a user attempts to access an application where a particular "level" is required. I.e. If Level 1 is required, something that meets Level 3 is sufficient (but not the reverse). In a simple example, presenting the current NetidPassword may satisfy Level 1, and then any additional factor of authentication that is not equivalent to NetidPassword could raise the authentication to Level 2. Services that require no specific level are assumed to require Level 1 ("NetidPassword" Authentication).

Specific Group of Authentication Needed

In this particular case, there may be a number of authentication methods that satisfy a requirement (and other than being grouped, there is no relationship in terms of one being stronger than another, etc.). For example, a service may accept any authentication method that is certified as meeting a FIPS standard.

Specific Chain of Authentication Needed

In this use case, a user attempts to access an application where a particular set of authentications must be present (ordered) (i.e. password, safeword)

Specific Set of Authentication Needed

In this use case, a user attempts to access an application where a particular set of authentications must be present (un-ordered) (i.e. password, safeword)