Upgrade path : IdP V2 Filter --> V3 FlowExecutionListener ?

[Cantor, Scott]

> Just wondering if it sounds reasonable to say that an upgrade path for
> an IdPv2 Servlet Filter is an IdPv3 FlowExecutionListener. If so,
> maybe the configuration of flow-execution-listeners could/should be
> moved to user-space.

Filters a very general mechanism, I don't think that the listeners would be equivalent for any but a very tiny subset of use cases.

> The use case is auditing events, such as logout or session re-use
> (SSO), where the principal name is desirable.

I think auditing should be addressed with the auditing code, and all of that should already possible. Logout is heavily audited already.

> In v2, it was possible to get the IdPSession from the HTTP session.
> Not so much in v3. As Scott said on the last dev call : the session is
> on the client. So, custom code which is interested in the username
> needs to be called from within Web Flow, not outside of it like a
> Filter.

The username is in the context tree.

> With logout, there aren't any built-in interception points (for
> example, the post-authn profile intercept sub-flows), so I think the
> options for calling custom code are (1) a FlowExecutionListener, (2)
> overriding an Action bean, and (3) modifying flow definition files in
> system/. Not sure if (2) works. Narrowing the use case to auditing,
> another approach might be to extend auditing to somehow call user
> defined code (and thus create an API).

There already is a massive extension framework for auditing custom fields.

> But it's not possible at the moment for a deployer to add a listener
> without modifying system/conf/webflow-config.xml. Maybe the list (not
> sure it's a List) of flow-execution-listeners could be moved to conf/,
> not sure how to do that wiring.

That's a custom XML schema. We would probably have to redo the webflow config with native Spring unless there's a way to inject them after the fact.

> I imagine that writing to a database or sending a message somewhere
> upon some events occurring on the IdP would be useful or possibly
> required by some deployers. I'm thinking that flow execution listeners
> are the right approach. Does that sound right ?

Not unless we think the auditing layer should be replaced with that.

-- Scott