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