I. Introduction

This document is the specification of levels of assurance (LOA) in CAS clients and server.

The LOA is the confidence the CAS server has in the given credentials to say who the principal is.

There are a number of different factors that affect LOA:

Registration and Identity Proofing
Assurance level of the authentication token
Security of the authentication mechanism (channel encryption, etc.)
Other details of the authentication (e.g. how stale is it?)
Other policies in place (such as revocation policy)

II. Authentication API in CAS server

NOTE: This document is based on the following documents: Level Of Assurance Specification and Example LOA Use Cases

A) CAS 3.5.0

In CAS server 3.5.0, an authentication manager is in charge of validating credentials. It takes credentials as input.

An authentication manager has :

many authentication handlers, each supporting a kind of credentials and returning a principal
many credentials to principal resolvers, each supporting a kind of credentials
potentially many authentication meta data populators which add attributes to the authentication.

A credentials to principal resolver can retrieve user attributes from a specific repository and populates them in the authentication.

An authentication has :

an authentication date
attributes
a principal with identifier and attributes.

B) CAS 4.0.0

TODO Marvin : describe briefly the new design of the authentication API in CAS server 4.0.0

III. New concepts or updated ones for LOA

A) Assurance Policy (new)

The CAS server has one and only AssurancePolicy. It consists of one or more AssurancePolicyLines.

Each AssurancePolicyLine consists of:

String name - string primary key, probably no whitespace permitted
int strength - numeric value 0..100 indicating relative assurance strength of this policy line
String description - human-readable description of this policy line
List<CredentialRequirement> credentialRequirements - ordered list of CredentialRequirements that must be successfully authenticated in order fulfill the requirements for this policy.

Each CredentialRequirement consists of:

String credentialType - an identifier indicating the type of credential required
List<CredentialDetailValidator> credentialDetailValidators (optional) - list of CredentialDetailValidator beans that are used to further determine if the credential is sufficient to fulfill the requirement.

Each CredentialDetailValidator implements an interface and provides the following methods:

method boolean validateCredential(Credential) - checks to ensure that the credentials pass some specific rules

Examples of CredentialsDetailValidator:

PasswordStrengthValidator(int weakest, int strongest)
IPSubnetRange(subnetMask, subnetPrefix)

B) Authentication handler (update)

So far, an AuthenticationHandler authenticates Credentials and is defined to support a kind of Credentials.

An authentication handler will be added:

maybe: attribute name
maybe: method String getSupportedCredentialsType() - return a string representation of the type of Credentials supported by this handler
maybe: method YesNoMaybe principalHasSufficientCredentials(Principal p, String credentialsTypeIdentifier, List<CredentialsDetailValidator> validators) - given a non-null principal, determine if that principal is actually able to fulfill the credentials in question. returns an enum which can indicate an unknown state

C) CredentialsGatherer (new)

An CredentialsGatherer is a way to get Credentials. Each CredentialsGatherer is defined to support a kind of Credentials it will return when called.

This concept replaces the AuthenticationViaFormAction and AbstractNonInteractiveCredentialsAction.

There are two types of CredentialsGatherer :

InteractiveCredentialsGatherer means the user has to give inputs as Credentials. An InteractiveCredentialsGatherer is also defined with a View to display to get user inputs. At least, one InteractiveCredentialsGatherer is defined in CAS server : the LoginPageCredentialsGatherer which supports UsernamePasswordCredentials. This replaces AuthenticationViaFormAction.
SilentCredentialsGatherer means the CAS server will get by itself Credentials silently from the HTTP request. This replaces AbstractNonInteractiveCredentialsAction.

SilentCredentialsGatherer

Currently subclasses of AbstractNonInteractiveCredentialsAction are wired directly into the Spring WebFlow as action beans. (See SPNEGO and X.509 Certificates as examples.) Under the new design, there would be a generic non-interative action bean always wired into the SpringWebFlow. This action bean would be configured with a list of SilentCredentialsGatherer beans and would process each one. The beans might use session variables for caching and to reduce duplicate work.

SilentCredentialsGatherer beans might need to have the opportunity to issue redirects (to initiate silent federation, for example). However, these use cases might be better handled with InteractiveCredentialsGatherer beans instead. TBD.

Possible interface methods:

Credentials gatherCredentials(HttpServletRequest request)

InteractiveCredentialsGatherer

Currently, this is also handled using Spring WebFlow configuration (primarily via the viewLoginForm and realSubmit states). Instead, a generic view-state should replace viewLoginForm and a generic action-state should replace realSubmit. These two states would call beans that delegate all the implementation-specific details to the InteractiveCredentialsGatherer. The gatherer is responsible for selecting the view (JSP page, which could display HTML or issue a redirect), and for receiving the form post or redirect return and extracting credentials (currently handled by AuthenticationViaFormAction.doBind()).

Attributes:

String id
String displayName
String logoImageUrl
String jspViewName

Methods:

Credentials extractCredentails(HttpServletRequest)
- Alternative: something SpringMVC-specific like doBind() so that we can handle errors on fields, though I'd prefer something NOT SpringMVC-specific

D) Interaction manager (new)

An InteractionManager is the action bean that is responsible for processing authentication managers for silently-gathered credentials and for choosing next right InteractiveCredentialsGatherer to try for the currently-desired level of assurance.

The InteractionManager does this:

Locate all existing Authentication objects (results of past successful authentications)
1. These are found in the current TicketGrantingTicket
Locate all existing Credentials that have not yet been authenticated
1. These were gathered by SilentCredentialsGatherer beans in an earlier step of the web flow.
Authenticate all Credentials that haven't yet been authenticated (i.e. silently gathered ones). If successful, store in the current TGT. Create a TGT if necessary. If unsuccessful, store some kind of flag somewhere so we don't try to process the credential again.
Determine all acceptable assurance policy lines, based on incoming parameters, attributes of the registered service, and defaults.
If the current set of Authentications is insufficient to satisfy any acceptable assurance policy lines, determine which types of credentials would be necessary to come into compliance.
If multiple types of credentials would be valid, choose one based on pre-configured preferences/rules. Place the others into a list and put that list.
Locate the corresponding InteractiveCredentialsGatherer.
Locate InteractiveCredentialsGatherers for all of the alternative possible credentials, and put those into a list.
Show the view for the selected InterativeCredentialsGatherer.

E) Ticket Granting Ticket (update)

The ticket granting ticket needs to be updated to support a list of Authentication objects instead of only a single Authentication object.

F) Authentication manager (update)

The authentication manager takes credentials and returns an authentication. Currently it is called directly by SpringMVC actions (such as AuthenticationViaFormAction and subclasses of AbstractNonInteractiveCredentialsAction). Instead, the new CredentialsGatherer beans will be calling the authentication manager.

The authentication manager will always store the following attributes in a successful Authentication object:

name of the authentication handler
name of the credentials type

G) Registered service (update)

So far, a registered service supports attributes : id, name, theme, description, isAnonymous...

New optional attributes:

List of acceptable named lines from the assurance policy.
Minimum acceptable LOA value

If both are listed, that means: "Accept any value greater than or equal to the minimum, PLUS any lines listed by name."

H) Assurance evaluator (new)

Given a TGT containing a list of successful Authentication objects, the assurance evaluator computes two things:

a numeric value indicating the maximum assurance that is guaranteed by this set of Authentication objects. (This is the row with the maximum value such that all lines with lesser values are also fulfilled.)
a list of all lines of the assurance policy that are fulfilled by this set of Authentication objects

IV. Extension to CAS protocol

So far, the CAS server supports the renew parameter set to true to force re-authentication whatever the current authentication is.

LOA requirements can be specified using a new parameter named "loa":

loa=<number>
- Any lines in the assurance policy that matches this strength or greater are all acceptable.
loa=<comma-separated-list>
- Any lines named in the comma-separated list are all acceptable.
loa=<number>,<comma-separated-list>
- Any line in the assurance policy that matches this strength or greater OR any lines named in the comma-separated list are all acceptable.

V. Main algorithm

A) Diagram

G) Communication with Client

Ideas for a new CAS Protocol for Ticket Validation Response

Possible CAS Protocol 4.0 ticket validation response

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
  <cas:authenticationSuccess>
    <cas:user>${principal.id}</cas:user>
    <cas:proxyGrantingTicket>${pgtIou}</cas:proxyGrantingTicket>

    <cas:proxies>
       <cas:proxy>${proxy.principal.id}</cas:proxy>
       ...
    </cas:proxies>

    <cas:user-attributes>
      <cas:attrib name="${attrib.key}">${attrib.value}</cas:attrib>
      ...
    </cas:user-attributes>

    <cas:loa-number>${max_loa_number}</cas:loa-number>
 
    <cas:levels-satisfied>
       <cas:level>${level.name}<cas:level>
       ...
    </cas:levels-satisfied>

    <cas:auth-handlers>
      <cas:auth-handler name="${authhandler.name}">
        <cas:attrib name="${attrib.key}">${attrib.value}</cas:attrib>
        ...
      </cas:auth-handler>
      ...
    </cas:auth-handlers>
  </cas:authentication>

  </cas:authenticationSuccess>
</cas:serviceResponse>

Added sections:

NOT NECESSARILY RELATED TO LOA: user-attributes - contains attributes of the user (principal)
- attrib - subject to the attribute release policy associated with this service - basically the same as the attributes in the SAML validation response
loa-number - the maximum number associated with any of the satisfied levels of assurance
levels-satisfied - list of the names of all assurance levels that were satisfied by the users's current session
- level - the name of the level of assurance
MAYBE: auth-handlers - list of all auth handlers that have successfully authenticated for the user's current session (i.e. authentication objects) - note: this might not be needed or desired

auth-handler - an individual auth handler; the "name" XML attribute contains the name

attrib - each attribute in the authentication object can be listed here. probably require deployer to specify which attributes should be released, or maybe include a release policy for registered services similar to that for user attributes

VI. Use cases

See Example LOA Use Cases

VII. Roadmap

A) Step 1 : only client requested LOA

For a first step, the idea is to target only the LOA requested by the client (renew parameter).

It means creating the assurance policy, level of assurance and assurance evaluator, updating the authentication handler and the authentication manager and implementing the main algorithm (impacts on webflow).

B) Step 2 : add server requested LOA

For a second step, we can add the requested LOA defined in CAS server.

It means updating the registered service, the services management webapp and the main algorithm.

C) Step 3 : add interactions

For a third step, we can finally add the interactions and interactions manager and update the main algorithm (impacts on webflow).

Second Level Of Assurance Specification