Advice on migrating SPNEGO to MFA-flow

[Cantor, Scott]

> For normal authentication requests (no special requirements from SP or
> custom relying-party config) we want to authenticate our users by:
>   - their previous session if available and still active for achieving SSO
>   - SPNEGO authentication if the client resides in a subnet so it can
> request a Kerberos ST. Therefore we set an activationCondition based on
> several subnets on the authn/SPNEGO flow. Since not every user-agent is
> automatically able to use SPNEGO we rely on the cookie to "opt-in" and
> to actually run SPNEGO. (from a user's perspective this provides SSO as
> well)

And so the initial choice is always "password" unless the user opts-in, correct?

>   - password authentication if none of the above succeeded
> 
> Our IAM-system allows users to register a 2nd factor. Users can also
> indicate whether they want to use this 2nd factor for every login or
> only when the application requests for it. The former sets the attribute
> eduPersonAssurance to a certain value, for the latter eduPersonAssurance
> is empty.

And the second factor doesn't stand alone, so it has to be combined with...either password or SPNEGO? Just password?

> If a SP requests for the authnContextClass
> 'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport', but
> the user already authenticated using its first and 2nd factor, he must
> not re-authenticate because he already authenticated using a higher
> level of trust.

That works if your earlier method was password or password plus something else, but if you did SPNEGO, that technically isn't PasswordProtectedTransport. Once you start playing games like that, the IdP is going to deliberately make your life painful because it's not designed to lie. And once you manipulate the configuration to lie, that makes other lies automatic.

Of course, this is why using contexts that refer to specific technologies is a problem, and why requesting weaker methods is a bad idea.

But, if you want to configure SPNEGO as a flow to support that Principal type, it shouldn't do too much damage. Not every "lie" is the same and some won't cause as many weird side effects.

> If a SP requests for the authnContextClass
> 'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport' &
> forceAuthn is set, the user must be re-authenticated using his password.

ForceAuthn is implemented somewhat universally as "don't reuse a result" and beyond that just impacts which flows can be tried based on whether they support that feature. As long as SPNEGO doesn't, I guess that won't cause problems but you'd have to do a lot of testing to really see what it will do.

> I was not using the ExtendedFlows feature of the Password flow to run
> SPNEGO as a subflow. I now configured SPNEGO as an extended flow for
> Password.

I didn't recall whether that went hand in hand with that SWITCH built, it may have. I will grant that the extended flows stuff is awful, but that's because it was built as a stopgap until the MFA design was done. It's not as bad as that initial-authn disaster, but it's not great.

I suspect that you can implement whatever logic you're using the extended flow hook to do in the MFA flow, and if you can, that would probably be better. The MFA flow can do things with cookies just as easily as anything else can. Limiting the different types of mechanics used is better than trying to combine a lot of features and make it all work together.

The big advantage is all the logic around principal types. With the MFA flow, it's all much cleaner: you tell the system exactly which principals each flow supports, by themselves, and then the MFA flow can easily coordinate which ones to run for different situations.

With the extended flows thing, I think you have to hack in a lot of extra weirdness and lie about which principals are supported to get things to work. It's just not good.

> In order to use SPNEGO as an extended flow of the Password flow, it had
> to enabled it in the idp.authn.flows property, otherwise the extflows
> won't be enabled. Password on the other hand, must not be enabled via
> this property, it can be called directly from the MFA-flow as a subflow,
> I find this quite confusing.

Aside from all the non-MFA worarounds being hard to use in their own right, that's also confusing because you're mixing them, as I say, that's a mess. In fact, I think it likely won't even work right. I'd pick one.

The extended flows thing is really about enabling multiple flows, so they're all "activated". The MFA flow is about hiding multiple flows underneath a new one, and part of the win there was being able to avoid the need to activate them all from the point of view of the IdP, which prevents the IdP from running them accidentally.

> I also re-ordered the methods in general-authn.xml:
> 1: authn/Password
> 2: authn/multifactor
> 3: authn/MFA
> 4: authn/SPNEGO
> 
> When I now use Password authentication as my first factor, all works as
> expected.

Well, maybe, but I suspect you wouldn't be asking about this again if it did, so I'm afraid you're probably still looking at a dead end. But it's your system, I guess if it provides the right results, ok.

> If I then go to a SP which requests the authnContextClass linked to my 2nd factor
> authn, I want to reuse the authentication result from SPNEGO. With my
> currect MFA-transitionmap he goes to authn/Password:

The MFA flow will reuse results for you automatically, but when you have two potential starting points (Password and SPNEGO), you really need to script that yourself. You want either one to be the first factor, so you have to script that I think and have it check for active results from either one of those methods, and assuming that's there, skip them and go right to the second factor or whatever other logic is there.

> I guess I should use a nextFlowStrategy as the initial step in the
> TransitionMap to determine I can reuse the active result, if not go to
> authn/Password. If so, check if authnContextClass for 2nd factor is
> requested or set in the eduPersonAssurance-attribute (opt-in) and then
> go to authn/multifactor.

I think so. The first transition rule, instead of directing it to run a specific flow, should run a script or bean to return the next step. Each rule can always do that. Specifying a flow directly is just a short-cut when you don't need to implement any logic and know which flow should run.

I think I cover all the ways you can implement transitions in the wiki from simple to complex, with an example of each type.

> I have to figure out how to do this in using your API. Any pointers
> would be appreciated since I am not that familiar with the API.

You're going to have to be more specific about what you need a pointer to in the API. The wiki should cover how to do the different transition approaches, but I assume you mean something more about what you have to access or test for in the rule.
 
> It's better to explicitly deprecate those properties at
> https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationConfiguration
> in favour of the MFA-flow.

If they were officially "I know for certain they're being removed" deprecated, I would have. We're not at that point. I did include warnings.

> Since I now use SPNEGO as an ExtendedFlow of the Password flow this
> question has become irrelevant.

I think you will eventually find that it is relevant again, because I doubt using the ExtendedFlow feature with the MFA feature at the same time will hold up. It might work in your special case, but probably not for most people.

> But anyway before I did the transition to SPNEGO as an ExtendedFlow of
> Password, I tried adding an entry in the TransitionMap for ReselectFlow,
> but control was given back to SelectAuthenticationFlow, log:

I'll have to check that out.

> In my authn/multifactor lib, I use the CanonicalUsernameLookupStrategy
> to retrieve the username. But I understand that I must not use it for
> determining the authentication flow.

Getting the username out is fine, that's all it's there for.

-- Scott