Unexpected behaviours with matchExpression and SPNEGO and RemoteUser

Cantor, Scott cantor.2 at osu.edu
Thu May 18 10:00:34 EDT 2017


> > I don't follow that, I would have to see what you're talking about.
> 
> In conf/authn/spnego-authn-config.xml to
> shibboleth.authn.SPNEGO.ClassifiedMessageMap I added:
> <entry key="InvalidPassword">
>     <list>
>         <value>InvalidCredentials</value>
>         <value>INVALID_CREDENTIALS</value>
>     </list>
> </entry>

And I'm saying that should fail the whole login, not "fall" into anything else. If not, you're messing with other features that confuse the discussion, such as running flows off of the Password flow, or that kind of thing. That breaks assumptions about "correct behavior" and does a lot of very odd things that don't hold true for the system in general.

> We have a SPNEGO button on our Password login page. If SPNEGO fails it
> just returns to Password but shows the error message.

Yeah, you're mixing up issues here. That changes how things work and interact, and you were asking about other "top level" flows and how that interacts with the IdP when errors occur, or at least I thought you were.

In general, what you're doing with the button is about one step short of deprecation. I'm not there just yet, but I am considering it. The MFA flow is how this should be handled now.
 
> Sure, but then the user doesn't get any message on why (or even that)
> RemoteUser failed which is what we want.

No, this again has to do with the fact that when the flows are all running at the top level, the system doesn't have the kind of behavior you want. The Password -> SPNEGO case is not typical, it's the special case.

> With the configuration above we get fallback to Password and a friendly
> notification that the login failed.

That's not possible unless the Password flow is actually running those other flows, and those other flows are not quite meant to be run like that. They weren't designed like the SPNEGO flow to start with. I would have to spend a lot of time playing around to see whether that's possible to fix or not or how I would try and fix it.

> Since both RemoteUser and SPNEGO fall back to Password you can configure
> the IDP to show the error messages of RemoteUser and SPNEGO on the
> Password login page.

See, that's just it, they *don't* fallback to Password, they just run whatever flow happens to be next at the top level. Unless you're running them *from* the Password flow. So the issue is that you're using that trick and not all the flows probably compose well with it, and you weren't really specific about that initially. I was thinking in terms of top level behavior.
 
-- Scott



More information about the users mailing list