Page Comparison

...

The beans named shibboleth.impersonate.GeneralPolicy and shibboleth.impersonate.SpecificPolicy in intercept/impersonate-intercept-config.xml must be defined by you with the named AccessControl policies you want to apply.

The "general" policy runs first up front and determines whether to actually offer the impersonation option. This is logically equivalent to attaching an activation condition to the flow itself, but the AccessControl service is reloadable, so using a policy is more flexible. The "specific" policy runs after an account name is selected to decide whether to allow it.

Since retrieving a policy by name that doesn't exist results in denial of access, the system is safe out of the box. Enabling the flow won't actually cause it to run due to the lack of a matching policy defined to allow access to it.

...

If the policy named by the shibboleth.impersonate.GeneralPolicy bean grants access, the view is rendered. Assuming a username is entered and the impersonation is attempted, the flow runs the policy named by the shibboleth.impersonate.SpecificPolicy bean. This policy is evaluated with its "resource" input set to the intended account name to impersonate, allowing the policy to react accordingly.

...

Example

Aside from the UI, all of the flow's configuration is actually just defining policies, either in conf/access-control.xml or an included file. In practice, a "real world" implementation of such policies would likely rely on some kind of directory or database of rules controlling which users can impersonate which users to which services, perhaps through group memberships resolved during initial attribute resolution.

For simple illustrative purposes, consider a rule that the flow is authorized only to users possessing a particular entitlement value, and then are allowed to impersonate any users named by a second custom attribute to services named by a third.

Notes

TBD