Versions Compared

Key

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

...

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 ?

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.

B) Level of assurance (new)

...

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

...

But, how do you do that with authentication constraint ? What do you imagine as a syntax ?

NEW Nathan:
Take a look at bottom this document for a description: Example LOA Use Cases
Note that I've simplified the concept of the "constraint expression" so that it basically is simply an ordered list of authentication handlers (with attributes) that all need to be fulfilled.  I've eliminated "OR" and grouping, since these can be handled in other ways.

V. Main algorithm

A) Diagram

...