idp.authn.flows and idp.authn.*.order bug?

[Simon Lundström]

Hey all,

While migrating our IDP to v5 I tried to keep as many features as
possible but yet migrate to the new config styles of v5 but SPNEGO (and
SPNEGO via RemoteUser) was one of the things I couldn't get to work
straight away. Now when the dust has cleared I've started to revisit.

I re-read all the AuthN docs and while it looked like I didn't have to
change anything from our old config one thing did stand out: order.

If I configure the IDP to try RemoteUser first and then Password via:

idp.authn.flows = RemoteUser|Password

it just never tries RemoteUser even on debug logging:

DEBUG [net.shibboleth.idp.authn.impl.PopulateAuthenticationContext:203] Profile Action PopulateAuthenticationContext: Installed 2 potential authentication flows into AuthenticationContext
DEBUG [net.shibboleth.idp.session.impl.PopulateSessionContext:140] Profile Action PopulateSessionContext: No session found for client
DEBUG [net.shibboleth.idp.authn.impl.InitializeRequestedPrincipalContext:146] Profile Action InitializeRequestedPrincipalContext: Profile configuration did not supply any default authentication methods
DEBUG [net.shibboleth.idp.authn.impl.FilterFlowsByForcedAuthn:54] Profile Action FilterFlowsByForcedAuthn: Request does not have forced authentication requirement, nothing to do
DEBUG [net.shibboleth.idp.authn.impl.FilterFlowsByNonBrowserSupport:54] Profile Action FilterFlowsByNonBrowserSupport: Request does not have non-browser requirement, nothing to do
DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:270] Profile Action SelectAuthenticationFlow: No specific Principals requested
DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:309] Profile Action SelectAuthenticationFlow: No usable active results available, selecting an inactive flow
DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:368] Profile Action SelectAuthenticationFlow: Selecting inactive authentication flow authn/Password

Looks like 2 flows are installed/available but why would it choose
Password when RemoteUser is first in the flows config?

Turns out I had misunderstood idp.authn.flows. It *never* controlled the
order it just controlled which were enabled and was gonna be tried. I
can't find the docs now but I remember that I read that the order that
the beans were defined was the order. I'm guessing
authn/general-authn.xml/authn-system.xml and/or webflow-config.xml.

The old order of the .xml-file made sense, well in my world, because
that's the order that you want to try authN:
* IPAddress
* SPNEGO
* External
* RemoteUser
* RemoteUserInternal
* Function
* X509
* X509Internal
* Password
* Duo
* MFA

The new order is.. Password always win? Since everything has the same
prio (1000) by default and Password being defined first now in
conf/authn-system.xml (if that's taken into account when the prio is the
same, I don't know I didn't find the actual code).

Now for the real questions:

This seems like a bad default? Can the order be restored into the old
order?

I didn't find anyone else talking about this on the mailinglist and I
guess it's because everyone is using the MFA flow to set the order so
no one else has hit this "bug"?

BR,
- Simon