In CAS3 we have decided that Principal may contain not just a principal id but also whatever attributes the site decides to return. Here are some thoughts on how this should be modeled.

Current Model

In the current (2/3/05) version of the code the AuthenticationManager first calls AuthenticationHandler.authenticate(Credentials) which returns boolean and then invokes CredentialsToPrincipalResolver.resolvePrincipal(Credentials) to get the Principal. So CredentialsToPrincipalResolver is expected to re-use the Credentials. The most concrete issue with this model is that Credentials may be one-time-use so they cannot be used twice.

Alternate Model

Principal AuthenticationHandler.authenticate(Credentials)

It is the job of authenticate to return at least the principal identifier. We have had discussions about whether it returns a richer object including assertions in SAML form about the authentication itself (see AuthenticationResult in Authentication module). Regardless of how failure is handled, however, success needs to return a bare bones principal.

Principal PrincipalAttributeHandler.addAttributesToPrincipal(principal)

The names here not so great but the function is to pass a principal in and let the method add attributes and return the enhanced principal.

What's the flow?

We came up with scenarios where multiple authentication handlers would want to share an attribute handler and also ones where each authentication handler would acquire attributes in a defferent way. So the most flexible model is for the authenticate() method to invoke one or more attribute handlers before returning Principal.

Comments?

Browser not supported