some comments about v3 post-login / post-authn flows

[Cantor, Scott]

On 9/3/14, 6:09 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>
>Where the strings like 'post-authn/consent/terms-of-use' are flow IDs,
>and their beans are flow descriptors which can be configured by the
>user. This feels alot like Servlet Filters, where subflows might
>decide to terminate execution of the chain or continue to the next
>subflow.

That's not a bad analogy. We have a large number of places now where you
can inject custom subflows at different spots, this is really just adding
an iteratable case of that.

>I wired in the master post-authn subflow into the abstract SSO flow
>after attribute resolution :
>
><subflow-state id="DoAttrCheck" subflow="access/attr-check">
>   <input name="calledAsSubflow" value="true" />
>   <transition on="proceed" to="DoPostAuthnSubflow" />
></subflow-state>
>
> <subflow-state id="DoPostAuthnSubflow" subflow="post-authn">
>    <input name="calledAsSubflow" value="true" />
>    <transition on="proceed" to="BuildResponse" />
></subflow-state>

I will probably just recast the attr-check thing I did as a post-authn
flow. It fits there just as well anyway, and it's one less step.

>Given this setup, someone deploying a post authn flow would need to
>copy their flow definitions below conf/flows/post-authn/, with
>Velocity templates going to views/, etc., without needing to modify
>anything under system/.

As long as we have some built-in to system to handle the vanilla cases.

>I'm hoping that once a post-authn model/framework is in place, folks
>interested in consent flows would know how to plug in to the IdP in a
>"standard" way.

The storage bit and the context tree is really the key to that I think,
once that's done and we have an example done, probably terms of use, it
should be very clear.

-- Scott