jaas authentication failover

[Cantor, Scott]

On 3/29/19, 11:55 AM, "Liam Hoekenga" <liamr at umich.edu> wrote:

> That seemed to do the trick.  It also fixed an issue I was having when throwing the GEANT OIDC plugin into the mix.

I guess my confusion was that I thought you were doing that deliberately for a purpose.

> I still wonder, though, is there anything left over in some context that says "user authenticated with
> JAASGuestLoginConfigurations" vs "user authenticated with JAASKerberosLoginConfigurations"?

Not without doing what you just "undid".

Now that I understand what the intent is, I think the problem you're having is actually a design limitation.

The Password flow is meant to advertise support for (usually) the simple password context classes, and not fancier MFA context classes. The MFA flow is built so that it can run the Password flow regardless of what the SP asks for, as an "automatic" first step of doing the login. It doesn't care what the Password flow is configured to support.

But this JAAS strategy feature allows (actually requires) each JAAS configuration to be evaluated based on whether it supports the request's requirements or not.

If an SP requires an MFA context class, none of the JAAS configurations are going to "claim" support for that context class, so when the Password flow starts running, and looks at the JAAS configurations to run, if that second slot of the pairs returned by the function are carrying something, it's going to check that against the SP's request and say "no, doesn't support it", and then it skips it. When that field is empty, it doesn't check.

The problem is that the second field in the pair coming back is used for two things that are really independent:

- what the JAAS configuration should support to decide whether to try it
- what the resulting Subject should contain in its Principal collection for reporting out to the other parts of the IdP

You're asking about the second of those, but doing that will screw up the first one. They weren't supported as independent use cases. All of this stuff gets very hard because adding options to control the behavior ultimately keeps adding more and more complexity, so it's a vicious circle.

-- Scott