Use of IdP's authentication flow to protect itself
Description
Environment
Activity
Scott Cantor August 27, 2016 at 1:16 AM
Eliminated the redundant error handling machinery in the resolvertest flow.
Finished preliminary documentation.
Scott Cantor August 24, 2016 at 1:32 PM
resolvertest retrofitted. The authn/attribute data shows up in the same spot as the eventual Subject/Attribute data for the test, so the flow clears out the whole tree after the up-front access check before proceeding with the original flow.
Scott Cantor August 22, 2016 at 3:13 PM
TBD: resolvertest flow was done differently from the others so will be additional work to retrofit.
Also would like to adjust the access checking behavior to populate resource/operation with something sensible for these flows.
Scott Cantor August 22, 2016 at 3:09 PM
r8337
Main check-in revising the status/reload flows to use the new machinery. Out of the box behavior is the same, but changing settings in admin.xml does allow authentication to be enabled.
Scott Cantor August 18, 2016 at 12:45 AM
Basic model:
InitialProfileRequestContext per usual.
Run new action, InitializeAdministrativeProfileContextTree, handing it a flow descriptor deduced from the profile ID in the context root. That will stuff the descriptor into a RelyingPartyContext as the ProfileConfiguration, which provides authentication settings. UIInfo also available for login form use.
If the profile config signals to do authentication, we'll populate a RequestedPrincipalContext and run authn per usual, which means we can control authentication flows and rules using the flow descriptors (e.g. require MFA for an admin page).
The child flows are then responsible for access control and doing their work.
The IdP needs a way to protect its own administrative features (few of which currently exist) with the authentication layer it uses for the SSO protocols. This is about the only web application I would ever argue should "do" authentication itself.
Some kind of hook for authz would be desirable, but I would be very hesitant to build it out beyond an interface so that we're not reinventing that wheel right now. Something like what I already built for that might be workable, don't know yet.
It would be simple to just prototype how a particular webflow could call into the authentication layer for its own use. Maybe that's good enough. It seems weird to think about adding some kind of additional "session" with the IdP to access its own features and not just use the one we have for SSO.