...
All interceptors are enabled or disabled on a per-relying-party basis using properties in the profile bean(s) you want to enable the flow for. See the ProfileInterceptConfiguration topic for an example.
Enabling Module
...
The primary configuration involved with this flow is to define AccessControl policies to control who can impersonate whom. And of course, one can customize the view template displayed.
The properties named idp.impersonate.generalPolicy and idp.impersonate.specificPolicy control the named AccessControl policies you want to apply. They default to "GeneralImpersonationPolicy" and "SpecificImpersonationPolicy" respectively. There are examples below.
...
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.
...
If the policy denies access, the failed attempt is logged and an event named "ImpersonationViolation" terminates the entire request. This is an event you can configure whatever error handling you prefer in response to (see ErrorHandlingConfiguration), but for new installs it's defined to be a "local error". Upgraded systems will need to add that event to the map of local events (you can compare your copy of conf/errors.xml to the one in the dist directory).
...
log an informational message
destroy any existing attributes resolved for the user
move the original username into an "impersonatingPrincipalName" property in the attached SubjectContext
populate the impersonated principal name into the attached SubjectContext
re-run the AttributeResolver with the effective subject name set to the selected value
add an audit field ("uu") containing the impersonating account so that it can be recorded in the audit log
Attribute Resolver Considerations
For most configurations, the only user-specific element of the resolution process will be derived from the principalName property of the AttributeResolutionContext provided to the resolver, which will be set by this flow to the impersonated name instead of the original one.
However, you should thoroughly examine and test your configuration to be sure that you're getting the output you expect. In particular, if you have behavior (likely via scripts or the advanced SubjectDerivedAttributeAttributeDefinition) that depends on content internal to the user's authentication state, this will not be effectively overridden by this flow.
To facilitate attaching conditions or adding script logic that can be made dependent on whether impersonation is happening, a new property has been added to the AttributeResolutionContext, the resolutionLabel, and it will be set to "intercept/impersonate" (the flow ID) when this flow is doing the resolution (it will be empty in the traditional case).
...
The following properties in conf/idp.properties may be used to override the default policy names used:
Name | Default | Description |
|---|---|---|
idp.impersonate.generalPolicy | GeneralImpersonationPolicy | Named AccessControl policy to run to determine whether to run this flow |
idp.impersonate.specificPolicy | SpecificImpersonationPolicy | Named AccessControl policy to run to determine whether to allow the requested impersonation |
Note that these are not Spring bean IDs, but rather keys into the map of policies defined to the access control service.
...
The "general" policy is a simple test of an entitlement attribute for a specific value that is intended to mean "allow this logged-in user to at least attempt impersonation", and uses the SimpleAttributePredicate Java class. This class is often used to implement authorization rules in the context-check interceptor.
The "specific" policy could be implemented by a somewhat-involved script, but the example below relies on an advanced Java class that checks the values of a resolved IdPAttribute against a dynamically computed candidate value (or values) produced by functions, which can themselves be scripts or expressions. This DynamicAttributePredicate class relies on an injected map of attribute names to functions, instead of attribute names to strings. The mapped function objects return the data values that have to be found in the named attribute at runtime to be a valid match. It's indirect instead of static/direct.
...