Versions Compared

Old Version 48

changes.mady.by.user Jérôme LELEU

Saved on

compared with

New Version 49

changes.mady.by.user Jérôme LELEU

Saved on

Key

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

...

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

NEW Jérôme :

I'm not tied to my basic solution either. Above all, I want to stick to the most simple solution. I admit that expressions allow composition, which is better than re-coding authentication handlers, credentials...

...

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

...

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.

NEW Jérôme :
Just to be sure : you want to keep the ability to request a specific authentication method (and not a level of authentication), correct ?

...

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

NEW Jérôme :
I agree, it would be great to improve CAS validation response, we have to try to get an agreement on that....

...

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

...