Thoughts about authentication method / workflow mapping

[Cantor, Scott]

FYI, I'm working now to figure out a workable model now for how the overall flow will work as far as requesting specific methods in SAML, supporting SSO to bypass login, etc. so I can document that and start adjusting code.

> I wonder if you could explain or cite some references for the need to
> support multiple active authentication workflows in a single
> authentication context. I imagine that design is attempting to solve
> some of the problems you're referring to, but I can't imagine what
> they are off the top of my head.

Since the terms here get crazy (we probably should not have used Context ourselves), what do you mean by authentication context there?

If you're speaking abstractly, V2 already allows a user's session to contain multiple "active" AuthenticationMethod objects that represent what I'd call an AuthenticationEvent now. But I think you know that, so I think you mean something else.

I should note that right now the SubjectContext is carrying a multimap of workflow IDs to events but I haven't settled that yet. My concern with a map is that it means a given workflow can only be part of a session once, but I'm not sure my concern with that is warranted.

> I see some mixing of vocabulary that you might want to consider:
> 
> @Nonnull private Subject supportedPrincipals;
> 
> That seems to equate subject and principal, where in terms of the
> java.security APIs it's a parent/child relationship; a subject has one
> or more principals bound to it. It's fine if you want to put a stake
> in the ground and call them equivalent in the context of IdP APIs but
> it may cause some friction.

No, that's strictly internal. If you look, Subject doesn't appear on the API at all, I just used it to shortcut having to implement my own class-indexed Principal collection. Which itself is easy to replace, I just did it to save time. But the API is currently in terms of Principal, strictly. May just need a comment explaining that.

-- Scott