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
- Key areas of interest:
- E-Authenticaiton 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
- Key areas of interest
- Incommon Assurance Policies Bronze and Silver
- Key areas of interest
- Section 4.1: Summary of Identity Assurance Criteria
- Key areas of interest
- Authentication Contexts for SAML 2.0
- Key areas of interest
- Section 3.4: Authentication Context Classes list
- Key areas of interest
II. Authentication API in CAS server
NOTE by Nathan: I've written a new LOA spec document that is based on the discussion found in this document: Second Level Of Assurance Specification
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 assurance policy. It consists of many levels of assurance (at least two).
...
The assurance policy is basically a map from a set of authentication attribute constraints, defined in an expression, to descriptive names and numbers.
Example Assurance Policy
Authentication handlers defined for this example:
...
* I just noticed that with this design (and if reusing the "renew" parameter to specify the names of accepted levels), then adding a level named "true" might actually provide backwards compatibility automatically without needing any special code. Haha! 
I'm not sure if I'd actually recommend this practice, but it is kind of interesting. -Nathan
Authentication Constraint Expressions
An authentication constraint expression describes a combination of authentication handlers and authentication attributes derived from those handlers that are required to achieve the given level of authentication. Acceptable authentication handlers can be combined using logical and and or and grouped using parentheses. Authentication attribute constraints can be defined for each authentication handler. (In this example, they are defined within braces following the authentication handler.)
...
NOTE: As I'm working on my use cases, I'm discovering that the attributes aspect of authentication handlers (other than the pseudo-attributes of "initial" and "timestamp") might be better handled proactively. In other words, a service that would require a stronger password will probably already be using role-based authorization to allow/deny access. If there is an interrupt screen in CAS that enforces the stronger password policy based on this role membership (e.g. by looking at Grouper or LDAP group membership), then can be assured that the user has the stronger password if they get past the interrupt screen code. In that case, we probably don't need to handle attributes at the constraint expression level. This would reduce the complexity of the assurance evaluator. On the other hand, it still might be useful to compute a stronger LOA number (or name) based on attributes such as password strength. Especially when federating with someone who wants NIST-like levels, it might be nice to be able to pass that extra info along. -Nathan
Authentication Attributes (update)
Authentication attributes come in two flavors: credential attributes and event attributes. For the most part, these are stored in the Authentication object and placed there by the authentication handler. However, some of these attributes used in constraint expressions (such as the "initial" attribute in the above examples) will likely be computed on the fly or pulled from other objects.
...
I have one question though : how do you evaluate the "initial" attribute ? Isn't it an information you only get after authenticating the user in the authentication handler ?
B) Level of assurance (new)
A level of assurance has :
...
NEW Nathan:
True. I see three flavors of attributes. First, you have attributes that would always be true about the user and could be looked up using only partial knowledge of the user (such as by their username). These include things like password policy enforced and a checklist of procedures followed during signup. Other attributes are only known once authentication has been complete, such as the timestamp and whether or not SSL was employed. These attributes would stick around as metadata associated with the "Authentication" object. (See the AuthenticationMetaDataPopulator interface in the current CAS implementation.) Finally, some attributes, such as the "initial" attribute, would need to be handled as a special case. That's because for a given Authentication, this attribute has the value of "true" at first, but then has the value of "false" for every time after that. Note that I'm not convinced that it would be best to re-implement "renew" as a feature of LOA in this way. Doing this gives a lot of flexibility, but it might be sufficient to think of it as a separate concern.
NEW 2 Jérôme :
I read carefully your spec. It's an excellent work, I think we're close to a solution we both agree on.
My remarks on you spec and more globally. I agree :
- on LOA defintion based on authentication handlers ordrerd list
- with requested "loa" parameter syntax : numeric value means a LOA and superior, name value requests specific LOA
- that authentication handlers should be linked to user interactions (instead of credentials which are not known from LOA)
- on using precedence for interactions when having same level of assurance.
But,
- the user interactions part is not totally clear to me : do you want to have one screen with multiple user interactions or several screens with just one user interaction ? I think also that each interaction should be attached to credentials for further authentication
- I still belive we can get rid of parameters just by using supports() method on authentication handler : I would say that the supports() method could have more input than just the credentials, but also Authentication, HttpServletRequest... Don't you think ?
NEW 2 Nathan:
- I was imagining that each interaction has a particular "starting screen", which could lead to subsequent screens based on Spring Web Flow and controllers that are triggered from the first screen.
- If two authentication handlers are required for the requested LOA, then CAS would show the interaction for each handler in sequence. In this case the user would see two screens, one for the first authentication handler and one for the second. This allows easy mix-and-match of authentication handlers.
- The thought is this:
- Authentication Handler is requested
- Interaction is selected as defined by the authentication handler
- First screen of interaction is displayed as defined by the interactionSpring Web Flow and controllers might show additional screens
- If alternate Interactions (for alternate Authentication Handlers) are available, list links to the alternates on the screen.
- Spring Web Flow and controllers might show additional screens
- The interaction results in Credentials
- The Credentials are handled by the Authentication Handler, producing an Authentication
- Repeat these steps for any other authentication handlers required for this LOA
- One thing I'm trying to avoid is having to define multiple copies of an authentication handler in order to support things like multiple password policies. We probably could make that work successfully, but it feels like more work than necessary for deployers.
- It might be OK to start this way (no parameters but with multiple auth handlers to support multiple password policies) and then sometime in the future re-evaluate options that would make it easier to define LOAs based on password policy strength. I'll look through our use cases again to determine whether this will work well for us in the short-to-medium time-frame.
B) Level of assurance (new)
A level of assurance has :
- many names (at least one)
- a level (positive numeric value). 0 means not authenticated. The higher the value is, the more secure the level is.
- a constraint expression. see above. -Nathan
By default, the assurance policy is defined with the following levels of assurance :
| Level | Names | Examples |
|---|---|---|
| 50 | double_credentials | Login/password + SMS code |
| 40 | credentials | Login/password with local authentication handler |
| 30 | external_credentials | OAuth (Twitter, Facebook...) authentication |
| 20 | system | IP based authentication |
| 10 | cookie | Remember-me |
| 0 | anonymous | The user is not authenticated |
C) Authentication handler (update)
So far, an authentication handler authenticates credentials and is defined to support a kind of credentials.
...
D) Interaction (new)
An interaction is a way to get credentials. Each interaction is defined to support a kind of credentials it will return when called.
...
- annual acceptable use policy
- need to increase password strength
- need to register (or confirm) contact information such as cell #
- need to select security Q&A
- need to register device/browser (you've probably seen facebook do this, for example)
I think it would greatly benefit CAS to have a generalized solution for interrupt screens, and I think it could be done without much complexity by simply generalizing the concepts found in LPPE.
NEW Jérôme :
I agree. I propose to keep this spec focused on LOA (steps 1, 2 and 3 in roadmap) and start a new spec after for other steps (4 ,5 and 6).).
NEW Nathan:
Sounds reasonable. I wanted to emphasize the ways that interrupt screens will likely play an important role in specific implementations of LOA concepts. Read these scenarios for more examples: Example LOA Use Cases
E) Interaction manager (new)
- many interactions (at least one).
F) Authentication manager (update)
One issue that we'll need to deal with is authenticator handlers that represent the same numeric "strength" of authentication. For example, for our second factor we might let users choose either Google Authenticator (if they have a smartphone) or SMS code (if they have an older phone or one that doesn't support the app). We might want to have the ability to say that these two authentication mechanisms afford the same level of authentication (if that is how we decide to define them), such that the system would allow the user to select the one most appropriate for their circumstance (or ideally we could automatically select the right method if we knew that they were only set up for one of the two).
G) Registered service (update)
H) Assurance evaluator (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.
...
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).
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
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.
...
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.
...