Policy Server Guides › Policy Server Configuration Guide › Impersonation

Impersonation

This section contains the following topics:

Impersonation Overview

Impersonation Process

Security Considerations for Impersonation

Policy Server Objects for Impersonation

Sample Implementation of 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.

Note: For information about sessions, see the Policy Server Administration Guide.

Impersonation Process

The process of impersonating another user consists of the following:

• A privileged user (impersonator) establishes a CA SiteMinder® session by accessing a resource protected by SiteMinder. This can be the Administrative UI or some other application or resource protected by a CA SiteMinder® policy.
• The impersonator, using the currently established identity, accesses a form which allows the impersonator to specify the user to be impersonated (impersonatee). The impersonator does not present 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 or not the impersonator may be impersonated using a series of policies.

• Determines whether or not the impersonator has sufficient rights to impersonate the impersonatee.
• Uses the impersonator’s established session when granting the impersonator access as the impersonatee.
• Audits all impersonator activity.

To begin an impersonated session, an impersonator accesses an .fcc file directly that has a target that points to a resource in the realm protected by the impersonation authentication scheme.

The following diagram shows an example of impersonation where a customer service representative (CSR) accesses an .fcc file directly to begin an impersonation session.

1. A customer with a problem calls his CSR. The CSR determines that the best way to solve the customer’s problem is to impersonate the customer.
2. The CSR accesses the impersonation start page which in this case is named “/app/impersonators/startimp.fcc” to begin the impersonation process. The Forms Credential Collector (FCC) presents a form to the CSR. The CSR provides the name of the customer to be impersonated, and possibly other attributes for disambiguation. Within the .fcc file 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 CA SiteMinder® realm that is protected by the impersonation authentication scheme.
3. 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 may 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.
4. Finally, the Policy Server directs the CSR (impersonating the Customer) to the target of the FCC.

Security Considerations for Impersonation

While impersonating a customer, an impersonator’s session specification will look to CA SiteMinder® much like the session specification of any customer. The major difference is that the impersonator’s distinguished name and the user directory in which the impersonator originally authenticated will be present as additional fields. This allows all impersonated access to resources to be passed through additional checks. It also allows the Policy Server to record impersonated activities for auditing.

The impersonated session specification is also used to prevent impersonation chaining. When the Policy Server determines that the fields for the impersonator DN and user directory are in use, it will not allow further impersonation and will reject the login attempt. This stops impersonators from stacking one impersonation on top of another to gain access to otherwise restricted resources.

Effects of Authentication Scheme Protection Levels

While impersonating a user, the protection level at which an impersonator originally authenticated will not be checked. Normally, when accessing resources in a new realm protected by an authentication scheme at a higher level, the user would be challenged for new credentials. However, since an impersonator should be a privileged user, these types of challenges will not occur during an impersonation session. Protection levels are meant to indicate the strength of credentials used to access resources in a realm. In the case of impersonation, there are no credentials specific to the user being impersonated, therefore protection levels are not considered.

Note: Once the impersonated session ends, protection levels are once again enforced normally.

Session Idle Timeouts

During an impersonated session, an impersonator’s original session can possibly idle out. This depends on the idle timeout value for the realm in which the impersonator originally authenticated. If the impersonator impersonates a user for a longer period than their original idle timeout, the impersonation session ends with the impersonator’s original session. To avoid this situation, increase the session idle timeout for realms in which impersonators commonly authenticate.