...
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.
Localtabgroupexpand | |||
---|---|---|---|
Localtab live |
| ||
The beans named shibboleth.impersonate.GeneralPolicy and shibboleth.impersonate.SpecificPolicy in conf/intercept/impersonate-intercept-config.xml must be defined by you with the named AccessControl policies you want to apply. Localtab live | | active | true
Expand | ||
---|---|---|
| ||
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. |
...
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
Localtabgroupexpand | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Localtab live |
| ||||||||||
The following beans are defined in conf/intercept/impersonate-intercept-config.xml:
Localtab live | | active | true
Expand | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
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.
...