Intercept flows and adjustable auth levels

[Cantor, Scott]

> Obscurity (not documented publicly since our IDM group runs both the IdP
> and the pw/secret SP), and lack of incentive (I can't conceive of any
> reason why a sane SP operator would want to allow in users with expired
> passwords, and even the insane ones probably wouldn't bother going out
> of their way to allow it).

The hatred of our password change policy here is so deep that I wouldn't put it past somebody.

> Also, our v2 code is basically implementing the policy in code that the
> expired password auth level is not sufficient for authentication to SPs
> other than our pw/secret app (it doesn't issue a SAML response unless
> it's that SP; instead it shows the "But Thou Must change thy password"
> screen).

Yes, I guess that would take care of it.

> I'm glad you called this out though, since v3 handles this stuff
> differently.  Between intercepts to catch users with the status flags,
> and perhaps implementing a custom auth context evaluator that ensures
> "pw/secrets only" never satisfies any requested type might be a pretty
> good guard.

If you just block the response, that probably is all you need, since requesting it would just lead to an error.

> OK.  Requesting isn't a concern (no incentive), I just need to prevent
> it from being used.

Interceptor. That's simpler than trying to screw with the authentication behavior.

> Perhaps it's as simple as not specifying it in the
> defaultAuthenticationMethods of the default relying party, and only
> specifying it for our pw/secret app? (Javadoc suggests that that
> property limits the allowable methods...)

It does, but not listing anything leaves the choice wide open, and an SP request always trumps the setting anyway. It's a "default", meaning it can be overridden by the SP.

The only limit on *flows* that would run is really the other RP property, I think it's called activeAuthenticationFlows or something like that. That's expressed directly in terms of which login flows to turn on for the SP's request.

> Great, thanks!  One more question on this - is it possible to have
> multiple flows (or multiple instances of the same flow) running in one
> browser session?

Yes. The parameter is the key that differentiates conversations in different tabs or windows. The conversations are stored in the Java session, so it's one to many and it looks them up with the execution key, which is just a simple integer that increments. It's all opaque, the parameter is embedded in the flowExecutionUrl.

-- Scott