After you have installed the IBM WebSphere Portal Server 6.0 agent and you have performed the post-installation steps that apply to all J2EE agents in the Policy Agent 2.2 release, complete the following agent-specific tasks:
Adding an Access Manager Trust Association Interceptor to IBM WebSphere Portal Server 6.0
Changing the Logout Link Actions for IBM WebSphere Portal Server 6.0
Adding the Agent Filter to the IBM WebSphere Application Server 6.0 Administration Console
Adding the Agent Filter to the IBM WebSphere Portal Server 6.0 Application
This task allows the agent to establish single sign-on (SSO) with the protected IBM WebSphere Portal Server 6.0 instance.
This task must be performed once per IBM WebSphere Application Server node regardless of how many IBM WebSphere Application Server instances exist within that node.
Ensure that all instances of the underlying IBM WebSphere Application Server are stopped.
Start the Administration instance of IBM WebSphere Application Server on which the Administration Console is deployed.
Typically this instance is named server1.
Log in to the IBM WebSphere Portal Server 6.0 Administration Console.
Navigate to the Interceptors page.
Click New.
Name the new Trust Association Interceptor with the following class name:
com.sun.identity.agents.websphere.AmTrustAssociationInterceptor
Click Apply.
A new page opens.
Save the changes:
Navigate again to the Interceptors page.
The navigation steps are explained at the beginning of this task description.
Check the Trust Association Enabled checkbox.
Click OK.
Save and apply changes to the Master configuration.
Restart all server instances as necessary, including the instance on which IBM WebSphere Portal Server 6.0 is deployed.
The Policy Agent Trust Association Interceptor is now installed.
You can change the Logout actions within IBM WebSphere Portal Server 6.0 to provide a seamless user experience with single sign-on (SSO) using Access Manager.
Ensure that the IBM WebSphere Application Server and IBM WebSphere Portal Server 6.0 instances are running.
Backup the following file:
WPS-base/PortalServer/config/properties/ConfigService.properties
where WPS-base represents the directory where IBM WebSphere Portal Server 6.0 was installed.
Modify the WPS-base/PortalServer/config/properties/ConfigService.properties file as follows:
Set redirect.logout to true.
Set redirect.logout.ssl to true or false, depending upon the environment.
Set redirect.logout.url to the Access Manager logout URL (AMlogout-URL).
where AMlogout-URL represents the Access Manager logout URL. For example:
http://amhost.domain.com:AMport/amserver/UI/Logout |
where AMport represents the port number of the Access Manager host.
Important: Remove the comment sign (#) from the above changed lines and then save the file.
Run the following portal configuration task:
WPS-base/PortalServer/config/WPSconfig.sh update-properties |
If you are running WebSphere Portal Server in a cluster, replicate your changes to the cluster.
Restart the IBM WebSphere Portal Server 6.0 instance for these changes to take effect.
This required task more tightly integrates the IBM WebSphere Application Server 6.0 Administration Console with the Access Manager environment. This task is required only once for the IBM WebSphere Application Server 6.0 Administration instance (typically server1) where the Administration Console is installed.
The IBM WebSphere Portal Server 6.0 agent provides a servlet filter that can be added to the IBM WebSphere Application Server 6.0 Administration Console. This filter allows the enforcement of coarse grained URL policies defined within Access Manager to further control the access to protected resources on the IBM WebSphere Administration Console. The following steps detail how this filter can be installed.
Ensure that the Administration instance of IBM WebSphere Application Server is stopped.
Locate the adminconsole/WEB-INF/web.xml file, which contains the deployment descriptors for the IBM WebSphere 6.0 Administration Console.
The path to this web.xml file is:
WAS-base/AppServer/systemApps/adminconsole.ear/adminconsole.war/WEB-INF/
where WAS-base represents the directory where IBM WebSphere Application Server 6.0 was installed.
Backup the web.xml file.
Because you will modify the deployment descriptor in the next step, creating a backup file at this point is important, especially if you need to uninstall the agent in the future.
Edit the web.xml file, as follows:
<display-name>adminconsole</display-name> <filter id="Filter_PolicyAgent"> <filter-name>Policy Agent</filter-name> <filter-class> com.sun.identity.agents.filter.AmAgentFilter </filter-class> </filter> ... //other filter definitions <filter-mapping id="FilterMapping_PolicyAgent"> <filter-name>Policy Agent</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> ... //other filter mappings </web-app>
This required task integrates the IBM WebSphere Portal Server 6.0 instance with the Access Manager environment.
This task is required only once per IBM WebSphere Portal Server 6.0 instance for a given host.
The IBM WebSphere Portal Server 6.0 agent provides a servlet filter that can be added to the IBM WebSphere Portal Server 6.0 application. This filter allows the enforcement of coarse grained URL policies defined within Access Manager to further control the access to protected resources on the IBM WebSphere Portal Server 6.0 instance. The filter can also be configured to provide additional personalization information in the form of HTTP Headers, cookies, or HTTP Request Attributes that can be used to further enhance the functionality of protected components. The following steps detail how this filter can be installed.
Ensure that the portal instance of IBM WebSphere Application Server on which the WebSphere Application Portal 6.0 instance is deployed is stopped.
Locate the wps.war/WEB-INF/web.xml file, which contains the deployment descriptors for IBM WebSphere Portal Server 6.0.
The IBM WebSphere Application Server can read this file at runtime from either of the following directories:
WAS-base/AppServer/profiles/wp_profile/installedApps/ Cell-Name/wps.ear/wps.war/WEB-INF
WAS-base/AppServer/profiles/wp_profile/config/cells/ Cell-Name/applications/wps.ear/deployments/wps/wps.war/WEB-INF
where:
WAS-base represents the directory where IBM WebSphere Application Server 6.0 was installed.
Cell-Name represents the IBM WebSphere Application Server 6.0 cell protected by the agent.
Backup the two web.xml files before modifying the deployment descriptors.
Since you will modify the deployment descriptor in the next step, creating backup files at this point is important, especially if you need to uninstall the agent in the future.
Edit both of the web.xml files referred to in this task, as follows:
<display-name>WebSphere Portal Server</display-name> <filter id="Filter_PolicyAgent"> <filter-name>Policy Agent</filter-name> <filter-class> com.sun.identity.agents.filter.AmAgentFilter </filter-class> </filter> ... //other filter definitions <filter-mapping id="FilterMapping_PolicyAgent"> <filter-name>Policy Agent</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> ... //other filter mappings </web-app> |
When Websphere Portal Server 6.0 is installed, two administrative user IDs should have been created in the WebSphere Portal:
wasadmin is the administrative user ID for WebSphere Application Server.
and
wpsadmin is the administrative user ID for WebSphere Portal Server.
Therefore, you should create the same user IDs, wasadmin and wpsadmin, in Access Manager. These names are used to authenticate to Access Manager and to access the WebSphere Administration Console and WebSphere Portal Server as the respective administrator after the agents are installed and configured.