Policy Server Guides › Policy Server Configuration Guide › Impersonation › Sample Implementation of Impersonation

Sample Implementation of Impersonation

This section contains a description of a simple implementation of impersonation. The minimum Policy Server objects required to implement impersonation are:

Infrastructure Objects:

Agent

Impersonation requires a Web Agent and its associated Policy Server Agent object.

Note: To implement impersonation, you must have at least one CA SiteMinder® Web Agent installed in your deployment. More information on installing a Web Agent exists in the Web Agent Installation Guide.

Authentication Scheme

An impersonation authentication scheme based on the Impersonation Authentication Scheme Template is required. For the sample defined in this section, the authentication scheme is named "Impersonation Auth".

User Directory

Impersonation requires one or more user directory objects that point to user stores which contain impersonators and impersonatees. The two populations of users should be distinguishable due to an attribute value or group membership.

Domain

A policy domain is required. For the sample defined in this section, the policy domain is named "Impersonation Domain".

Domain Objects:

Realms

For the sample described in this section, two realms are required: "Impersonation" and "App1". The "Impersonation" realm should use the "Impersonation Auth" authentication scheme. The “App1” realm can use any authentication scheme.

Rules

For the sample described in this section, you must configure a rule under the "Impersonation" realm that allows access to all resources for the "Get" action. In other words, an asterisk should be entered in the Resource field for the rule. You must also configure the rules for the impersonation events. One rule allows impersonation if the impersonator is included in an applicable policy, and the other rule allows an impersonatee to be impersonated if included in a different, applicable policy.

Rules

A similar set of rules to those in the “Impersonation” Realm should be created under the “App1” realm.

Policies

For the sample described in this section, six policies are needed. One policy must be defined for each rule in the "Impersonation" realm, and one policy must be defined for each rule in the "App1" realm.

Sample Impersonation Implementation Assessment

Once all of the required Policy Server objects are in place, an administrator initiates an impersonation session by:

1. The administrator who will become the impersonator logs in to a protected network.
2. The administrator provides credentials and is authenticated and authorized.
3. The administrator accesses the imp.fcc file using a Web browser.
4. The administrator is prompted to enter a user ID for the person to be impersonated. The administrator may also be required to provide extra information about the user to be impersonated.
5. The administrator submits the information.
6. The Policy Server uses the policies that are defined for impersonation to determine:
   • Is the administrator allowed to act as an impersonator?
   • Is the user allowed to be impersonated?
7. If both are true, the impersonator impersonates the impersonatee.

Note: Without custom development,.jsp page or servlets for example, the impersonation session can be tracked using audit logging. However, it can be beneficial for an enterprise to create some custom web applications to monitor and track impersonation sessions.

Forms for Initiating the Impersonation Process

Impersonation requires a number of Web-based forms that must be customized for an appropriate interface for an enterprise. Forms contain the basic elements that should be presented by the .fcc file that invokes the impersonation process.

The hint field indicates that it is possible to configure impersonation to require additional attributes which can be used for disambiguating an impersonatee. The hint is configurable in the impersonation authentication scheme as a list of additional attributes, which can include information such as an employee number, or any other user attribute that uniquely defines a user in the user directory.

Impersonation Result Forms

The results of an impersonation attempt must be communicated in a form to represent both successful and failed impersonation attempts.

Note: The following forms are provided to illustrate the basic requirements for each form. All impersonation forms must be customized and referenced from the .fcc file.

Impersonation Logoff Forms

A form for ending an impersonation session must be configured.

Note: The following form is provided to illustrate its basic requirements. Impersonation forms must be customized and referenced from the .fcc file.