LoginToSelf

Design notes on IDP-961 - Getting issue details... STATUS ...

The use case is having the ability to construct flows (or callouts to servlets) that leverage the IdP authentication layer and optionally the AccessControl service to protect user and admin features that require identifying a user, to control the data acted on and/or for access control to the features.

Admin functions eventually would include accessing metrics/state, checking on sessions, administrative logout, managing MFA token registrations, many others long term.

User functions include registering/managing MFA tokens, managing privacy/consent state, reviewing current application sessions (maybe, seems like a security risk to show that info, much like logout does).

Ideal

I'd rather just implement RP support and be done with it (so the IdP issues an assertion to itself), but we still don't have all the code for that yet in Java and it would take much longer than I have to spend on it to do well. I think we could work out a design that's less perfect but that we can eventually tap into later if we do the RP thing.

Interim

As a middle ground, I have a model in mind of implementing a reusable 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).