I. Introduction

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

...

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

...

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.

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.
• SilentCredentialsGatherer means the CAS server will get by itself Credentials silently from the HTTP request.

D) Actions and Web Flow (updated)

D) Interaction manager (new)

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.

For backward compatibility, these parameter and value will remain but new values will be possible for the renew parameter to handle LOA :

• renew=value, the numeric value is strictly positive, it's meant to be a requested numeric LOA
• renew=name, name is the name of an authentication handler or the name of a level of assurance.  (I recommend allowing the client to specify either a minimum number or a list of names of the level of assurance and not an individual authentication handler.  If that level of flexibility is desired, then the client should be able to specify a complete authentication constraint expression and not just an authentication handler name. Noe that with a list of names, only exact matches count. Even if the user has fulfilled a higher number but not fulfilled the requested type of authentication specified by the named level, then it doesn't count. -Nathan)
  

V. Main algorithm

A) Diagram

Image Removed

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

The requested registered service gives the requested authentication handlers.

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.

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

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.

From these requested authentication handlers, the needed interactions can be computed using the interaction manager.

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.

Let's start with the first interaction if it exists.

If the interaction is a system one, credentials are returned by this interaction.

• If credentials are null, we move to the next interaction. If credentials are not null, the authentication manager is called with these credentials and the requested LOA. A principal is returned.
  • If the principal is null, we move to the next interaction. 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).

G) Communication with Client

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

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

• 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

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.

NOTE: The following were written by Nathan.

1. Guest -> Student -> Employee
   1. I first interact with CAS when registering for an event as a guest.
      1. For convenience I choose to use Facebook authentication.
   2. A few months later, I join the organization as a student.
      1. Through a process out of the scope of this document, I sign up for a username and password.  These credentials are connected to my existing identity, which up to this point only contained Facebook authentication information.
      2. If I attempt to access a resource intended for guests (app1), I see a login page that does include the Facebook button.
      3. If I attempt to access a resource intended for students (app2), I see a login page that does not include the Facebook authentication option.
      4. Let's say I login to app1 using Facebook, then I navigate to app2.
         
         1. I am presented with the login page again, this time not showing the Facebook button and including a message stating, "You must login with your username and password.  Facebook Connect is not supported for the site you are trying to reach."
         2. After I login, I am taken to the page.
   3. A few years later, I join the organization as an employee.
      1. Through a process out of the scope of this document, I am forced to increase the strength of my password to meet employee standards.  This is likely handled through a business process but also enforced using an interrupt screen in CAS that analyzes my password strength (probably by looking at authentication attributes, the assurance policy, and my organizational roles) and, if necessary, sends me to a self-service change password page after logging in.  The change password page will check my role (in my case by looking in Grouper) and will enforce the employee password policy.
      2. In this case, because password strength has been enforced prior to my accessing a service (through the use of interrupt screens and validation), the service can assume that my password is strong enough.
2. Remember me
   1. I'm a student.
   2. I read a blog on the organization's blog site and I want to leave a comment.  I log in and check the "remember me" box.
   3. When reading another blog a few days later, I am able to leave a comment without logging in again because the "remember me" feature worked for the blog.
   4. I access the event registration web app, and it presents me with the login page because it requires an LOA number higher than that of the "remember me" feature.
3. Trusted external IdP  - Note that this is very similar to using a public IdP like Facebook, and (like Facebook Connect) is basically a form of federation
   1. I'm an employee at a partner organization.
   2. I attempt to access the event registration web app.  On the login page, I click the link "login with username and password from partner organization."  (yes, the real message would be much less generic... more along the lines of "login with facebook" but for the partner org)
   3. I attempt to access an employee portal website, which does not accept employees from partner org.  I am shown the login screen again, with a message saying something like, "You must login with your username and password.  Partner Org login is not supported for the site you are trying to reach."
4. Add a second factor (selected by user) when accessing enterprise app
   1. I access the employee portal and login with my username and password.
   2. I navigate to the organization PeopleSoft HR system.
   3. The system looks up some info in my account and determines that I have my cell phone registered to receive SMS messages and I have Google Authenticator configured.  It presents me with a screen showing the two options and asking me to click one.  I click on the "SMS message" option.  (Note that if I had only previously set up one of these options, the system would have selected it automatically.  If I had not previously set up either option, the system would have given me instructions telling me to set up at least one of these.)
   4. My phone receives a code as an SMS message.  I type this code into a text box on the screen and click "continue".
   5. I am granted access to the PeopleSoft HR system.
5. Extra-strong password policy enforced for user with power-admin role - Note that this is an important LOA scenario, though it is somewhat outside of the scope of LOA in CAS as we're talking about now.  It really highlights how interrupt screens can play an important role in LOA.
1. I'm an employee with access to the PeopleSoft HR system.
2. I'm granted a special role in PeopleSoft that gives me lots of power.  This is registered in the organization's RBAC system (in this case Grouper).
3. The next time I login with my username and password, some code in CAS intercepts my login and realizes that my password is not strong enough for this role.  I get sent to a screen where I must choose a stronger password.
4. After choosing the stronger password, I login again and then am granted access to PeopleSoft.
5. Note that PeopleSoft itself might not specifically immediately request any special password strength (beyond what would be true for all users), since it doesn't know who is accessing it when it redirects the first time.  However, after it has received and validated the ticket, it might take the opportunity to look up the person's assigned roles to ensure that their current password strength or LOA level is sufficient.  In that case it could redirect the user back to CAS with a more specific LOA request.  Alternatively, it would probably block access and notify an administrator, because the interrupt screens should have already done the work to ensure that this aspect of the LOA policy was fulfilled.

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

InteractiveCredentialsGatherer

D) Interaction manager (new)

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

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

VI. Use cases

See Example LOA Use Cases