Versions Compared

Old Version 42

changes.mady.by.user Nathan Kopp

Saved on

compared with

New Version 43

changes.mady.by.user Nathan Kopp

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 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 composing compose existing authentication methods (including  together without writing code (and with automatically also composing all necessary related components ) together without writing codelike credentials and user interactions).

B) Level of assurance (new)

...

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). I think we need It would be nice to have 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 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)
, etc.  I

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

could be done without much complexity by simply generalizing the concepts found in LPPE.

E) Interaction manager (new)

...

I'd like you to describe more the HTTP requests and the LOA values requested.
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 ?
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 authenticationNathan:  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

...