The session specification of the impersonator is treated like the session specification of any customer. The major difference is that the distinguished name of the impersonator and the user directory in which the impersonator originally authenticated are present as extra fields. The extra fields let:
The impersonated session specification is also used to prevent impersonation chaining. If the Policy Server determines that the fields for the impersonator DN and user directory are in use, it does not allow further impersonation and rejects the login attempt. This action stops impersonators from stacking one impersonation on top of another to gain access to otherwise restricted resources.
The protection level at which an impersonator originally authenticated is not checked during impersonation. Normally, when accessing resources in a new realm that an authentication scheme is protecting at a higher level, the user is challenged for new credentials. However, an impersonator is a privileged user, so these types of challenges do not occur during an impersonation session. Protection levels are meant to indicate the strength of the credentials that are used to access resources in a realm. There are no credentials specific to the user being impersonated during impersonation. As a result, protection levels are not considered.
Note: When the impersonated session ends, protection levels are enforced as expected.
During an impersonated session, the original session of the impersonator can possibly idle out. This depends on the idle timeout value for the realm in which the impersonator originally authenticated. If the impersonator exceeds the original idle timeout value, the impersonation session ends with the original session of the impersonator. To avoid this situation, increase the session idle timeout for realms in which impersonators commonly authenticate.
For an impersonation to take place, the impersonator and impersonatee must be bound to policies in an impersonation realm. The impersonator policy must have a rule that fires for the ImpersonateStart event and the impersonatee policy must fire for the ImpersoanteStartUser event.
Impersonation starts in a realm that is configured to begin the impersonation process. When an impersonator requests a resource in the impersonation realm, the impersonator is challenged by an impersonation authentication scheme. The scheme prompts the impersonator for credentials with a form. Instead of prompting for a user name and a password as is usual, the form prompts the impersonator to supply the user name of an impersonatee. Within the FCC file for the form, there is logic that sets the password to the current Session Specification of the impersonator.
The Policy Server uses the impersonation authentication scheme to verify that the current session of the impersonator is valid. Then the Policy Server attempts to find the user to be impersonated in the directories included in the policy domain that is associated with the impersonation realm. If the Policy Server finds the user, authentication proceeds.
If the Policy Server locates the impersonatee in a directory, it verifies that the impersonator has the right to impersonate, and that the impersonatee can be impersonated. These rights are configured and enforced using policies, rules, and two impersonation events.
Impersonation events are similar to authentication and authorization events, but are not passively invoked. Policies must specifically bind both the impersonator and the impersonatee to Impersonator event rules. If policies do not exist, or do not include impersonator event rules for the impersonator and for the impersonatee, impersonation is not allowed.
Impersonation can be allowed or disallowed in any realm using policies and rules with impersonation events. Realms can be configured to disallow all impersonation, or to restrict possible impersonators and impersonatees.
|
Copyright © 2014 CA.
All rights reserved.
|
|