3.3 SNAPSHOT: AuthN resolveAttribute not activating authn flow

[Cantor, Scott]

> If what the above is saying is that one will not be able to use the value of the
> "eduPersonAssurance/assurance/whatever name one used for that
> attribute" to force another factor (e.g. Duo) to be used (and current SSO
> session to NOT be sufficient), then you will greatly slow down adoption of
> 3.3. Any number of institutions drive the signaling of Duo/another factor thru
> logic in the resolver to calculate a value for that attribute.

No, that's not what I'm saying. I *am* saying that the right way to do that sort of thing is to populate the RequestedPrincipalContext appropriately, because that's what drives all that code in a way that's not fragile and that I can avoid breaking. I may have to undo or modify the change I made but that will re-break IsPassive, so I cant just undo it completely, I have to review it again.

3.3 allows the defaultAuthenticationMethods setting to be derived from a function at runtime. If the function knows the user identity, then it's very simple to resolve an attribute in Java or a script and use it to populate the setting. That's the appropriate mechanism to replace the to-be-deprecated ones. If you need to force Duo, just populate the context with a value that Duo satisfies and Password alone doesn't, and that can depend on anything you want.

The problem I see right now is that the step to pull out the defaultAuthenticationMethods property is coming too early right now, but I should be able to adjust that easily before we freeze. It's sitting right outside the authentication subflow call today, so moving it inside should be straightforward for SAML and CAS. It just needs to run after the session is loaded for the user, and then if SSO is in play, you'll get the chance to intervene in the apropriate way.

-- Scott