Intercept flows and adjustable auth levels
Christopher Bongaarts
cab at umn.edu
Tue Jun 28 19:00:42 EDT 2016
Thanks as always, you and Rich have given me enough to work from I
think. A couple clarifying comments:
On 6/28/2016 9:28 AM, Cantor, Scott wrote:
> 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?
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).
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).
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.
>> - 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.
OK. Requesting isn't a concern (no incentive), I just need to prevent
it from being used. 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...) If that doesn't do the trick
for this, maybe that would be a reasonable feature request - allowing a
per-relying party property to restrict the available auth methods... Or
maybe rely on the methods above.
>
>> - Is there some way to pick up a flow where it left off?
> 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.
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? I've noticed the "execution=s1e1" with various
numbers, and figured they might be tracking multiple "sessions" or
something. Either that, or it's a spoiler for season 1 episode 1 of
some TV show.
--
%% Christopher A. Bongaarts %% cab at umn.edu %%
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%
More information about the users
mailing list