Objective:
Here, in this article it is demonstrated how a user or a group of users can be assigned the delegator role in order to mimic access rights of another user and thus, impersonate them.
With every new version of IBM Websphere Portal Server, several new features are introduced in order to assist Portal developers to provide rich and positive user experience and deliver proper content to each user. Features like Security, Personalization, user-editable content, etc. allows different user to view different content. In this case another developer’s or a support specialist’s life becomes difficult who is going to resolve issues on that portal. He or she does not know what content is visible to current user. He needs to find out various configurations, roles and personalization in order to start debugging the code or to resolve the issue.
The user impersonation feature in WebSphere Portal 6.1.5 onwards alleviates this challenge by permitting some users with the ability to assume the profile of others. When one user impersonates another, the user can experience the portal as if they were the impersonated user. An impersonator assumes a given user’s security access, user profile attributes, portal page and portlet customizations.
The delegator is able to see the portal exactly as it is visible to the user who is getting impersonated.
Implementation:
Scenario:
We have the following scenario implemented –
Users:
1. Admin – Insurance company administrator who provides various services
2. Customer – End user who subscribes for various insurance plans provided by Admin
Each customer can subscribe to multiple plansof an Admin and there will be several customers under a particular Admin.
When Customer logs in it sees home page with a portlet listing all the plans it has subscribed to.
When Admin logs in it sees home page with portlet listing all the Customerswho come under its services. On clicking on any Customer, Admin should be able to impersonate the corresponding Customer and thus should see the portlet listing all the services that the corresponding Customer has subscribed with all the security and personalization applied properly.
Step-by-Step Implementation:
Step 1:
WAS configurations to enable user impersonation:
1. Log on to the WebSphere Application Server Integrated Solutions Console or Network Deployment Administration Console.
2. Perform the following steps to enable the Impersonation feature:
a. Navigate to Resources > Resource Environment > Resource Environment Providers > WP Authentication Service > Custom Properties.
b. Click New.
c. Enter logout.explicit.filterchain in the Name field.
d. Enter com.ibm.wps.auth.impersonation.impl.ImpersonationLogoutFilter in the Value field.
e. Click Apply and then click Save to save the changes directly to the master configuration.
f. Navigate to Resources > Resource Environment > Resource Environment Providers > WP PortletServiceRegistryService > Custom Properties.
g. Click New.
h. Enter jndi.com.ibm.portal.portlet.service.impersonation.ImpersonationService in the Name field.
i. Enter com.ibm.wps.portletservice.impersonation.impl.ImpersonationServiceImpl in the Value field.
j. Click Apply and then click Save to save the changes directly to the master configuration.
3. Stop and restart the WebSphere_Portal server.
Step 2:
Portal configuration to assign delegator role to proper group or user who can impersonate other users :
a. Log on to WebSphere Portal as the Administrator.
b. Click Administration.
c. Click Access > User and Group Permissions.
d. Click Users or User Groups.
e. Search for the user or group you want to assign as Delegator.
f. Click the Select Resource Type icon for the required user.
g. Navigate to the page that contains the Virtual Resources option, using the Page Next button and click that link.
h. Navigate to the page that contains the USERS option and click the Assign Access icon.
i. Select the Explicitly Assign checkbox for the Delegator role.
j. Click OK.
k. Verify that the required user now has User and Delegator access.
The user(s) or groups with the Delegator role can now impersonate another user.
Step 3:
Following code is needed to initialize Impersonation and PUMA service in the portlet, and should be placed in the init method.
Listing 1:
public void init() throws PortletException {
super.init();
try {
javax.naming.Contextctx = new javax.naming.InitialContext();
pshimpersonate = (PortletServiceHome) ctx
.lookup(ImpersonationService.JNDI_NAME);
PortletServiceHomepshome;
pshome = (PortletServiceHome) ctx.lookup(PumaHome.JNDI_NAME);
pumaHome = (PumaHome) pshome.getPortletService(PumaHome.class);
} catch (javax.naming.NameNotFoundException ex) {
ex.printStackTrace();
} catch (NamingException e) {
e.printStackTrace();
}
}
Step 4:
When the Admin logs in, all the Customers are fetched using PumaLocatorand are displayed on the home page. On click of any Customer following processAction code is executed:
Listing 2:
@ProcessAction(name = "impersonateAction")
public void impersonateAction(ActionRequest request, ActionResponse response)
throwsPortletException, java.io.IOException, PumaSystemException,
PumaAttributeException, PumaMissingAccessRightsException, ImpersonationException {
System.out.println("Entering UserImpersonationPortlet.impersonateAction()");
//Getting Form data
String user_cn = request.getParameter("user_cn");
System.out.println("User-cn : " + user_cn);
// obtain the service object and use the service
ImpersonationServiceimpersonationService = (ImpersonationService) pshimpersonate.getPortletService(ImpersonationService.class);
PumaLocatorpumaLocator = pumaHome.getLocator(request);
List<User> users = pumaLocator.findUsersByAttribute("cn", user_cn);
if (users.size() > 0) {
try {
impersonationService.doImpersonate(request, response, users.get(0));
}catch (Exception e) {
throw new ImpersonationException();
}
}
System.out.println("Exiting UserImpersonationPortlet.impersonateAction()");
}
Using the ‘cn’ attribute of PUMA we can get the ‘User’ object of the user to be impersonated. Hence passing that object in doImpersonate() method will enable us to see the portal as it is visible to the impersonated user.
The PUMA group ‘Admin’ has been assigned as the delegator. So using:
impersonationService.doImpersonate(request, response, users.get(0));
we can see portal as it looks to impersonated user.Thus all members of PUMA group ‘Admin’ can now impersonate any user.
Application Flow :
When a customer logs in , say Michael :
When Admin logs in , say InsuranceAdmin :
Admin sees all the customers listed under him -
On clicking over any customer ( say Michael ), admin can impersonate the corresponding customer and see what is visible to him -
On clicking logout, Admin comes back to his own home page.
Limitations:
Impersonation cannot be used with Client-Side Aggregation (CSA). So CSA should be disabled for all the pages where impersonation is to be used.
Incomplete configurations may lead to exposure of sensitive information and privacy implications. For e.g. Support person need not to see the bank account or personal information of users. Or we need to ensure that impersonated user can only read the data, not create, update or delete it.
When a user who is enabled for impersonation impersonates other users, the people awareness feature is disabled for the entire session for which that user is authenticated.
Conclusion:
Impersonation preventsseveral database operations to occur redundantly.
It assists support personals to view customer’s query without prompting for credentials.
Helps in providing rich user experience by utilizing all the features provided by Websphere Portal Server. For e.g. Complex Personalization and security features may change the view of portal as it is visible to another user.
Relevant content can be delivered to proper user and can be customized by support person very easily.
Way of implementing impersonation is same in WPS 6.1.5 and WPS 7.0.0, so there is lots of documentation. No compatibility issues are there.
Authors:
Brij Mohan Lal Srivastava
Ascendant Technology
Chennai(India)