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