Restricting authentication based on group membership when configured for standalone LDAP

Question
How do you configure IBM WebSphere Portal so that only members of a specific group can log in if WebSphere Portal security is configured to use a standalone LDAP?

Answer

The same general steps will be taken for each supported LDAP although the specific userFilter will differ depending on the LDAP brand and/or version.

First, check with your LDAP administrator to confirm that your LDAP implements an attribute whereby group membership is specified within each user record. The IBM® Redbooks® publication, "IBM WebSphere Portal V6 Self Help Guide", lists the default attributes used for memberOfAttributeName support in several supported LDAPs in table 5-15 on page 155.

If your LDAP implements one of these attributes, verify that it can be used to properly identify the subset of users who should be allowed to authenticate to the Portal server. Check the userFilter in the wkplc.properties file: (This assumes the userFilter in wkplc.properties was not edited since originally enabling security. You can likewise refer to the ConfigEngine helper files for your LDAP to help construct your userFilter.)

standalone.ldap.userFilter=(&(cn=%v)(objectclass=inetOrgPerson))

Test the search filter using ldapsearch prior to making any changes to the WebSphere Portal configuration. Your ldapsearch might look something like:

ldapsearch -x -v -D -w -h -p -b (&(objectclass=inetOrgPerson)(groupMembership=))

(This example uses Novell eDirectory's groupMembership attribute.)

If the search succeeds, add the (cn=%v) back to the userFilter, then back up and update wkplc.properties as follows:

standalone.ldap.userFilter=(&(cn=%v)(objectclass=inetOrgPerson)(groupMembership=))

( is a distinguished name and might be something like cn=portalgroup,o=yourOrganization.)

Update the WebSphere Portal and WebSphere Application Server security configurations by running wp-modify-ldap-security as described in the Information Center v6.1:

WebSphere Portal > Installing WebSphere Portal > Setting up WebSphere Portal > Setting up a (standalone/clustered) production server > Configuring WebSphere Portal to use a user registry > Configuring WebSphere Portal to use a user registry on (your OS) > Choosing your user registry model on (your OS) > Configuring a stand-alone LDAP user registry on (your OS)

Users should now be authenticated only if they belong to the group identified by above.

How to forward search requests to the Search Center Portlet

Problem(Abstract)
This technote discusses how to create a search box that will forward search requests to the Search Center Portlet.

Resolving the problem
Search functionality is often crucial but there are times when placing the default Search Center portlet on a page does not fit with the plan and design of a portal. The solution is to write a simple search box that can be conveniently put on your Portal page that will forward the query to the complete Search Center Portlet on a new page.
In IBM WebSphere Portal 6.1, this can be accomplished with code similar to the following.

Add the code to the banner_searchControl.jspf file (located in \profiles\wp_profile\installedApps\\wps.ear\wps.war\themes\html\):

<%@taglib uri="/WEB-INF/tld/portal.tld" prefix="wps"%>

Portal 6.1 will not start after enabling runtime Warning tracing level

Abstract
IBM WebSphere Portal version 6.1 or higher is installed successfully, however during the startup of the server, users are unable to access the login page and receive an error of 404: Page Not Found. The SystemOut.log file shows an error message of EJPFD0016E: Initialization of service failure while the Portal appserver was starting. This Technote explains how to resolve this error so users can successfully access the portal's login page.

Content

Actions Taken to Induce Behavior
1) Login to the WebSphere Application Sever Administrative console for the WebSphere_Portal
server (i.e. http://hostname:10027/ibm/console by default).
2) Navigate to Troubleshooting -> Runtime Messages -> Runtime Warning
3) Select Warning from the pull down menu and click apply.



4) Review and Save the changes.
5) Restart the WebSphere Portal server.

*Note: This behavior will only be induced if logging into the Application Server Administrative console that is running in the WebSphere_Portal application server, for example:
http://hostname:10027/ibm/console

It will not be induced if logging into the Application Server Administrative console that is running in the server1 application server, for example:
https://hostname:10003/ibm/console.

Look in the serverindex.xml file to confirm which WC_adminhost_secure port numbers are being used for server1 and WebSphere_Portal.


Review of the Portal SystemOut.log File
The file SystemOut.log records many activities that the portal undertakes during
startup and runtime. Reviewing this file, the following might be observed:
[4/21/09 17:49:27:438] 00000014 Servlet E com.ibm.wps.engine.Servlet init EJPFD0016E:
Initialization of service failed.
Caused by: java.lang.ClassNotFoundException: com.ibm.wps.services.ServiceHelper
[4/21/09 17:49:27:486] 00000014 ServletWrappe E Deregister the mbean because of uncaught init()
exception thrown by servlet portal: javax.servlet.UnavailableException: Initialization of one or more
services failed.
Caused by: java.lang.NoClassDefFoundError: com.ibm.wps.services.ServiceHelper

Resolving the Errors
1) Locate the following file:
/wp_profile/config/cells//nodes//servers/WebSphere_Portal/server.xml
2) Make a backup of this file.
3) Open this file in an ASCII text editor
4) Locate the following line in the server.xml file:
${WPS_HOME}/base/wp.script/lib/wp.wire.jar
5) Add the following line JUST after this line in the server.xml file:
value="${WPS_HOME}/shared/ext" description="Internal Portal component"
required="false"/>
*Be SURE the xmi:id= does NOT match any other items in this file.
6) Save the server.xml file.
7) Stop and start the Portal server.

APAR Fix Available
WebSphere Application Server (WAS) APAR PK79875 will prevent this behavior from occurring. This APAR is scheduled for inclusion in the WAS 6.1.0.25 and 7.0.0.5 fixpacks. If runtime warning messages are required in the affected environment, it is STRONGLY recommend the interim APAR fix be installed to prevent the ws.ext.dirs property from being overwritten.

Technical Explanation: Missing Java .jar File During Startup
WebSphere Portal is dependent on correctly loading a number of Java .jar files during startup to
correctly function. In this instance, the NoClassDefFoundError indicates the Portal system is either using
an incorrect Java classloader to load the .jar file, or, is unable to locate a .jar file needed for proper
operation.

Reviewing the Portal SystemOut.log file, the following may be observed during a previous startup
attempt:

ws.ext.dirs = /opt/IBM/WebSphere/PortalExpress/AppServer/java/lib:[...]:/opt/IBM/WebSphere
/PortalExpress/AppServer/deploytool/itp/plugins/com.ibm.etools.ejbdeploy/runtime:/opt/IBM
/WebSphere/PortalExpress/PortalServer/shared/ext

Reviewing the Portal SystemOut.log file, the following may be observed during a current startup attempt:

ws.ext.dirs = /opt/IBM/WebSphere/PortalExpress/AppServer/java/lib:[...]:/opt/IBM/WebSphere
/PortalExpress/AppServer/deploytool/itp/plugins/com.ibm.etools.ejbdeploy/runtime

Observe the missing /opt/IBM/WebSphere/PortalExpress/PortalServer/shared/ext value in the ws.ext.dirs parameter. This parameter is built from the WebSphere Portal server.xml file. The actions taken section caused an update to occur to the WebSphere Portal server.xml file. This update inadvertently overwrote the property which specified the ws.ext.dirs parameter.

Overriding the Web Content Management (WCM) presentation template by way or URL parameter in v6 functions differently from v5

Question
You utilize the pageDesign= URL parameter to control which presentation template to display at time or rendering in Web Content Management (WCM) v6 and receive unexpected results compared to v5


Answer
The solution varies depending on where you call the URL command your version of Web Content Management.
v5:

To override or to specify a specific presentation template (or page design) to a WCM object at time of rendering, append the following URL parameter depending on the request context.

For a servlet: some_url?pageDesign=my_template


For a portlet: some_url&pageDesign=my_template

v6

To override or to specify a specific presentation template (or page design) to a WCM object at time of rendering, append the following URL parameter depending on the request context.

Scenario 1: If you are loading the presentation template from the same library as the object you are rendering:

For a servlet: some_url?pageDesign=my_template

For a portlet: some_url&pageDesign=my_template

Scenario 2: If you are loading the presentation template from a library that is different than that of the object being rendered:

For a servlet: some_url?pageDesign=my_library/my_template

For a portlet: some_url&pageDesign=my_library/my_template

Retrieving the rendering context within a WCM .jsp component

Question How do you retrieve the rendering context within a Lotus Web Content Management (WCM) .jsp component? Answer Sample .jsp: 1. For the preview to work, place the code in the following directory: \ibm\WebSphere1\profiles\wp_profile\installedApps\\wcm.ear\ilwwcm.war\jsp\html> 2. Access via a .jsp component configured with the following path: /jsp/html/render.jsp. Note that this .jsp will not work if accessed directly using a URL in a browser such as xxxx/wps/wcm/jsp/html/render.jsp. The .jsp must be accessed via Preview or a rendering portlet. If you are accessing the content via the Web Content Viewer local rendering portlet, you must also place the .jsp in the war/jsp/html directory for the local rendering portlet. Here is a sample location: \websphere\PortalServer\installedApps\WCM_Local_ng_Portlet_zkj5916.ear\zkj5916.war\jsp\html\ If you use the Remote Rendering Portlet, you must place it there as well. <%@ taglib uri="/WEB-INF/tld/wcm.tld" prefix="wcm" %> <%@ page language="java" contentType="text/html; charset=ISO-8859-1" %> <%@ page import="com.ibm.workplace.wcm.api.*" %> ">Cannot get Workspace <% RenderingContext currentRenderingContext = (RenderingContext) pageContext.getRequest().getAttribute(Workspace.WCM_RENDERINGCONTEXT_KEY); out.println("APP PATH: " +currentRenderingContext.getWcmWebAppPath() + " "); out.println("Servlet PATH: " +currentRenderingContext.getWcmServletPath() + " "); out.println("Rendering Context " +currentRenderingContext.getPath()); %> <%-- Note: if the rendering context is returning %2F instead of "/", you may want to use the string replaceAll method to modify. For example: String myContext = currentRenderingContext.getPath(); String myModifiedContext = myContext.replaceAll("%2F", "/"); --%>

Determining if WebSphere Portal security configuration is standalone or federated

Question How do you determine if your IBM WebSphere Portal security configuration is standalone or federated? Answer Open the security.xml file. Standalone: /config/cells//security.xml Cluster: /config/cells//security.xml The activeUserRegistry property appears on line 2. If the configuration is federated (which is the out-of-the-box default), the value will be WIMUserRegistry_1. If the configuration is standalone, the value will be LDAPUserRegistry_1. Running the Portal configuration task, wp-modify-ldap-security, will change the security configuration to standalone. Among other things, a standalone configuration does not support multiple repositories, including multiple LDAP servers. If your architecture requires multiple LDAP servers and you have a standalone security configuration, run the config task wp-modify-federated-security to "switch" or convert to a federated configuration before running any tasks to add another repository. Refer to Configuring WebSphere Portal to use a user registry for details

How to disable unused applications in WebSphere Portal v6.1.x.

Question What is the minimum set of applications needed to run IBM® WebSphere® Portal v6.1.x? How can you disable or uninstall extra applications that are not in use? Will this improve the startup performance and decrease the total startup time of the Portal 6.1.x system? This technote provides detail about what applications should run to enable WebSphere Portal v6.1.x to function correctly and how to safely disable applications that are not in use. Answer Overview: WebSphere Portal and Lotus® Web Content Management (WCM) version 6.1 can be installed in a number of different configurations. In a default full installation including both Portal and WCM v6.1.0.1, a total of 103 applications are installed. In many scenarios, it is not desirable to run all 103 applications simultaneously. WARNING about disabling applications: This technote provides details on how to disable or uninstall applications in a Portal environment. Making such changes may have unintended side effects on the Portal environment. It is STRONGLY recommended that any changes first be applied in a sandbox or test environment where such changes and the potential for unintended side effects will have minimal impact prior to being attempted in a development, quality assurance, or production environment. Limitations of IBM Support IBM Support cannot recommend which specific applications should be disabled in a given environment. Each customer's environment is unique and any recommendations would require a detailed analysis and customization per environment. Such a customization is provided by IBM Services but not by IBM Support. The minimal set of applications is noted in this technote. Thorough testing should be done to ensure that disabling an application does not adversely affect other applications operating in the same Portal environment. Method #1: Automatically disabling applications via the Portal configuration task The "enable-develop-mode-startup-performance" configuration task will automatically disable all applications except the bare minimum needed to run WebSphere Portal v6.1.0.1. As described in the Portal 6.1.x Information Center, this task performs the following actions: Java Virtual Machine (JVM): JVM will be switched to development mode and the initial heap size will be set to the maximum heap size to reduce the amount of garbage collection during start up. Portlets Portlets and Web Applications will be activated on first access and not at start up. Since some of the portlets and applications are required at start up, a white list will hold the applications still started at start up. NOTE 1: The configuration task will disable MANY applications and break functionality including Portal search functionality, Web Content Management (WCM), custom applications, and so on. To prevent the configuration task from disabling functions such as custom applications and search, the Portal 6.1.x Information Center contains information to whitelist applications so they are not disabled by the configuration task. NOTE 2: To add applications to the white list, modify the profile\PortalServer\config\StartupPerformance\ wp.base_ProfileEarAttributesTargetMapExclList.jacl file. Add a line such as lappend WarFileNameList App_name, where App_name is the name of the application. Log into the WebSphere Application Server console mode and navigate to Applications --> Application Types --> WebSphere Enterprise Applications to get a list of available applications. On a Portal 6.1.0.1 system, all applications EXCEPT the following will be disabled: content_j2ee jcrear isclite ivtApp Live_Object_Framework PA_Login_Portlet_App PA_PortalWSRPProxy PA_PTransformationApp Personalization_Lists_6 Personalization_Workspace_6 query wps NOTE 3: It is recommended this configuration task be run with an administration installation although it can be successfully run with a full installation of Portal 6.1.x. Method #2: Disabling applications manually: If it is not desirable to automatically disable 91 applications from auto-starting, it is possible to perform this task manually and disable each application one at a time. To perform this task of preventing the applications from auto-starting: 1. Start the WebSphere Application Server associated with WebSphere Portal(startServer.sh server1). 2. Log into the WebSphere Application Server administration console (https:/ /hostname.company.com:10003/ibm/console). 3. Go to Applications --> Enterprise Applications --> individual application such as PA_Search_Center. 4. Click "Target specific application status" --> Disable Auto Start. 5. Optional: Go back to the application listing and click Stop to stop the application that is currently running on the Portal server. ************************************************************************* Technical considerations: Disabling vs. uninstalling applications: In general, once applications are uninstalled, they can be very difficult to redeploy correctly, especially if the system was upgraded. Therefore, it is STRONGLY recommend that instead of uninstalling applications permanently, the applications should be disabled from auto-starting when the Portal server is started. The applications will take a minimal amount of storage space on the Portal system (and on the Deployment Manager if in a cluster) and will not be in use by the Portal system during startup or normal operations. Should business needs change, the applications will be available and can be enabled at a moment's notice. Further, if an application is uninstalled and there is a hidden dependency that is unknown, it can be painful to attempt to reinstall the application instead of simply restarting the application if it is disabled and not auto-started. Portal 6.1.0.1 startup performance time At the time of this writing, a limited amount of testing was done on a test lab machine in which the applications were disabled using the Portal configuration task, "enable-develop-mode-startup-performance", explained in Method #1 above: With a default installation of the Portal 6.1.0.1 Content Server with all 103 applications enabled, reviewing the SystemOut.log file for a startup time displayed a total startup time of approximately 3 minutes, 10 seconds: [datetime] 0000000a ManagerAdmin I TRAS0017I: The startup trace state is *=info. [datetime] 0000000a WsServerImpl A WSVR0001I: Server WebSphere_Portal open for e-business With a default installation of Portal 6.1.0.1 Content Server with 91 of 103 applications disabled via Method #1, reviewing the SystemOut.log file for a startup time displayed a total startup time of approximately 1 minute, 39 seconds: [datetime] 0000000a ManagerAdmin I TRAS0017I: The startup trace state is *=info. [datetime] 0000000a WsServerImpl A WSVR0001I: Server WebSphere_Portal open for e-business Exact performance gains or losses will be environment-specific. However, in general, the fewer applications started by the Portal server during startup, the quicker the Portal server startup time should be.

Customizing the Portlet Unavailable message

Question How can you provide a different error message than Portlet Unavailable, based upon the portlet involved?

Answer

You have a few options to customize the Portlet Unavailable message. First, look at one of your skins, such as the following one: \WebSphere\profiles\wp_profile\installedApps\wpsbvt\wps.ear\wps.war\skins\html\IBM In that location is the control.jsp file that calls the portlet to render with the following tag: Therefore, the body of the tag is only rendered if the portlet has a problem. The program uses a key passed by the portal engine to determine what value to pull from the resource bundle. More information on the problem format tag can be found in the Information Center topic " tags." So, you could create a new skin for your specific portlets and enter your own custom text there. Or you can use the fmt tags and pull a different key from the regular text bundle. All of these resource bundles are stored in the wp.ui.jar file in the portalserver/shared/app directory. For the English language, you use the problem_en.properties file. In that file, you see the following line: portlet.not.available = This portlet is unavailable. You can change that text to whatever you wish. Note that the text you enter will be the same for every portlet that is unavailable. If you want only the Web Content Management (WCM) portlets to return a different message, you need to replace this line: With something like the following: Then you add a line to the engine_en.properties file in wp.ui.jar like this: wcmproblem = The WCM portlet could not be rendered You would need to add a line like that to every language file for engine_XX.properties. You can also suppress the Portlet Unavailable error messages.

How to tell that search indexing has completed in IBM Web Content Management (WCM)

Question

As the system administrator of an IBM® Web Content Management (WCM), you are interested in learning if the product's search index can completed being processed. How does one verify that the search indexing has completed?

Answer

The WCM system's SystemOut.log and trace.log files can be used to indicate the status of the search index's state of completion. Search string Meaning IndexMaintainer.processPendingUpdates. Processed This entry in the WCM SystemOut.log indicates that the index maintainer task is completed. Example: [12/4/07 19:45:58:734 IST] 0000013e JCRCFLLoggerI I com.ibm.icm.ts.tss.JCRCFLLoggerImpl com.ibm.icm.ts.tss.app.IndexMaintainer.processPendingUpdates [java.lang.ThreadGroup[name=icmciWorkManager: icmjcrear,maxpri=10]] com.ibm.icm.ts.tss.app.IndexMaintainer.processPendingUpdates [java.lang.ThreadGroup[name=icmciWorkManager: icmjcrear,maxpri=10]]: - IndexMaintainer.processPendingUpdates. Processed 149 events for index: 1 Search string Meaning IndexMaintainer.runIndexMaintenance() (*** no pending updates***) This entry in the WCM trace.log indicates that there are no events needing to be processed. **Note:** This output written to the trace.log requires that the following configuration be enabled: com.ibm.icm.ts.*=finest