...
As a middle ground, I have a model in mind of implementing a reusable parent flow:
- Set up profile request state (usual preamble to all our flows)
- Run authentication in as standard a mode as possible
- Conditionally resolve attributes
- Apply AccessControl policies
- This needs some extending/revisiting to make it more ProfileRequestContext-friendly, perhaps just a specialization of the current interface
- DoWork
There are couple of ways this could compose:
- A parent flow, with children picking up from DoWork
- A top-level flow that maybe renders a menu/UI and does work by calling subflows that inherit the tree
Ordinarily I don't like parent/child as much because it's more complex and intertwined, but in this case, it has some advantages. Making the "real" functional flow the top-level flow means the reusable steps like authentication could be aware of what functionality is running, which is harder if it's happening up front and then there are calls into the real flows. On the other hand, calling subflows means authentication happens up front, and is reused automatically across a number of calls into subflows.
I toy with the idea of building some kind of primitive token-based authenticator to these flows, essentially a "session" with the IdP as a service, separate from its SSO layer. We have bits to do that if we want, but I think we could start simpler by just assuming authentication runs fully any time a flow starts, and SSO takes care of avoiding lots of extra prompts. Also allows a simple way of enforcing authentication requirements for a function by just populating a RequestedAuthenticationContext node with the policy to impose (e.g. require MFA to access token management).