Policy Server Guides › Policy Server Configuration Guide › Impersonation

Impersonation

This section contains the following topics:

Security Considerations for Impersonation

Impersonation Overview

Impersonation provides a method for a privileged user to assume the role of another user without ending the privileged user’s session. This feature facilitates the following:

Customer service representatives (CSRs) impersonate customers to investigate access problems.
Helpdesk representatives impersonate employees to investigate access problems.
Employees impersonate co-workers who are on vacation or out of the office.
Any other situation in which one user must temporarily assume the identity, of another user.

Impersonation provides a secure solution in the preceding situations. In all cases, passwords are not disclosed to allow one user to impersonate another user.

The following terms are used when describing impersonation:

Impersonated session: A user session created for the purpose of assuming another user's identity.
Impersonatee: The user whose identity is assumed by a privileged user.
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: Also known as the Session Ticket or Session Spec, this term is the information 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 Policy Server’s Session Specification.

Impersonation Process

The process of impersonating another user consists of the following:

A privileged user (impersonator) establishes a session by accessing a resource that a policy is protecting.
The impersonator, using the currently established identity, accesses a form that lets the impersonator specify the user to be impersonated (impersonatee). The impersonator does require the credentials of the impersonatee. The form is an FCC file with special logic to enable the impersonated session.
The impersonator submits information about the impersonatee.

The Policy Server determines whether the impersonator can be impersonated using a series of policies.

Determines whether the impersonator has sufficient rights to impersonate the impersonatee.
Uses the established session of the impersonator when granting as the impersonatee.
Audits all impersonator activity.

The following diagram shows an example of impersonation:

Graphic showing the impersonation process workflow

A customer with a problem calls a CSR. The CSR determines that the best way to solve the problem is to impersonate the customer.
The CSR accesses the impersonation start page (/app/impersonators/startimp.fcc) to begin the impersonation process. The FCC presents a form to the CSR. The CSR provides the name of the customer to be impersonated and other attributes for disambiguation. Within the FCC are directives (not shown) that collect the session specification of the CSR for use by the authentication scheme. The impersonation authentication scheme is invoked on the Policy Server because the target of the FCC resides in a realm that is protected by the impersonation authentication scheme.
The Policy Server takes the information gathered by the FCC and uses it to determine if the customer to be impersonated can be found in any of the configured user directories. If found, the Policy Server determines if the CSR can impersonate the customer, and if the customer may be impersonated. If both are allowed, the Policy Server authenticates the impersonator and the CSR acts as the customer for the duration of the impersonated session.
Tthe Policy Server directs the CSR (impersonating the Customer) to the target of the FCC.