Inter-Flow Signaling: switching back and forth between authentication flows

Daniel Lutz daniel.lutz at switch.ch
Tue Mar 31 15:02:37 EDT 2015


On 2015-03-31 at 17:31, Scott Cantor wrote:
> On 3/31/15, 11:16 AM, "Daniel Lutz" <daniel.lutz at switch.ch> wrote:
>> My flow is currently called "authn/SpnegoKerberos".
> 
> Just FYI, our convention is to capitalize acronyms, so if you were looking
> for it to be donated, it should be SPNEGOKerberos. Or just SPNEGO (are there
> any actual Kerberos specific assumptions in it? I thought SPNEGO was just
> mechanism independent).

Thank you for the hint. I will rename it to "authn/SPNEGO".

(I actually already considered this renaming. At the beginning,
I just decided to call it "SpnegoKerberos", since we focus on
supporting Kerberos and don't have plans to support NTLM.
Support for NTLM or other mechanisms might be added in the future.)

>> One possible deployment is to allow the manual initiation of the SPNEGO
>> authentication from the "authn/Password" flow's login page.
>> I can do this by using inter-flow signaling by triggering the event
>> "authn/SpnegoKerberos". This will call my flow "authn/SpnegoKerberos".
> 
> The only thing you have to be cognizant of with doing that is that you're subverting
> the selection logic the IdP performs to select flows based on the request. That means,
> for example, that you can call a flow to produce an AuthenticationResult that will later
> on not meet the SP's requirements and cause an error. The good thing is the IdP detects that,
> it doesn't assume that a flow that ran necessarily produced a compatible result (which was a
> bug in V2 that came up constantly).
[...]
> Generally flow signaling requires some code that checks the request state and determines whether
> signaling the flow is the right thing to do. I haven't really written such a flow so I don't have
> any example code for that yet, but the IdP should have the right predicates in place to be able to
> relatively cleanly evaluate a flow to see if it should run, basically what the
> SelectAuthenticationFlow action does.

Thank you for this hint. I will consider this and try to implement it
appropriately.

>> But in case of a SPNEGO authentication error, the user should get back
>> to the login page. I could manage this by triggering the event "authn/Password"
>> (via my flow's ClassifiedMessageMap, by a mapping from "NoCredentials"
>> to "authn/Password"). This will lead the user back to the login page.
>>
>> Is this the right way to do it?
> 
> Probably, yes (modulo the point above). Or you can avoid the remapping, just wire it directly
> to the flow name as the event.

Might you give me a hint how I can wire it directly to the flow name
as the event, and where I should do this?
(I'm not yet familiar enough to see how this is done.)

Would I do this somehow in the flow definition (e.g. spnego-authn-flow.xml)
or somewhere in the servlet?

In my current approach, my servlet uses the ExternalAuthentication
class to indicate the "NoCredentials" error (by setting the request
attribute ExternalAuthentication.AUTHENTICATION_ERROR_KEY). Then, my
ClassifiedMessageMap maps "NoCredentials" to "authn/Password".

>> That is, can you switch from one authentication flow to another one
>> as many times as required?
[...]
> I would say in general that you want to avoid doing too much of it.
> For example, I'd probably just signal back NoCredentials and let the
> IdP take back control and look for another flow to run, and if Password
> is the one left, that will just happen automatically if it should
> (and not if it shouldn't). And that allows for other flows that could be
> options instead of assuming password.

In case the flow "authn/SPNEGO" is signaled from the login form of the
flow "authn/Password" (e.g. through a button passing the parameter
"_eventId_authn/SPNEGO"), the flow "authn/Password" seems to be marked
as incomplete and moved to the intermediate set. This means that
"ReselectFlow" would not select it again. (That's the reason that I
currently manually select the "authn/Password" flow.)

Is there a possibility to re-activate the flow "authn/Password" again
in this case, so that "ReselectFlow" will select it again?
(Actually, the flow "authn/Password" hasn't failed in this case,
it has just not finished.)

Thank you a lot for your further help.

-- Daniel



More information about the dev mailing list