38 Managing Impersonation

This chapter describes how to manage and configure WebCenter Portal Impersonation, which lets designated users impersonate other portal users and perform operations as those users. For instructions on how to initiate an impersonation session (by the impersonator) and how to allow an Impersonation session (by the impersonatee), see the "Using WebCenter Portal Impersonation" chapter in Oracle Fusion Middleware Using Oracle WebCenter Portal. For information about impersonation ELs and APIs, see the "ELs Related to Impersonation" section in Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.

To perform the tasks in this chapter, you must be granted the WebLogic Server Admin role through the Oracle WebLogic Server Administration Console. Users with the Monitor or Operator roles can view security information but cannot make changes.

38.1 Introduction to WebCenter Portal Impersonation

38.1.1 About WebCenter Portal Impersonation

WebCenter Portal Impersonation lets a WebCenter Portal administrator or system administrator assign impersonation rights to a group of users ("impersonators"), such as support representatives or application administrators, so that they can perform operations as other users ("impersonatees"). Note that this is subject to the impersonatee granting the impersonator additional rights to impersonate them. This may be useful in the following instances:

A customer support representative may want to perform actions as another user in order to understand the issues being faced by that user.

An administrator may want to perform operations on behalf of a user.

A company executive may need to delegate someone to act on his or her behalf while away.

38.1.2 Best Practices for Using WebCenter Portal Impersonation

All applications participating in Oracle Access Manager (OAM) from an impersonatee's system will also be accessible to an impersonator. The only exception to this is that an impersonator will not be able to access the Impersonation task flow and grant or modify impersonation rights. Consequently, administrators should exercise extreme caution when granting impersonation rights because of what an impersonator could potentially access. Impersonators should be a very limited group.

To initiate an impersonation session the impersonatee and impersonator should agree on an appropriate time slot for the impersonation session. The impersonatee should then grant impersonation rights for that time slot only. The impersonatee should revoke impersonation rights immediately after the impersonator is done.

Note that an impersonation session will end if the impersonator logs out. An impersonation session will also end when the specified impersonation time duration end point is reached. For example, if a user grants impersonation rights to an impersonator between 1:00 and 2:00 in the afternoon, although the impersonator can start an impersonation session anytime between 1:00 and 2:00, the session will end at 2:00.

Also note that if a user revokes an impersonation grant explicitly while the impersonator is in the middle of an impersonation session, the revoke will not affect any existing impersonation session for that user. It will only take effect the next time the impersonator tries to impersonate the user. The user will then not appear in the list of available impersonatees.

38.2 Preparing WebCenter Portal for Impersonation

WebCenter Portal impersonation relies on OAM 11.1.2.0. Before you can enable impersonation for a WebCenter Portal instance you must first install and configure OAM 11g (Oracle's single sign-on solution), and then turn on impersonation in OAM. For information about installing and configuring OAM 11g, see Section 33.2, "Configuring Oracle Access Manager (OAM)."

38.2.1 WebCenter Portal Impersonation Requirements

To prepare WebCenter Portal for impersonation you must first install and configure OAM 11.1.2.0 and then turn on impersonation in OAM. You will also need to add impersonation attributes for each participating user.

Note:

WebCenter Portal Impersonation requires that OAM 11.1.2.0 be installed and configured as the single sign-on solution, and that OID 11.1.2.0 is installed and configured as the identity store.

38.2.3 Adding Impersonation Attributes to the Identity Store

For users to be available as impersonators or impersonatees they need to have the following attributes available for storing the impersonation grants in OID:

orclImpersonationGrantee

orclImpersonationGranter

These attributes are a part of the orclIDXPerson object class that is available by default in OID. This object class must be added to the list of object classes for each user's user record that you want to participate as an impersonator or impersonatee. You can do this either by adding the object class to individual users, or as a bulk update for multiple users as described in the following subsections:

38.2.3.2 Adding Impersonation Attributes for Multiple Users

You can add the attributes available for storing the impersonation grants in OID as a bulk update using the bulkmodify tool. Note that to use this tool you need to be able to access the machine where OID is installed, have system administrator rights, and need to know the OID database password.

To add the attributes for storing impersonation grants in OID for multiple users:

Stop OID.

Go to $ORACLE_HOME/ldap/bin and run the bulkmodify tool.

Specify basedn as the DN under which all users you wish to add the object class reside. The connect string is the OID DB connect string, which is typically OIDDB (determined from $ORACLE_INSTANCE/config/tnsnames.ora). Provide the DB password when prompted. The following shows a sample run of the command:

Restart all servers in the WebCenter Portal domain, including the Admin Server.

You may also need to account for any time difference between your WebCenter Portal server and OAM. Although Impersonation start and end times are accepted in WebCenter Portal, they are enforced by OAM so the time settings must be consistent. To account for time differences:

Log into WebCenter Portal as an administrator.

Select Administration > Attributes.

The Attributes page displays.

Tip:

You can also access the Attributes page directly by opening the page in your browser:

38.4 Configuring Impersonators

After configuring OAM and WebCenter Portal, you must configure the users to whom you want to grant impersonation privileges by adding those users or groups to the webcenter#-#impersonators role. Out-of-the-box, no users are granted this role. Only users belonging to this role either by direct membership or through an enterprise role membership are eligible to impersonate users in a WebCenter Portal instance.

Changes to role assignments are available immediately. You do not need to restart the managed server.

38.5 Disabling Impersonation

WebCenter Portal Impersonation is disabled by default, so unless you have already enabled impersonation there is nothing that needs to be done to turn it off. However, if you have enabled it and now want to disable it, follow the steps below to turn it off in WebCenter Portal and OAM.

Note that turning off impersonation in WebCenter Portal only disables it for that particular instance. Any other WebCenter Portal instances for which impersonation was enabled will not be affected until you turn off impersonation in OAM.

To disable impersonation for WebCenter Portal:

Log into Fusion Middleware Control as an administrator.

Go to WebCenter Domain > Security > Security Provider Configuration.

Navigate to the Properties section and click Configure.

Under PropertySets, locate the property set that defines the impersonation start and stop URIs (typically "props.auth.uri.0").

Delete the properties imp.begin.url and imp.end.url.

Restart all servers in the WebCenter Portal domain, including the Admin server.

Note that until you disable impersonation in OAM, impersonation in other WebCenter Portal domains will continue to be enabled.

To disable impersonation in OAM and turn off impersonation altogether:

38.6 Turning off the Session Indicator

The session indicator is an overlay that appears on the impersonator's screen by default during an impersonation session. Although the overlay provides a visual clue that the impersonation session is active, and also provides a quick way to stop the session by clicking Stop Impersonation, it may obstruct a view of part of the user's (impersonatee's) screen as show in Figure 38-2.

Note:

When the impersonation session notification toolbar is turned off, users must use the Impersonation page to stop an impersonation session since the Stop Impersonation button will no longer be visible.

where host and port are the host and port IDs of the WC_Spaces server.

Set the new hotkey sequence as shown below:

oracle.webcenter.security.impersonation.key=new key

where new key is a single character to be appended to Ctrl-Shift. Note that you can only override the default "I" with another single character. The Ctrl-Shift sequence is predefined and will always precede the key. Be sure to check that the overridden character is not already used by other components, tools or plug-ins. For example, Ctrl-Shift-M is used by menus, and Ctrl-Shift-K and Ctrl-Shift-J are sometimes used by browser plug-ins such as developer tools and the error console.

Restart the WC_Spaces server for the change to take effect.

38.8 Managing Audit Logs for WebCenter Portal Impersonation

WebCenter Portal Impersonation, when enabled, activates logging for Impersonation-related events as part of the Fusion Middleware Audit Service. Audit log events are stored in a file (the Audit Bus-stop) by default, but can also be uploaded to a database for persistency.

Note:

If you enable WebCenter Portal Impersonation, it is highly recommended that you also enable audit logging. When Impersonation is enabled, audit logging tracks the impersonator, impersonatee, and the context surrounding each impersonation event.

The Audit Bus-stop file has a limited capacity so storing log information in a database where events can be queried long after their occurrence is also recommended.

Impersonation audit logging provides the following key benefits:

Events that alter the security settings of Portal, Portal Server, and major Portal Server artifacts are traceable

Auditable events contain all relevant event payload to help define the impersonator, impersonatee and the context surrounding an event