Policy Server Guides › Policy Server Configuration Guide › Impersonation › Policy Server Objects for Impersonation › How an Impersonation Session is Initiated

How an Impersonation Session is Initiated

The following figure is a detailed process flow for how a privileged user initiates an impersonation session.

1. A previously authenticated impersonator attempts to impersonate a user by accessing an Impersonation .fcc file.
2. The .fcc is not protected, or the CSR is allowed access (decision not shown). The Web Agent presents the form (.fcc) that was requested in Step . The FCC has a hidden form field configured to indicate that the target is in a realm protected by the Impersonation authentication scheme.
3. The impersonator indicates the name of the user to be impersonated.
4. The Web Agent uses the target field of the .fcc to determine the realm.
5. The Policy Server determines the credentials required by the Impersonation authentication scheme.
6. The required credentials are returned.
7. The Policy Server indicates the realm that is being used to protect the .fcc target.
8. The Web Agent attempts to authenticate the impersonated user using the impersonator's session spec as a password.
9. The Impersonation authentication scheme's functionality is invoked to authenticate the user given the supplied credentials (the impersonatee name and the impersonator's session spec). The impersonator's session spec is validated. The Policy Server disambiguates the user and authenticates the impersonation session.
10. The Policy Server verifies that there is an event policy tied to the ImpersonateStart event. If there is a policy that applies to the impersonator, a similar check is performed to determine if there is am ImpersonateStartUser event bound to a policy that applies to the impersonatee. Responses can be tied to rules in either policy.
11. Once the impersonator has been authenticated using the impersonation authentication scheme, he can now attempt to impersonate the user in any application.

    Note: Since the impersonator has not accessed any resources, no impersonation has taken place.

    The session specification, is returned to the Web Agent. It contains the DN of the impersonatee and the DN of the impersonator, as well as the directories where both the impersonator and the impersonatee were located.

    The Web Agent moves the existing SMSESSION to SMSAVEDSESSION and sets a new SMSESSION cookie equal to the new session spec due to a @pushsession directive in the FCC.

12. The Web Agent attempts to determine if the impersonatee is authorized for the .fcc target resource.
13. The Policy Server indicates that the impersonatee is authorized for the .fcc target resource.
14. The impersonator accesses the resource that was indicated in the impersonation .fcc. For example, this can be a .jsp page that will indicate the DN of the impersonator and of the impersonatee.

1. The impersonator (now impersonating a user) navigates to a new application.
2. The Web Agent calls the Policy Server to determine if the resource is protected.
3. The impersonator access the requested resource.
4. Since the resource is protected and an SMSESSION cookie exists in the impersonator's Web Browser for this cookie domain, the Web Agent calls the Policy Server to validate the session spec.
5. The session spec is validated according to current authentication logic except that additional checks are made against the impersonator and the user because the validation logic can determine that impersonation is occurring due to the contents of the session spec. The impersonator must be bound to an event policy in the current realm that has a rule for an ImpersonateStart event. The user must be bound to a similar policy for the ImpersonateStartUser event that applies to users that can be impersonated.
6. The Web Agent asks the Policy Server if the user is authorized for the resource.
7. The Policy Server responds with an authorization response. The authorization response can indicate that the access is allowed or that the access is denied for a multitude of reasons (no rule fired for this resource or access was explicitly forbidden for the user, auth level was too low, session timed out, etc). All of these access reject reasons mirror the user experience. However, Protection Levels are not enforced for impersonated sessions.
8. The requested resource is returned.