Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 43 Next »

I. Introduction

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

The LOA is the confidence the CAS server has in the given credentials to say who the principal is.

There are a number of different factors that affect LOA:

  • Registration and Identity Proofing
  • Assurance level of the authentication token
  • Security of the authentication mechanism (channel encryption, etc.)
  • Other details of the authentication (e.g. how stale is it?)
  • Other policies in place (such as revocation policy)

Related documentation:

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 manager has :

  • many authentication handlers, each supporting a kind of credentials and returning a principal
  • many credentials to principal resolvers, each supporting a kind of credentials
  • potentially many authentication meta data populators which add attributes to the authentication.

A credentials to principal resolver can retrieve user attributes from a specific repository and populates them in the authentication.

An authentication has :

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

Nathan's Recommendation:

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:

NameAuthentication Attributes
ldaptimestamp (datetime), initial (boolean), password_strength (number 0..10), registration_process_id (string)
sms_codetimestamp (datetime), initial (boolean), phone_registration_process_id (string)
google_authenticatortimestamp (datetime), initial (boolean)
facebooktimestamp (datetime)
twittertimestamp (datetime)
openidtimestamp (datetime), provider_url (string)
remember_me_cookietimestamp (datetime), original_authentication_timestamp (datetime)

The policy looks like this:

NameLevelAuthentication Constraints
strong_two_factor50ldap {password_strength>=8} && (sms_code || google_authenticator)
strong_ldap_renew47ldap {password_strength>=8 && initial==true}
strong_ldap45ldap {password_strength>=8}
any_ldap_renew42ldap {initial==true}
true*42ldap {initial==true}
any_ldap40ldap
public_idp30facebook || twitter || openid
remember_me20remember_me_cookie

* 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!  (wink)  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 that authentication constraint expressions need to be run both forwards and backwards.  The server needs to be able to determine the levels and names that are applicable to the user's current set of authentication objects (i.e. "determine the current LOA").  The server also needs to be able to determine which authentication handlers should be satisfied, and therefore which interactions (see below) should be invoked, in order to raise the user's LOA to the desired level if it is not there yet.  Note that the server needs to be smart enough to know that it cannot upgrade someone from "ldap{password_strength==5}" to "ldap{password_strength==8}" just by sending them back through the "ldap" authentication handler and corresponding interaction.

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.

Credential attributes describe the credentials for a particular principal, such as (but not limited to) the key strength used for a certificate, the password strength for an individual user, any identity verification that was used for issuance, and revocation policies.  Credential attributes for a user can, in theory, be determined about a user even before that user attempts to authenticate with a given authentication handler.

Event attributes describe a particular authentication event, indicating details such as the authentication handler used, the timestamp of the authentication, the encryption level of the communication channel, and whether this was an initial authentication or part of a session (i.e. related to CAS's "renew" functionality).

Jérôme :

I understand your mechanism but do we really need to have "such complexity" to address all use cases ? Do we really need to have OR and AND logical links between authentication handlers ?

For multiple authentication handlers of the same kind (LDAP for example) with different password strengths, I had a very simple solution : define a type (string value) for each authentication handler and change the authentication manager to try only one authentication handler with the same type (just to try once the "LDAP" authentication handler for example).

If you need SMS + username/password authentication, I would create a SmsUsernamePasswordCredentials, a SmsUsernamePasswordAuthenticationHandler and a SmsUsernamePasswordUserInteraction : it may seem somehow redundant, but I think it's easy to code and understand.

I'd like to get Marvin's opinion on these solutions to know if and how much we are compliant with authentication API refactoring in CAS 4.0.

Nathan:
From reading this suggestion (e.g. SmsUsernamePasswordAuthenticaitonHandler), as a deployer I would think that it actually adds significant complexity (for deployers), since deployers would need to create a custom set of classes (credential, handler, and interaction) for every multi-factor combination.  Certainly, there may be ways to simplify the "expression" concept (see more comments below), but the general concept is this:  deployers should be able to mix and match authentication handlers out of the box without needing to write any new code.  I think that LOA should introduce a concept that allows the composition of authenticator handlers without the need to write code.  Another method of implementing this (instead of using expressions) would be to implement some generic "composition" handler classes that can be used to combine other handlers into a single one without writing code.  However, I think it would be easier for the deployer to work with expressions, since otherwise you'd have to deal with composing the Credentials, AuthenticationHandler, and UserInteraction all separately, whereas the expression would allow you to do the composition all in one spot.

Here's another perspective that can maybe help to get us on the same page:  You can think of my suggestion of "constraint expressions" as a way to dynamically define a new AuthenticationHandler (along with the corresponding Credentials and UserInteraction), composed of other pre-existing handlers, without needing to write code.  Then, each AuthenticationHandler (whether Java-based or expression-based) is given a name and a number.  And, again, I'm not tied to the concept of an expression... I'm more tied to the concept of deployers being able to easily compose existing authentication methods together without writing code (and with automatically also composing all necessary related components like credentials and user interactions).

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 :

LevelNamesExamples
50double_credentialsLogin/password + SMS code
40credentialsLogin/password with local authentication handler
30external_credentialsOAuth (Twitter, Facebook...) authentication
20systemIP based authentication
10cookieRemember-me
0anonymousThe user is not authenticated

C) Authentication handler (update)

So far, an authentication handler authenticates credentials and is defined to support a kind of credentials.

An authentication handler will be added :

  • a name
  • a supported level of assurance (strictly positive numeric value).
I think instead an authentication handler should simply populate its authentication object with appropriate authentication attributes, and the assurance policy should be responsible for mapping authentication handlers (or combinations thereof) to assurance levels. -Nathan

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.

There are two types of interactions :

  • user interaction means the user has to give inputs as credentials. A user interaction is also defined with a view to display to get user inputs. At least, one user interaction is defined in CAS server : the login page interaction which supports username password credentials.
  • system interaction means the CAS server will get by itself credentials from the coming HTTP request.
It might be nice if the concept of a pluggable interaction could be generalized to support other areas of CAS, such as interrupt screens.  For us, interrupt screens will play an important role in our overall LOA strategy (see use-cases below).  I wonder if Spring Web Flow or Spring MVC already might have something to facilitate this feature.  -Nathan

Jérôme :
We already have the LPPE feature which addresses this issue (only for LDAP though) : an exception is thrown by authentication handler for password renewal and a screen to renew password is displayed. I think we should try to stick to this existing feature.

Nathan:
LPPE is great, but it alone not sufficient.  LPPE is a very specialized solution, and I'm talking about a generalized solution.  As you mention, LPPE only works for LDAP (and for password policies). It would be nice to have a pluggable concept (Java interface + Spring extension point) that works for any authentication handler.  Yes, we should build upon the concepts of LPPE (such as the ability to handle various return values that come out of the authentication handler action), but I think it needs to be generalized a little bit more, since LDAP Password Policies are only one of many possible reasons you might wish to interrupt the login process.  Other reasons (some of which have been mentioned in the CAS mailing lists):
  • 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.

E) Interaction manager (new)

An interaction manager is defined with :
  • many interactions (at least one).
An interaction manager is in charge of finding the right interactions to try for a given list of authentication handlers. The interactions are returned as a list to specify in which order interactions are to be tried.

F) Authentication manager (update)

So far, an authentication manager takes credentials as input.
To support LOA, it will now take a numeric level of assurance as input also.
I prefer to think of the "name" of the assurance level as it's primary key, and to think of the numeric value as an attribute.  Therefore, I think the authentication manager should receive the name instead of the number. -Nathan
Jérôme :
I prefer using numeric value because this way, you can have an authentication handler with a LOA value (for example : 49) which is not equals to an already existing LOA.

Nathan:
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)

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.

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)
Jérôme :
I'm not sure if we should keep the availability to request LOA by authentication handler name of by constraint expression. Does it match real use case ? Does it make sense ? I think we should always request a LOA by name or numeric value, meaning a specific level and ALSO the "superior" levels.
I think I'd prefer if we created a new parameter named "loa" or something like that, instead of reusing "renew".  We would still want to preserve the behavior of "renew=true", but I think that we don't gain much by piggy-backing on the existing parameter.  I don't think it really "costs" us much to add a new "loa" parameter and it makes the protocol more understandable.
Jérôme :
I agree. We can use a parameter named "loa" instead of "renew" to avoid confusion.

Note that behavior is slightly different whether the client requests LOA by name or by number.  Here's an example.  Refer back to the table above under the "Example Assurance Policy" section.   Let's say that a user has satisfied the requirements for level 47 (renewed LDAP authentication with strong password).  In this case, the user's numeric LOA value would be 47, and they would have satisfied the following named levels: strong_ldap_renew, strong_ldap, any_ldap_renew, and any_ldap.  If a service requests "loa=30" (meaning any numeric value >=30), then the user would be allowed to access the service.  But if a service requests "loa=public_idp" (level requested by name), then the user would be prevented from accessing the service, even though their numeric value is higher.
Jérôme :
Using a name or a numeric value of LOA must lead to the same result. The only diffrence between name and numeric value is that a name should match a defined name whereas a numeric value doesn't need to match a numeric LOA because it only relies on numeric comparison (and not on exact matching).

Nathan:
In the use cases that I need to support, our central IT policies and concepts of "better" and "worse" most likely won't be agreed-upon by the entire organization.  This means that in some cases, an app (or a set of apps run by a particular department) might reject an authentication method (considering it weaker) that the rest of the organization has deemed acceptable and considers stronger.  Certainly it would be GREAT if we could just force agreement, but that just isn't the case where I work.  Our central IT department doesn't have that authority.  It would be very helpful to be able to support exceptions to the rule.
Another way to think of it is this:  This concept extends beyond pure "levels" of authentication (where one is always better than another) to "types" of authentication (where each type has pros and cons that make it better or worse under varying circumstances).  One example would be related to PCI compliance.  As an organization, we might say that the two-factor combination of a simple password plus Google Authenticator is stronger than a complex password.  But PCI rules might say that all users need a strong password regardless of whether or not they have Google authenticator.  Thus, the systems that need to be PCI compliant would need to be configured to handle an exception to the rule and reject something that the rest of the organization thinks is strong.

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

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).
If the interaction is a user one, the associated view is display to let the user fill its credentials. After the user has filled its credentials, these are submitted to the authentication manager with the requested LOA. A principal is returned.
  • 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

Possible CAS Protocol 4.0 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>
Added sections:
  • 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.

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.
Jérôme :
I'd like you to describe more the HTTP requests and the LOA values requested.
Nathan:  I didn't include the HTTP requests because in my use cases, the LOA requirements for each service will usually be defined in the service registry instead of being via HTTP.  (This is similar to how you can register a user to force renew using the service registry.)  However, I can certainly add this information.  I'll make a new page and write up some scenarios.
I may be mistaken, but I don't see anything here which cannot be addressed by what I proposed at first. I don't see the need for authentication handlers combination (&&, ||).
Did I miss something ?
Nathan:  As I mentioned above, the expressions allow deployers to easily compose out-of-the-box authentication handlers (and related components) into flexible multi-factor handlers with very little effort.
I'm only doubtful on how to handle properly the fact a user is already authenticated by username/password and needs to authenticate by SMS in addition to the previous authentication.
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) Version 1.0 : only client requested LOA

For a first version, 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) Version 2.0 : add server requested LOA

For a second version, 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) Version 3.0 : add interactions

For a third version, we can finally add the interactions and interactions manager and update the main algorithm (impacts on webflow).

Jérôme :

D) Version 4.0 : 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.

E) Version 5.0 : 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.


  • No labels