idP 3 - optional 2F based on attributes

[Cantor, Scott]

> I have an authentication scenario that requires second factor authentication
> based on attribute values. These attributes are created by a data connector
> that uses the uid attribute as a source. The additional complication is the
> second factor flow (e.g., captcha) needs to produce attributes.

The only real semi-supported way to make attributes available after authentication would be to capture them in custom Principals and add them to the Subject. There's a new custom Principal class added in 3.2 to facilitate that use case.

But I'm not sure you're really "producing" attributes here. State information doesn't inherently need to be modeled as an IdPAttribute.

> I'm looking at AttributePostLoginC14NConfiguration. Is this the place to start,
> or do you think my use case requires a custom authentication flow? I am
> wondering in particular how to choose a flow based on attribute values.

No, that is not the same use case, that's about transforming the principal name via attribute machinery. I guess it's a sample of how to do attribute resolution in a flow, though, which isn't very hard to do. The ResolveAttributes action doesn't need much to run, just an AttributeResolutionContext somewhere in the tree and the right injected functors to get it to create the results somewhere else in the tree.

I am certain it will probably involve creating custom login flow(s). There's no way to select a flow based on attributes really, only "filter" them in a limited way. The selection "engine" provided is much less advanced than that and just walks the list supplied at runtime looking for one that's compatible with the request and that has a valid activation condition. It's possible to attach an activation condition that looks at anything in the context tree, but whether that's enough or not is hard to say.

The UI implications of these use cases are such that trying to automate them via any kind of abstract framework is probably doomed to fail in a lot of cases, wehereas just building flows is relatively simple once you know how to do them. The existing ones are usually pretty simple and short, SPNEGO being an exception.

-- Scott