Intercept flows and adjustable auth levels

[Cantor, Scott]

> One is the "expired password" situation.  In our case, password
> expiration is controlled by an attribute in our LDAP directory. When the
> password expiration attribute has a particular value, the password is
> expired for normal authentication, and can only be used to log in to
> change the password.  Ideally, the user would change their password,
> then be directed back to the original application where they are now
> logged in and ready to rumble.

An interceptor should handle that case well enough, as somebody else mentioned, adapting the one I checked in for expiring password notifications would be workable.

> What I'm trying to figure out at this point is how to handle
> authentication and/or "SSO" to the pw/secret app, perhaps by setting a
> proprietary URI in a Principal object in the AuthenticationResults
> (which basically mimics the custom auth type we used in v2). And then,
> figuring out how to trigger re-evaluation of the AuthenticationResults
> in the SubjectContext after the user has completed their task.

You can't manipulate that after the fact; it wouldn't be persisted so you're just changing a copy of the information and the session's copy would be the original. There's no supported way to change the content outside of an authentication step.

As far as how to handle some kind of specialized authentication, I can't really think of much that would work reliably. Using a special AuthnContext is no different than using a special attribute to signal it. It's an authorization problem, and most apps won't care or check. I would say that it needs to be part of the IdP itself if you want to do it cleanly, or you'd have to live with the likely leakage. I'd be curious how you managed to prevent applications from consuming the special auth type before?

> - Where might one put something to "upgrade" an existing
> AuthenticationResults by re-reading the user's LDAP entry? Perhaps doing
> it in a customized LDAP authn flow that could skip requesting a password
> when an existing AuthnResults is present but upgradeable?

That probably could work. Each login flow/type will only have one copy of its AuthenticationResult preserved in the session. So one way of "changing" the old result is to produce a new copy of it with the change and make that the result of that same login flow. That will overwrite the previous result from that flow in the session.

But you'd have to prevent the engine itself from just reusing the existing result directly and never re-calling your flow. About the only way to do that is with the custom Principal as AuthnContext trick, and that takes me back to the earlier question. I just don't see what stops anything from requesting or consuming that type of authentication.

> - Is it necessary/desirable to call out a custom auth type in the
> AuthenFlowDescriptor if no SP will ever assert it for matching?

You mean request it. Not if you don't trigger it via relying-party.xml I suppose. It wouldn't come into play as a basis for selection. I'm just wondering how you'd prevent an SP from requesting it to bypass your rule.

> - Is there some way to pick up a flow where it left off?  Perhaps as
> information in a dynamic link to our pw/secrets app (so it has a URL to
> return the user to when finished)?  Maybe Spring has some magic that
> allows this?

Yes, it's built into SWF. The flowExecutionUrl/URL/whatever variable is always available to views and expressions and that's the resumption location. That's how external authn is wired to work.

-- Scott