...
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.
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.
An authentication handler will be added :
- a name
- a supported level of assurance (strictly positive numeric value).
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.
E) Interaction manager (new)
- many interactions (at least one).
F) Authentication manager (update)
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.
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)
...
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 thought 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 composing existing authentication methods (including all necessary components) together without writing code.
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.
An authentication handler will be added :
- a name
- a supported level of assurance (strictly positive numeric value).
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.
LPPE is great, but 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). I think we need a pluggable concept (Java interface + Spring extension point) that works for any authentication handler and in any place where you want to interrupt the user after login for any reason. Yes, we should reuse the concepts of LPPE, but it needs to be generalized, 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), etc. I think it would greatly benefit CAS to have a generalized solution for interrupt screens, and I don't think it would add much complexity to CAS configuration.
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.
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)
In the use cases that I need to support, our policies might not end up being defined my a straight numeric scale where the concepts of "better" and "worse" are agreed-upon across 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. I need to be able to support exceptions to the rule.
...