Versions Compared

Old Version 7

changes.mady.by.user Nathan Kopp

Saved on

compared with

New Version Current

changes.mady.by.user Andrew Petro

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

I. Introduction

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

...

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 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.

...

  • 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.

...

  • 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.

...

  • 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.

...

  • 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()).

...

  • 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:
  1. Locate all existing Authentication objects (results of past successful authentications)
    1. These are found in the current TicketGrantingTicket
  2. 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.
  3. 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.
  4. Determine all acceptable assurance policy lines, based on incoming parameters, attributes of the registered service, and defaults.
  5. 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.
  6. 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.
  7. Locate the corresponding InteractiveCredentialsGatherer.
  8. Locate InteractiveCredentialsGatherers for all of the alternative possible credentials, and put those into a list.
  9. 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=<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

...

  • 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

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).

NEW Jérôme :

D) Step 4 : add interrupt screens

By extending the current LPPE feature, a mechanism of interrupt screens could be created.

E) Step 5 : return "real" SAML information to clients

It would be usefull to return "real" SAML information, i.e. authentication contexts to the client through SAML validation.

F) Step 6 : support SAML authentication requests

To be able to handle very complex client requests on LOA with many parameters (and without previous definition on CAS server), the CAS server should be able to handle SAML authentication requests on /login url.