ShowTable of Contents
Matthias Falkenberg - Software Engineer - IBM WebSphere Portal and IBM Web Content Manager
Managing enterprise portals with user impersonation
Managing enterprise portals
When talking about effective and efficient management of an enterprise portal there is a multitude of things coming to one's mind. You might think of license management or resource planning because those aspects are related to highly visible costs in your company. Leaving the topic of license costs aside, the question is what the team taking care of your enterprise portal spends their valuable time with. Usually, there are people who have a focus on planning release cycles, on performing migrations, and on consolidating the infrastructure. In addition, someone on your team is certainly devoted to application integration as well as application development and product customization.
Analyzing and solving problems
What I did not mention so far is problem analysis and problem solving. This facet is easily left out because nobody really likes to think that there might be a problem; be it an issue with the infrastructure, the portal software, custom applications and so forth. The truth is, it does not really matter what the cause of an issue is in the very moment when it occurs. The most important thing is to get the enterprise portal up and running as fast as possible (again). At the end of the day problem management is also about managing costs and keeping them low. Not only does that mean to have the right people looking into the hitch but also to give them the tools needed to get the job done and to get it done fast.
In the best case, the enterprise portal product already includes such tools and means for analyzing problems. IBM WebSphere Portal ships with, for example, the Portlet load monitoring feature and the dynamic cache monitor. It also offers fine-grained client side as well as server side logging and tracing that can be enabled whenever needed. What does not need enabling is the first failure data capture (FFDC). When an issue occurs, the FFDC feature instantly collects information about related events and errors.
Those tools and log files give you a valuable insight into the circumstances that lead up to a failure, hence, they support you in resolving problems effectively and efficiently.
Tackling the tough nuts with user impersonation
But there are always some tough nuts to crack. Among the hardest challenges are intermittent troubles and those that only affect particular users. Enterprise portals like IBM WebSphere Portal include comprehensive capabilities for personalization and customization based on user groups and even subject to specific users. Instead of delivering a single set of content and functionality to all users, every single one of them may enjoy a personal user experience, thus, making it difficult to examine any type of malfunction that only certain users are troubled with. This is where the user impersonation feature comes into play.
User impersonation allows you to access an enterprise portal as another user. In consequence, you get the same user experience as the impersonated user including access to the portal pages, portlets, and other portal components.
There are numerous situations when becoming a different user is beneficial to resolving a problem or helping the impersonated users quickly in fulfilling a task, for example:
A business user encounters an issue with an application after configuring it to meet the personal needs. The user cannot resolve the problem without help and suspects the reason is poorly written software.
After applying a fix to the enterprise portal, some business users contact you because they cannot access an application specific to their department any longer. You immediately check the server side log files but they do not show any irregularities.
Although the migration of the enterprise portal succeeded without errors, there are a number of business users reporting problems. They complain that one of the business applications does not work as it used to.
Intermittent malfunctions of an application trouble a particular business user. After a first check, you engage a support specialist. To avoid any impact on other users when looking into the problem, the analysis, which includes the deployment of a debug module and the use of extensive tracing, takes place after office hours when all business users have already logged off.
Imagine the scenarios given above and how user impersonation can support you helping your business users:
As a technical user impersonation allows you to check the state and the configuration of the application in the personalized user context. You do not depend on potentially less accurate information giving to you by the business user but get a first-hand view on the symptoms of the failure. This speeds up your analysis of the issue many times over and even allows you to correct what might be wrong with the configuration.
Without user impersonation you might have to ask the business user to provide a detailed description of the problem for you to imagine the current state of the application. You might also ask for screenshots and for a transcript of the settings. You might also use the IBM WebSphere Portal XML configuration interface to export all user customization data of the application to look at the settings of the particular user. Once you find the source of the trouble you might have to ask the user to implement the necessary configuration change or you might prepare a XML document for implementing the modification using the XML configuration interface.
By impersonating one of the business users that informed you about the trouble they are having, you can gain a better understanding of the situation. If the server side log file has not brought up anything until then or if it contains nothing but inconclusive entries, you can enable tracing for the failing application and reproduce the failure at any time. You can also capture client side traces and check them for clues. All this will give you a valuable insight to close in on the cause of the problem and might help you to implement a workaround for the business users to continue working.
Without user impersonation, you depend on the error description the business users provide. Often they have difficulties in collecting technical data, for example, client side traces using tools like Fiddler or Firebug. Apart from the technical skills they might not have, the analysis of technical problems is not their job. Furthermore, they might not be available to reproduce the issue when you would need them to in order to gather server side traces.
When a migrated enterprise portal goes life, the business users usually do not have access to the previous environment any longer. Therefore, it can be difficult to get a precise understanding of the change with respect to the user experience. You would need to rely on the description of the complaining business users. Using user impersonation, you can access a previous version or backup of the enterprise portal as well as the current environment as one of the business users for reasons of comparison. You can navigate the application to see the differences first-hand and to get traces from both systems in order check for potential changes in the code path through the application.
Without user impersonation the business users need to be involved in the problem analysis. You might have to rely on the accuracy of their error description and on their skills to provide answers and data to technical questions and requests like the capture of client side traces. Moreover, you might not have the chance to compare the failing application in the user context between the old and the new environment.
User impersonation allows you and the support specialist to work on the user-specific issue after office hours. You can deploy the debug module, enable tracing for the involved components, and perform as many tests as it takes to reproduce the intermittent problem that seems to only affect a particular user.
Without user impersonation you might have to ask the business user to stay late in order to navigate the enterprise portal in a way that forces the error to occur once you have the debug module set up and the trace specification enabled. The already troubled user might feel like a marionette and might be unwilling to help you in particular if it consumes a lot of time, which could be the case considering that the error only occurs intermittently.
Previewing the content of an enterprise portal
Fortunately, it is not always about problems and I most certainly do not want you to only think of user impersonation as a tool to solve tough, user-specific issues. There are many other user-cases that this feature either enables or eases.
One of those use-cases would be the preview of an enterprise portal from the perspective of a particular user with actual data. With almost endless opportunities of personalization as one of the fantastic capabilities enterprise portals give you, the effect of changes to the server and to its content are sometimes hard to predict: How does it look and how does it feel when adding this web content or that enterprise content, when changing this design artifact or that style element, when deploying a new version of this portlet or that iWidget? The answer is that it may be different for every single user of the enterprise portal because of user-specific settings and data.
With user impersonation, web content authors, web designers, application developers, and administrators can check the effect of changes on a certain users before publishing or them.
Managing the scope of user impersonation in single sign-on environments
Understanding the scope of user impersonation in single sign-on environments
Configuring single sign-on (SSO) for servers in an IT infrastructure is fairly common. Not only is it a necessity to enable certain integration scenarios, such as integrating enterprise content from various backend applications into an enterprise portal to create a single point of access, but it also improves the user experience almost indefinitely if a single log on to the enterprise portal allows the users to access any services needed for their day-to-day business.
But SSO can also be tricky and you have to put a lot of thought into the setup unless IT security has no more than an esoteric meaning to your company. Now with user impersonation in the picture you will have to think it through again. When you impersonate another user, you will take the user's place including all of the user's access permissions with respect to and maybe even beyond the enterprise portal. If it is part of an SSO domain, you might be able to roam freely and to access other servers and data in the same SSO domain in very the same way as the user being impersonated is allowed to.
Imagine you allow web content authors, web designers, application developers, administrators, and perhaps support specialists to impersonate users of an enterprise portal. As you have seen earlier in this article, they might all have a reason to use the user impersonation feature of IBM WebSphere Portal. But quite possibly they should not have a carte blanche to gain access to all applications and all data hosted by servers in the SSO domain by impersonating a user. Think of the support specialist that helps you to tackle a user-specific issue with the enterprise portal. Unless it is an integration topic, there is no reason at all for the support specialist to access other systems than the target enterprise portal.
On the other hand, enterprise portals are characterized by their capability to act as a single point of access to whatever services and data that is available in a company's IT infrastructure. Therefore, there might be good reason to extend the scope of user impersonation to those services and repositories - or to some of them at least.
The scope of the IBM WebSphere Portal user impersonation feature varies quite a bit depending on the security configuration of the application servers in your SSO domain. The major out of the box switch to manage the scope is called "Security Attribute Propagation". IBM WebSphere Portal adds a custom Java object to the security Subject of a user when the user is impersonated. The com.ibm.wps.portletservice.impersonation.impl.OriginalUserCredential allows the enterprise portal to differentiate between actual and impersonated users. Among others, it enables the enterprise portal and custom applications to control access to certain resources if the authenticated user is impersonated by another user.
Without security attribute propagation the OriginialUserCredential is not transported from one server to another in your configuration. Consequently, other servers in your SSO domain have no way of knowing whether the current user is impersonated or not. They will grant the user access to their resources regardlessly.
However, if the security attributes are propagated to the servers in your infrastructure, they can decide to block impersonated users while allowing actual users to pass. Because security attribute propagation uses Java serialization for objects contained in the security Subject, the OriginalUserCredential class must be available to the servers. By default only IBM WebSphere Portal knows it. Therefore, if security attribute propagation is enabled, the presence of an OriginalUserCredential in the security Subject prevents an impersonating user to access servers in your SSO domain other than IBM WebSphere Portal.
Extending the scope of user impersonation in single sign-on environments
As mentioned in the previous section of this article, one way to extend the scope of user impersonation to other servers in your infrastructure is to switch off security attribute propagation in your SSO configuration. This way, the OriginalUserCredential as the indicator of impersonated users does not flow from the enterprise portal to others servers.
In case you use security attribute propagation in your environment, SSO will fail with other servers for impersonated users if the servers do not find the OriginalUserCredential class in their classpath. While it is available in IBM WebSphere Portal V6.1.5 (or higher) out of the box, you must copy the custom security attribute class into the classpath of other servers (for example, IBM Lotus Quickr for WebSphere Portal before V8.5 or any version of IBM Connections) to allow impersonated users to access them seamlessly.
If you have installed PM34927 on your enterprise portal, you will find the com.ibm.wps.portletservice.impersonation.impl.OriginalUserCredential class in the wp.auth.cmd.ext.jar file located in the $APP_SERVER_ROOT/lib/ext/ directory. If you have not yet applied that fix, the class file is found in the wp.auth.cmd.jar file in the $PORTAL_SERVER_ROOT/base/wp.auth.cmd/shared/app/ directory.
You can extract the class file from the JAR file. Afterwards, put it into a directory or inside a JAR file that is in the classpath of the server that should grant access to users coming from an IBM WebSphere Portal server no matter whether or not the user is being impersonated. An example of a suitable location is the $APP_SERVER_ROOT/lib/ext/ directory of an IBM WebSphere Application Server installation.
Limiting the scope of user impersonation in single sign-on environments
The opposite of extending the scope of user impersonation in SSO environments is to restrict it. For instance, you might want to allow web designers to impersonate business users of your enterprise portal in order to test a new theme in the context of actual users but they should not be allowed to gain access to the IBM Connections server in the same SSO domain because that product is managed by a different team.
Or imagine a support specialist who should be able to impersonate an actual enterprise portal user to help you in the analysis of a user-specific issue but who must not be able to access the company data hosted by the enterprise content management server in the same SSO domain because external personel is not authorized.
To make sure that the applications servers that belong to a SSO domain are aware of impersonated users, you must enable security attribute propagation to ensure that the OriginalUserCredential is transported to other servers in the course of a propagation login. If the other servers are not instances of IBM WebSphere Portal V6.1.5 (or higher) or IBM Lotus Quickr V8.5 (or higher), the propagation login will fail by default if the custom security attribute is contained in the security Subject. Hence, the scope of user impersonation is limited to IBM WebSphere Portal based servers automatically if security attribute propagation is enabled in your SSO configuration.
But this is only because the deserialisation of the OriginalUserCredential contained in the security subject of an impersonated user fails on the target server because it cannot find the OriginalUserCredential class. It is not because the target server understands that the requesting user is impersonated by another user that might not be granted access per se. What you are actually looking for is a solution that allows servers to differentiate between actual and impersonated users in case of propagation logins. Apart from enabling security attribute propagation you need to add the com.ibm.wps.portletservice.impersonation.impl.OriginalUserCredential class to the classpath of the servers in your SSO domain as described in the previous section of this article.
Furthermore, you have to hook a custom Java Authentication and Authorization Service (JAAS) login module into (propagation) login flow of the servers to which you want to control the access for impersonated users. In general the main task of JAAS login modules is to authenticate users via callbacks to get credential information (for example, user identifier and user password). Of course, it is also in their power to make the user authentication fail, which is exactly what a custom JAAS login module is supposed to do when its purpose is to prevent impersonated users from accessing a server by means of SSO.
This article comes with a sample JAAS login module. Please refer to the inline comments to understand how you can check for a propagation login, how you can retrieve the OriginalUserCredential, and how you can let the login fail if the requesting user turns out to be impersonated rather than the actual user.
As an extension to the sample login module you might add code to dissect the OriginalUserCredential to increase the granularity of the decision as to whether a propagation login is rejected or not. You might extract the user identity or distinguished name of the impersonating user and only reject the login attempt if it is the user account of an external support specialist, who is only allowed to use another user's identity on a particular enterprise portal in your environment to resolve a user-specific problem.
Testing the sample JAAS login module
This section describes the use of the sample JAAS login module in an SSO environment consisting of two IBM WebSphere Portal V7.0 servers. The idea is to prevent a user that impersonates another user on enterprise portal A from accessing enterprise portal B despite the SSO configuration. The sample JAAS login module can be downloaded from Lotus Greenhouse (Greenhouse login/registration required). The RestrictiveAccessLoginModule.jar file contains the compiled version as well as the source code of the sample.
Given a working SSO configuration inlcuding security attribute propagation, the following steps are required to set up the sample JAAS login module:
Put the JAAS login module JAR file in the application servers lib/ext directory to make sure it is loaded by the application server core.
Log on to the administrative console of enterprise portal B.
Click Security > Global security > Java Authentication and Authorization Service > System Logins.
Edit the WEB_INBOUND login configuration.
Click New to add a new JAAS login module configuration.
Enter com.ibm.portal.impersonation.sample.RestrictiveAccessLoginModule as module class name.
Select REQUIRED as authentication strategy to make sure that the JAAS login module must succeed or the entire login will fail.
Click OK to confirm the configuration and to return to the WEB_INBOUND login configuration view.
Click Save to save the configuration changes to the master configuration.
Restart enterprise portal B.
With the setup done, you can test drive the implementation as follows:
Log on to portal A as administrator.
Search for the user you want to impersonate and select the user from the search result.
Open a new Web browser tab or window.
Enter a URL to the protected space of portal B in the address bar, for example: http://$PORTAL_B_HOSTNAME:$PORT_NUMBER/wps/myportal
Assuming the setup is correct, the impersonated user does not gain access to the protected area of portal B. The user is redirected to the public portal space and asked to authenticate instead. In addition, the SystemOut.log file of portal B shows messages similar to:
[1/1/12 17:06:51:416 CET] 00000021 SystemOut O com.ibm.portal.impersonation.sample.RestrictiveAccessLoginModule.initialize(subject, callbackHandler, sharedState, customProperties) ENTRY
[1/1/12 17:06:51:416 CET] 00000021 SystemOut O com.ibm.portal.impersonation.sample.RestrictiveAccessLoginModule.initialize(subject, callbackHandler, sharedState, customProperties) EXIT
[1/1/12 17:06:51:416 CET] 00000021 SystemOut O com.ibm.portal.impersonation.sample.RestrictiveAccessLoginModule.login() ENTRY
[1/1/12 17:06:51:416 CET] 00000021 SystemOut O com.ibm.portal.impersonation.sample.RestrictiveAccessLoginModule.login() isPropagationLogin: true
[1/1/12 17:06:51:416 CET] 00000021 SystemOut O com.ibm.portal.impersonation.sample.RestrictiveAccessLoginModule.login() Propagation login failed because the requesting user is impersonated by another user. Single sign-on is only supported for actual users.
[1/1/12 17:06:51:418 CET] 00000021 SystemOut O com.ibm.portal.impersonation.sample.RestrictiveAccessLoginModule.abort() ENTRY
[1/1/12 17:06:51:418 CET] 00000021 SystemOut O com.ibm.portal.impersonation.sample.RestrictiveAccessLoginModule.abort() EXIT false
[1/1/12 17:06:51:425 CET] 00000021 FfdcProvider W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on /opt/IBM/WP7/wp_profile/logs/ffdc/WebSphere_Portal_9290929_12.01.01_17.06.51.4194190387393558856601.txt com.ibm.ws.security.auth.JaasLoginHelper.jaas_login 253
[1/1/12 17:06:51:433 CET] 00000021 FfdcProvider W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on /opt/IBM/WP7/wp_profile/logs/ffdc/WebSphere_Portal_9290929_12.01.01_17.06.51.4304501767666259945061.txt com.ibm.websphere.security.auth.WSLoginFailedException 250
[1/1/12 17:06:51:441 CET] 00000021 DMAdapter I com.ibm.ws.ffdc.impl.DMAdapter getAnalysisEngine FFDC1009I: Analysis Engine using data base: /opt/IBM/WP7/wp_profile/properties/logbr/ffdc/adv/ffdcdb.xml
[1/1/12 17:06:51:451 CET] 00000021 FfdcProvider W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on /opt/IBM/WP7/wp_profile/logs/ffdc/WebSphere_Portal_9290929_12.01.01_17.06.51.4296860475952250422485.txt com.ibm.ws.security.auth.ContextManagerImpl.login 3356
[1/1/12 17:06:51:454 CET] 00000021 FfdcProvider W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on /opt/IBM/WP7/wp_profile/logs/ffdc/WebSphere_Portal_9290929_12.01.01_17.06.51.4512307018754613918384.txt com.ibm.ws.security.web.WebAuthenticator.validate 2952