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

[Cantor, Scott]

On 3/31/15, 11:16 AM, "Daniel Lutz" <daniel.lutz at switch.ch> wrote:

>I'm working on an implementation of the SPNEGO/Kerberos authentication
>for IdP V3 based on SWF. I implemenented the authentication flow as
>an external flow using a helper servlet, similar to the "authn/X509"
>flow. 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).

>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).

As an example, an SP that requests PasswordProtectedTransport would not accept an SPNEGO result (unless the flow were configured so as to lie and include PPT as a custom Principal type in the result, but I'm assuming people aren't trying to lie).

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.

Of course, I wouldn't worry much about it initially, but eventually that's something it will need to do.

>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.

>That is, can you switch from one authentication flow to another one
>as many times as required?
>Or would this leave many unfinished flow executions?

It's (meant to be) designed so that interflow signaling of this sort just bypasses the usual logic the IdP is performing, and as long as it actually terminates and doesn't just loop endlessly back and forth, it's fine. But you have to be careful with the event handling and what you signal back, because anything that makes it back to the IdP can cause it to re-activate the internal selection logic, and overall it can just get pretty messy.

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.

-- Scott