Using Netegrity SiteMinder Authentication for WebSphere Portal
Many enterprise IT environments use Netegrity© SiteMinder© (hereafter called SiteMinder) to secure Web applications and servers. Naturally, when customers decide to move to IBM© WebSphere© Portal (hereafter called WebSphere Portal), they want to continue to use SiteMinder for their existing Web environment, and also as the authentication mechanism for their portal.
This article describes how to configure and customize authentication for WebSphere Application Server 4.x (hereafter called Application Server), and Websphere Portal 4.x, using SiteMinder as the authentication engine. The reader should be familiar with WebSphere Portal, Application Server, and SiteMinder administration . This article assumes that you already have installed SiteMinder and WebSphere Portal, and that they are working properly.
Using Netegrity SiteMinder with WebSphere
Figure 1 shows the general architecture for integrating WebSphere and Netegrity SiteMinder for authentication.
- When a client requests a protected resource without credentials, SiteMinder responds to the request with an HTTP response 401 (Authorization required).
- This response makes the browser challenge the user to provide a user name and password.
- After the user enters his or her credentials, the browser requests the resource again using these credentials, and SiteMinder forwards the request, including the credentials, to the Web server.
The Web server, in turn, forwards the request to Application Server.
Figure 1. Using SiteMinder for authentication with WebSphere
If you configure Application Server to enable trust associations, it will accept requests with credentials from trusted servers and not require the request to be authenticated again. You must install a Trust Association Interceptor (TAI) to handle requests from the trusted server. Netegrity SiteMinder provids a TAI.
- If you have configured WebSphere Application Server to not directly accept credentials provided by Netegrity SiteMinder, it will check the credentials with the Netegrity Policy Server before creating the LTPA token. You learn more about configuring security in this way below, in Session validation.
- After the TAI has successfully checked the credentials, Application Server generates the LTPA token for the current session.
- Finally, the LTPA token is stored as a cookie on the client and the requested resource is returned to the client.
Enabling a TAI in WebSphere
To enable trust association in WebSphere Application Server:
- Ensure all the latest fixpacks and e-fixes have been applied to WebSphere. See http://www.ibm.com/software/webservers/appserv/was/support/ for the latest fixes.
- Install the Netegrity web agent onto the WebSphere Portal Server's IBM HTTP server.
Depending on the platform, extract the web agent from the
tar or zipfile, as directed by the SiteMinder installation manual, into the web agent installation directory.
- Make sure that the Application Server running WebSphere Portal Server has the SiteMinder shared
libraries (for example,
/usr/netegrity/siteminder/webagent/lib) included in its path.
The library files are from the SiteMinder web agent that is installed on the IBM HTTP Server machine.
adminserver.shfile (for AIX) located at
<was_home>/bin, and add the following lines:
LIBPATH=$LIBPATH:/usr/netegrity/siteminder/webagent/lib export LIBPATH
Make sure that the
smjavaagentapi.jar(from the Netegrity SDK) has the same permissions as the
- Install the TAI class
- Enter the property name and value pairs for SiteMinder, by editing the
trustedservers.propertiesfile in the
<was_home>/propertiesdirectory and adding the following lines. Comment our (or delete) all other lines referencing other interceptors. See the WebSphere Portal V4.x InfoCenter for more information on the
com.ibm.websphere.security.trustassociation.enabled=true com.ibm.websphere.security.trustassociation.types=netegrity com.ibm.websphere.security.trustassociation.netegrity.interceptor= com.ibm.wps.sso.SiteMinderTrustAssociationInterceptor com.ibm.websphere.security.trustassociation.netegrity.config=siteminder
- In the
siteminder.propertiesfile (which is also in the
<was_home>/propertiesdirectory), add the IP address of the SiteMinder policy server and include the name of the Shared Secret (your SiteMinder administrator should know this). See the comments in the
siteminder.propertiesfile for information on additional attributes.
validateSessions=false SharedSecret=nsmtai # This is IP address of the policy server Servers=220.127.116.114
- Launch the WebSphere Administration Console and select Security Center from the console menu.
- In the Authentication tab, select Lightweight Third Party Authentication (LTPA) for the authentication
mechanism. Ensure the Enable Web Trust Association check box is checked, as
indicated in Figure 2.
Figure 2. WebSphere Application Server Security Console
- Restart WebSphere Application Server.
To increase security for authentication, you can configure WebSphere Application Server check credentials with the Netegrity Policy Server before creating the LTPA token. Configuring security in this way is known as session validation.
The TAI tries to log onto the Policy Server with the credentials provided by the SiteMinder Server. If the logon is successful, the LTPA token is generated.
To enable session validation:
- Configure an agent in the Netegrity Policy Server administration console. You do not need to specify any special rights or limitations. In this integration approach, the agent only checks whether the TAI can successfully log in with valid credentials.
- Install the Netegrity libraries through which the TAI communicates with the agent. For example, on Solaris,
libsmconapi.so, provided in the Netegrity SDK, to <WAS_ROOT>/bin. The libraries contain the functions to log onto the Policy Server.
- Set validateSessions in the
siteminder.propertiesfile to true, to configure the TAI to validate session credentials against the agent.
Handling WebSphere Portal URLs
Many of the URLs generated by WebSphere Portal include
/. and will not display in a browser, unless you remove
/. from the
in the SiteMinder agent.
- Open the Netegrity Siteminder Policy Server Administration console by opening this URL in your Web browser:
http://<policy-server>/siteminder/smadmin2.html. Login to the console.
- On the left hand menu, select Agent Conf Object.
Contact your SiteMinder administrator to find your agent name.
Double-click the name of the Policy Agent.
For example, in the example shown in Figure 3, the name is portalaixconfig.
Figure 3. SiteMinder Administration console
In the Agent Configuration Object window, search down the Parameter Name column and select BadUrlChars, as shown in Figure 4.
Figure 4. Editing the SiteMinder 5.5 Agent Configuration properties
Click Edit. Remove the
/.entry from the list and click Apply.
- While still in the Netegrity SiteMinder Policy Server Admin Console, from the main menu select Tools, and then select Manage Cache.
- Click Flush All to make sure that the changes you made are replicated.
- Stop and restart the IBM HTTP Server on the machine on which SiteMinder is installed.
The wpstai.jar is picked up by the ws.ext.dirs. Therefore, you need to add
/usr/netegrity/siteminder/webagent/bin/smjavaagentapi.jar(or whatever is appropriate for the environment setup) to the ws.ext.dirs variable in the admin.config file in the
- Regenerate the WebServer plugin.
- Stop and start the IBM HTTP server to ensure that all the changes take effect.
Verifying the configuration
To test your configuration, open the following URL in a Web browser:
You see a standard login screen as shown in Figure 5.
Figure 5. SiteMinder authentication prompt to WebSphere Portal
Enter a valid username and password. The WebSphere Portal homepage displays, by-passing the WPS login page.
Addressing secured resources through URLs
You may experience problems when WebSphere Portal Server addresses secured resources using URLs. For example, requests for graphics or configuration files for Click-to-Action may generate 401 HTTP responses. As shown in Figure 6, all WebSphere Portal Server requests must go through Netegrity SiteMinder, and therefore, they require credentials. However, WebSphere Portal does not, by default, provide credentials.
Figure 6. Handling requests for secured URLS
There are 2 workarounds:
- Use the credential vault of WebSphere Portal to provide credentials with each request. See Related information for sources to learn more about the credential vault.
- Configure the Netegrity Policy Server to allow access to resources from trusted servers (trusted zone).
Congratulations! You have now successfully configured Netegrity SiteMinder TAI with WebSphere Portal.
IBM WebSphere Portal Server 4.2 Info Center
Using Active Credentials Objects to Connect to Secured Web Applications
Using Credential Vault to Provide Single Sign-on for Portlets