Previous Topic: Add and Remove Global Policy Time RestrictionsNext Topic: Security Considerations for Impersonation

Policy Server Guides › Policy Server Configuration Guide › Impersonation

Impersonation

Impersonation provides a method for a privileged user to:

Impersonation does not require users to disclose passwords for one user to impersonate another.

The following terms are used when describing impersonation:

Impersonated session

A user session created for the purpose of assuming another the identity of another user.

Impersonatee

The user whose identity the privileged user assumes.

Impersonator

The privileged user that is able to assume the identities of other users.

Impersonation authentication scheme

A method for authenticating a user that allows a privileged user to assume the identity of another user while preserving the identity of the impersonator.

Session

Also known as user session. This term is the time between authenticating and logging out.

Session Specification

A session specification is also known as the Session Ticket or Session Spec.A session specification is the information that is held in a proprietary format on the Policy Server that describes a user and the characteristics of the current session.

SMSESSION

The name of the web agent cookie that contains the Session Specification of the Policy Server.

How an Impersonation Session is Initiated

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

Workflow for a Privileged User Iniating 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.

Workflow for an Impersonator Accessing a Protected Resource

  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.