Thoughts about authentication method / workflow mapping

[Cantor, Scott]

Working on the class that models authentication "workflows" which maps more or less to the V2 concept of a login handler, and thinking about all the problems we've had with the disconnect between the "method" supported by a handler (now notionally called the workflow ID) and the idea of a SAML authentication context.

I don't think the design as it stood really was addressing this disconnect any better than V2 did, and I think we ought to break this connection.

The idea that came to me was to leverage the use of the Subject/Principal API which we already decided to use to model extended information about authentication results. So I thought it might make sense to attach the SAML authentication context decl, decl ref, or class ref as an extended java.security.Principal type (one type for each kind of SAML thing, so it would be explicit).

Then I thought we could expose information on the AuthenticationWorkflowDescriptor class API about what java.security.Principal information a workflow can produce, to support figuring out what workflows can be used.

The advantage I see to this is that it's adaptable to other protocols without baking in assumptions or putting any SAML-specific ideas on the APIs other than through the extensibility of Principals that we're already having to handle. I particularly didn't like the idea of subclassing AuthenticationWorkflowDescriptor to be SAML-aware, nor do I think the workflow IDs should directly have to match any SAML constructs.

-- Scott