Thoughts about authentication method / workflow mapping

[Cantor, Scott]

On Jul 17, 2013, at 5:58 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:

>> 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.
> 
> For example, by the former "information" do you mean annotations and
> the latter ... attributes ?

No, I mean an explicit API on the workflow descriptor class that returns a set of Principal objects describing what it can generate when it actually produces a Subject as a result of a login. I checked in a draft.

We agreed in principle to express the result of logins as a Java Subject and use that as the extensibility API for advanced authentication data instead of inventing something new. I'm suggesting carrying that through to the point of using custom Principal classes for expressing the SAML AuthnContext class associated with a login.

Today we equate the authenticationMethod property that identifies a login handler directly as the SAML string that goes in the assertion, but that's been very limiting. The design in the v3 code had been carrying that limitation forward, matching the workflow ID with the SAML string, and I want to break that equivalency.

I'm also interested in that because other protocols have different ways of talking about authentication "type" and expressing it in a response. I think it's more appropriate, though more complex, to carry that protocol notion of "type" in an extension via the Subject/Principal API.

-- Scott