Using Password authn flow for 1st and 2nd factors

[Cantor, Scott]

> I'm wanting to use (copies of) the Password authn flow for the 1st factor
> (Kerberos backed) and 2nd factor (JAAS backed).

Unless you copy all of the code in all the actions, you're relying on implementation classes subject to change at any time. In other words, it's essentially not a feature and is an at your own risk approach if you don't create a very clean separation by completely avoiding use of implementation classes.

It's supported to extend the existing flow to utilize an arbitrary back-end by just supplying your own action bean, as documented, but that's not the same thing as duplicating it so two of them exist separately and reusing the existing flow definition.

Personally, I would simply not use the password flow like this, I'd just create my own flow by copying code as required as examples to emulate but the end result would be entirely your own and not subject to breakage as long as you strictly adhere to the login flow contract, which I attempted to document as best I could in a constrained amount of time.

> The 2nd would use a fork of jradius-client
> (https://github.com/detiber/jradius-client) talking to a RADIUS server

As far as I can see, there are no supported RADIUS clients in Java, so you are literally assuming ownership of that library code also. Just something to be aware of. The IdP will not be shipping RADIUS support unless that changes. That's not an acceptable risk we're willing to expose the community to.

> My stumbling block is getting a second copy of the flow
> working, and figuring out how to keep the username from the first instance
> through to the end instead of overwriting it in the second.

Well, the first part I addressed, and the second, well, they're not overwriting anything, they're separate flows using common working state perhaps but you cannot be relying on the working state of one flow in the other. If you need to consume a username from a flow,you do that by relying on a strategy mechanism that you can default to the same function used by the Duo flow, and it should be pulled from the output of subject canonicalization or an existing IdP session (the latter being the case if the first factor is bypassed for SSO).

> I think this would be generally useful for more than
> just me. A lot of OTP systems use RADIUS.

I agree, but we have no RADIUS library to rely on.

-- Scott