Versions Compared

Old Version 3

changes.mady.by.user Nathan Kopp

Saved on

compared with

New Version 4

changes.mady.by.user Nathan Kopp

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

I. Introduction

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

...

II. Authentication API in CAS server

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)

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

...

  • List<String> supportedCredentialsTypes- list of string representations for the types of credentials that might be gathered by this gatherer
    • alternative:  boolean supportsCredentials() method
  • For InteractiveCredentialsGatherer
    • getView() - returns something that can be used to initiate a spring web flow
    • that web flow will result in an Action that creates a "Credentials" object
    • actually, I think it would be better if interactive credentials gatherers could be plugged-in without modifying the web flow XML

D) Actions and Web Flow (updated)


The logic for authentication actions (such as AuthenticationViaFormAction) and corresponding web flows might need to be be updated and generalized.  I'm not quite sure how yet, but the goal would be to allow pluggable actions and credential gatherers without the need for updating the spring web flow or duplicating any of the login found in AuthenticationViaFormAction.  Probably generalize in a way similar to AbstractNonInteractiveCredentialsAction.  Here's a possible type hierarchy:

  • AbstractCredentialsAction
    • AbstractNonInteractiveCredentialsAction
    • AbstractInteractiveCredentialsAction
      • AbstractAuthenticationViaFormPostAction
      • AbstractAuthenticationViaRedirectAction - note that this maybe could be handled on the "non-interactive" side better (consider existing OpenID and OAuth variations)
It might be good to re-think this whole concept in order to make it pluggable without the need to change the web flow.  Maybe there would be one extension point in the web flow where CAS calls a list of all installed non-interactive actions and associated handlers.  (The actions extract credentials from the HttpRequest and the handlers process those credentials.)  Then there would be a second extension point...

E) Interaction manager (new)

An InteractionManager is in charge of finding the right CredentialsGatherer to try for a given CredentialRequirement.
The InteractionManager provides the following methods:
  • getGathererForCredentials(CredentialRequirement) - given a particular credentials requirement, find an appropriate gatherer

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

G) Authentication manager (update)

The authentication manager takes credentials and returns an authentication.  The actions (see D) are responsible for gathering ...
------ NOTE: THIS DOCUMENT IS CURRENTLY INCOMPLETE... TEMPORARILY STOPPED EDITING HERE.... I WANT TO RETHINK A FEW CONCEPTS... ------

H) Registered service (update)

So far, a registered service supports attributes : id, name, theme, description, isAnonymous...
To support LOA, it will now define what authentication handlers it supports. None selected means all.
I think it would be better for the registered service to define a list of assurance levels (from the server's policy) that it accepts. -Nathan

H) Assurance evaluator (new)

The assurance evaluator is in charge of evaluating the LOA of the authentication given as input. It returns a numeric value.
Generally, it returns the numeric value of the LOA associated with the authentication handler used to authenticate previously the user and stored in the authentication.
In case of remember-me, the LOA returned is not the one of the authentication handler but is computed.

...

I would like to redefine the assurance evaluator as the system that evaluates the assurance attribute constraint expressions and determines which level(s) of assurance (single number and possibly multiple names) are fulfilled by the current set of user authentication objects. -Nathan

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.

...

Note that I've simplified the concept of the "constraint expression" so that it basically is simply an ordered list of authentication handlers (with attributes) that all need to be fulfilled.  I've eliminated "OR" and grouping, since these can be handled in other ways.

V. Main algorithm

A) Diagram

B) Requested LOA

1) Client requested LOA

A client requested LOA is computed from the renew parameter if this one is defined :

  • If renew is a numeric value, all authentication handlers whose LOA is superior or equals are selected
  • If renew is a LOA name, the associated numeric value is used to find the authentication handlers as previously
  • If renew is an authentication handler name, the authentication handler is selected.

2) Server requested LOA

A server requested LOA is computed from the requested registered service (service parameter).

...

If no service is defined, all authentication handlers are requested.

3) Computed requested LOA

The requested authentication handlers are the intersection between the ones computed for client and the ones computed for server.

...

The requested LOA is the lowest numeric value of all selected authentication handlers.

C) Current LOA

The current LOA is retrieved from the authentication using the assurance evaluator.

D) Compare requested LOA and current LOA

If the current LOA is equals or superior to requested LOA, a service ticket is generated and the user is redirected to the service with this service ticket or to the generic login successfull view is displayed (if no service is requested).

If the current LOA is strictly inferior to the requested LOA, an authentication process should be started.

E) Define the needed interactions

At this step, we have the requested authentication handlers and LOA.

...

If no interaction is returned, a CAS error page is displayed : "The CAS server cannot grant the level of assurance requested by service and/or by renew parameter".

F) Process interactions

At this step, we have a list of ordered interactions to use for authentication process.

...

  • If the principal is null, the user is redirected back to the view with an error message. If the principal is not null, the user is authenticated and we can generate a service ticket and redirect him to the service or display the generic login successfull view (if no requested service).
If no more interaction is available (no interaction was able to authenticate successfully a user), a CAS error page is displayed : "The CAS server cannot grant the level of assurance requested by service and/or by renew parameter".

G) Communication with Client

Ideas for a new CAS Protocol for Ticket Validation Response   -Nathan

...

  • 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
Jérôme :
Yes, it would be great to return user attributes.
Regarding LOA, I would return the current LOA of the user with numeric value and names, and I would add the authentication handler name used to authenticate the user.
But I thought we wanted to add these information to the SAML validation, not to the CAS one, to keep backward compatibility...

Nathan:
It would probably be fine to go that route (i.e. support the new LOA stuff only within SAML), but there was talk on the cas-dev mailing list about possibly coming out with a new revision of the CAS protocol (probably listening at a different URL), to add these types of things.

NEW Jérôme :
I agree, it would be great to improve CAS validation response, we have to try to get an agreement on that....

VI. Use cases

A) 2 webapps supporting remember-me and authentication by credentials / client requested LOA

- I access app1 and app2 as remember-me (round-trips on /login)
- I access a more secured area (requiring login/password authentication) in app2 -> I'm redirected to CAS server with renew=credentials, I need to re-authenticate, I fill my password and I'm redirected to app2 -> I get access as I'm now authenticated (not remembered)
- I access a more secured area (requiring login/password authentication) in app1 : what happens ? I'm still remembered in this one, so I'm redirected back to CAS server with renew=credentials and as I'm now authenticated in SSO session with the right LOA, I'm redirected back to application with a valid service ticket.

B) Other use cases

Note that some of these are various versions of the same story but using different scenarios.

...

Nathan:  I think this scenario is actually much easier if we allow composition of handlers instead of using a custom combined handler.  The service requests the "LDAP + SMS" multifactor-LOA.  The server realizes that "LDAP" authentication is already fulfilled, so it simply sends the user through the "SMS" interaction and authentication handler.  If the handlers were hard-coded together into a single handler and a single interaction, there would be no easy way for the server to send the user through only the second half of the interaction and run only the second half of the authentication handler with the second-half of the credentials.  However, if the two authentication handlers are kept separate but simply composed together in the configuration, it would be easy for the server to trigger only the SMS parts of the flow.

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.

...