Unexpected behaviours with matchExpression and SPNEGO and RemoteUser

[Cantor, Scott]

> I think this might be a default configuration bug actually.

It's not a bug because it's explicitly wired into the flow. Whether it should have been done that way might be a bug, but the thought process was that the SPNEGO flow should "fall back" to another login flow when that error occurs.

> In conf/authn/spnego-authn-config.xml in the
> shibboleth.authn.SPNEGO.ClassifiedMessageMap there is no
> InvalidCredentials or INVALID_CREDENTIALS which makes it just "fall
> back" to the ReselectFlow, as noted in the comment in
> system/flows/authn/spnego-authn-flow.xml which makes it reselect twice,
> hence the two fold incrementation of execution(?).

No, ReselectFlow should be selecting a different flow, not SPNEGO. If it's selecting SPNEGO, that would be a bug. It's possible there's a glitch with how it's being run in the first place or what state it's leaving things in.

> When I added an InvalidPassword entry with InvalidCredentials as a value
> it shows the same as the authn/Password which is what I expected.

I don't follow that, I would have to see what you're talking about. An error like that should basically fail the whole login process. I don't know what "Same as authn/Password" means here since there's no form to display.
 
> Is there a way to add the transition to the flow without editing a
> system file?

No, but you don't need to. You can get InvalidCredentials as a message to signal ReselectFlow as an outcome, if you want. That's what the message maps do.

> Well, it seems like they can be tamed to have an UI.

I don't follow that part, but one thing I did realize is that if the External flow involves some sort of system that itself has a UI, I could see the logic for having the username checking logic fail result in passing control *back* to the external system. I didn't see that originally, but I could see wanting to do that. It's not really possible at the moment.

-- Scott