Versions Compared

Old Version 10

changes.mady.by.user Jérôme LELEU

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

...

...

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

...

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.

...

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

...

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