...
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.
| Localtabgroup | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
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. If the legacy file conf/intercept/impersonate-intercept-config.xml remains present, the beans in that file supersede the property definition(s) but you may remove the file if the default values or properties are used instead. |
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.
...
As a general matter, unless all of your attributes come from a persistent store you can re-query, this feature is not likely to work, or be safe to use.
Reference
| Localtabgroup | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
The following beans are defined in conf/intercept/impersonate-intercept-config.xml:
The following properties in conf/idp.properties may be used to override the default policy names used:
|
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.
...