...
- 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.
VI. Use cases
A) 2 webapps supporting remember-me and authentication by credentials / client requested LOA
...