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)

Related documentation:

Discussion on the cas-dev mailing list: https://lists.wisc.edu/read/messages?id=18431743
NIST Electronic Authentication Guideline
- Key areas of interest:
  - Section 5: Registration and Issuance Process
  - Section 6.3 - Token Assurance Levels (pp 48-54)
  - Really, the whole document is very interesting and directly applicable
E-Authentication Guidelines for Federal Agencies
- Key areas of interest
  - Section 2.2: This is an interesting discussion of risk assessment - addresses the question: "Why do we want LOA?"
  - Section 2.4: Examples of various levels
Incommon Assurance Policies Bronze and Silver
- Key areas of interest
  - Section 4.1: Summary of Identity Assurance Criteria
Authentication Contexts for SAML 2.0
- Key areas of interest
  - Section 3.4: Authentication Context Classes list

II. Authentication API in CAS server

NOTE: This document is based on the following documents: First Level Of Assurance Specification - Discussions 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)

I do not understand what is the advantage of giving up SWF/MVC capability to deal with lower level concerns like state management, http request binding and validation over re-inventing custom mechanisms to do essentially the same. I'd rather concentrate on the business domain of authentication/assurance than re-inventing the wheel. (Dmitriy Kopylenko)

From Jérôme Leleu : I'd like to avoid pollution on this document, but this requires an answer. I may not have been very clear, but this document must be cross-read with the first LOA spec and for both, the reader must focus on concepts more than on technical implementations details which may be discussed futher. Last tuesday, we had a conf call and this point (using or not SWF) was a key discussion : if I understood everything clearly, we came to the loose agreement of using SWF.

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.

NOTE: currently the SWF action (AuthenticationViaFormAction) does not use AuthenticationManager directly, but instead the CentralAuthenticationService facade API is used (Dmitriy Kopykenko)

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

Note: Would it be better to use a JSON format validation response for the new CAS protocol response? Easier to parse, less clumsy, more concise? -Andrew Petro

VI. Use cases

See Example LOA Use Cases