In order to implement impersonation in an enterprise, a number of Policy Server objects must be configured. The combination of objects provides the authentication and policy entitlements that are required to enable one user to impersonate another. The following objects are required for impersonation:
Impersonation requires a Web Agent and its associated Policy Server Agent object.
Note: To implement impersonation, you must have at least one web agent that is installed in your deployment.
Impersonation requires an authentication scheme object that is based on the Impersonation Template.
Impersonation requires one or more user directory objects that point to user stores that contain impersonators and impersonatees. The two populations of users should be distinguishable due to an attribute value or group membership.
Impersonation requires a policy domain object that includes the user directory object or objects.
Impersonation requires a minimum of two configured realm objects. One realm contains the resources accessible by the impersonatees. The other realm is the impersonation realm and contains the resources and rules that are required to initialize an impersonation session.
Impersonation requires access control rules to be in place. In addition, a rule with the ImpersonateStart event must exist for impersonators to begin an impersonation session. A rule with the ImpersonateStartUser event must exist in to allow a user to be impersonated.
In addition to policies that protect resources, impersonation requires extra policies to allow access to resources in the impersonation realm. These polices qualify users as impersonators and to limit the set of impersonatees.
To invoke an impersonation session, an FCC file, such as the sample startimp.fcc must be specified in the Impersonation authentication scheme and it must be processed by a Web Agent. By default, Web Agents do not protect files with the .fcc file extension.
One of the following two options is required for Web Agents to allow the initialization an Impersonation session:
Impersonation requires an Impersonation authentication scheme. This scheme is used as a method for an impersonator to initiate the impersonation process. To begin an impersonation session, an Impersonator directly accesses an .fcc file, which is a resource that Impersonation authentication scheme protects.
A critical part of impersonation is that the authentication process is using an appropriate authentication scheme and .fcc files. The .fcc files that enable the impersonation authentication scheme are installed with the web agent. The files must end in the extension: .fcc. Files with this extension can take advantage of special processing by the Web Agent. The impersonation authentication scheme is similar to an HTML forms authentication scheme.
An impersonator can invoke the impersonation authentication scheme by directly accessing the .fcc file for the scheme. The proper authentication scheme is invoked through the .fcc file’s target parameter. This value can be hard-coded in the .fcc file using the @target directive, or by setting the target (hidden form post variable) to the appropriate web page.
Note: The target resource must reside in a realm that the impersonation authentication scheme is protecting.
The FCC that begins the impersonation process must also include the @smpushsession=true directive, which instructs the Web Agent to save the current session cookie contents in another cookie so that the session cookie can now hold the session spec of the impersonated user.
The proper credentials must be presented to the Web Agent processing the impersonation authentication scheme to let authentication take place. The username should be the username of the user to be impersonated. The password should be set to the session spec of the impersonator, pre-pended, if necessary, with additional attributes. The FCC’s facility for substituting the contents of cookies or headers into directives at the time the form is posted should be used for this purpose. Using this facility, the FCC sets the @password directive to the Users Session Specification, with other data if necessary.
To end the impersonation process, another .fcc file can be included in the realm protected by the impersonation authentication scheme. This .fcc file should set the @target directive to point to a resource in the restricted realm that was used to begin the impersonation process. In addition, the @smredirect directive should be set to the same resource in order force an end for the authentication process. Finally, the @smpopsession=true directive should be used to restore the original session cookie.
When constructing an .fcc file for impersonation, the following directives should be used in the file:
This directive logs the user out of CA SiteMinder® and removes the SMSESSION cookie.
This directive adds HTTP request headers to the FCC namespace. For impersonation, this directive provides the contents of the session specification header, SMSERVERSESSIONSPEC (or SM_SERVERSESSIONSPEC; see Note about SMSERVERSESSIONSPEC and LegacyVariables), to the FCC namespace so that it is available for use as a password.
This directive allows a user to “impersonate” another user and then return to the original session. This directive must be set to "true".
This directive returns to the original session after @smpushsession has been used. This setting must be set to "true".
This directive redirects requests to the specified target.
This directive tells the FCC where to redirect to after processing a URL.
This directive specifies the contents of the password to be passed to the Policy Server.
Allows custom authentication schemes to send credentials larger than 4KB.This may be used in the same manner that the @password directive is used. When credentials are posted to an FCC using @smaltcreds, its value is sent to the Policy server during login as a byte buffer avoiding the password field which is restricted to 4k bytes. The @smaltcreds directive may not be used with existing out-of-the box authentication schemes, but it may be used for custom authentication. Developers of custom authentication schemes must code their authentication scheme libraries to look for the @smaltcreds credentials in the lpszCertBinary field of the user credential struct passed through the Agent API during login.
This directive specifies the user name to be passed to the Policy Server.
The "%" and "$$" functionality is used for data replacement similar to scalar variables in Perl. "%NAME%" is used to replace "NAME" with the data associated with "NAME" on a post. "$$NAME$$" is used to replace "NAME" with the data associated with "NAME" on a get.
The Web Agent includes the session specification in the set of headers that it includes with every request. The session specification header can be submitted as a password using several FCC directives. The @smheaders directive is used to include the SMSERVERSESSIONSPEC header in the namespace of the FCC. The @password directive is used to set the password to the contents of the SMSERVERSESSIONSPEC header.
The SM_SERVERSESSIONSPEC/SMSERVERSESSION header is only available if DisableSessionVars is set to its default value of false in the Web Agent configuration file.
Note: If the LegacyVariables Web Agent parameter is set to Yes, then the header should be SM_SERVERSESSIONSPEC. If the LegacyVariables Web Agent parameter is set to No, then the header should be SMSERVERSESSIONSPEC. The LegacyVariables parameter is not supported for Web Agents on IIS 6.0 web servers. For Web Agents on IIS 6.0, SMSERVERSESSIONSPEC is always the correct header.
The following .fcc file is invoked directly by an impersonator, or called by the impersonation authentication scheme to begin the impersonation process:
@username=%USER% @smheaders=%SMSERVERSESSIONSPEC% @password=%SMSERVERSESSIONSPEC% @smpushsession=true <html> <head><title>Sample Impersonation Form</title><head> <body> <h3> Please enter your Impersonation Information</h3> <form method=post><table> <tr> <td>User Name:</td> <td><input type=text name=USER></td> </tr> <input type=hidden name=target value="server.example.com/app/ impersonatee/successimp.htm "> <tr><td><input type=submit></td></tr> </table></form></body> </html>
The following .fcc file is invoked by impersonators to return to their original sessions.
@smpopsession=true @target=/impersonators/end.htm @smredirect=/impersonators/end.htm
While traditional Web Agents set fcccompatmode to yes by default, framework Web Agents set fcccompatmode to no. When the mode is set to yes, the Web Agent can process impersonation requests. However, when the mode is set to no, the following two requirements must be met in order for the Web Agent to process impersonation requests:
Impersonation events are rule events that must be configured and included in policies in order to allow a privileged user to impersonate another user.
You must configure at least one of each of the following impersonation events in order to enable impersonation:
When included in an appropriate policy, a rule that includes this event allows an impersonation session to begin.
When included in an appropriate policy, a rule that includes this event allows a set of users to be impersonated.
In order for impersonation to function correctly, multiple policies must be configured.
The following is required for the resource that initiates impersonation:
The following is required for an impersonator to access the resource:
Note: Policies must be in place for each resource that an impersonator can access.
The following figure shows the minimum policies that are required for an impersonator to access a resource:
If a site is composed of multiple cookie domains, the identity of the Impersonator could be confused while moving between resources in separate cookie domains. To avoid this problem the SMSESSION cookies in all of the cookie domains other than the current one must be cleared. This must be accomplished by modifying the forms that are used to begin and to end Impersonation. These forms should be augmented by HTML or script that calls server-side code to clear the SMSESSION cookies in all of the cookie domains other than the current one.
For example, consider Web Agents that are installed at yourcompany.com, subsidiaryA.com, and subsidiaryB.com. A Web Agent that carries out Impersonation could be located in the yourcompany.com domain. The .fcc files to start and end impersonation would need to call server-side functionality (JSP pages possibly) in subsidiaryA.com and subsidiaryB.com to clear out the SMSESSION cookies in those cookie domains for Impersonation to function correctly.
|
Copyright © 2014 CA.
All rights reserved.
|
|