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

[Tom Zeller]

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.

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

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.

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

One similarity between listeners and filters is that they are both
mappable in a similar way.

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.

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 ?

Thx !