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.

  1. When a client requests a protected resource without credentials, SiteMinder responds to the request with an HTTP response 401 (Authorization required).
  2. This response makes the browser challenge the user to provide a user name and password.
  3. 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.
  4. The Web server, in turn, forwards the request to Application Server.
    Figure 1. Using SiteMinder for authentication with WebSphere
    WebSphere and Netegrity Architecture Overview
    WebSphere and Netegrity Architecture Overview

    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.
  5. 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.
  6. After the TAI has successfully checked the credentials, Application Server generates the LTPA token for the current session.
  7. 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:

  1. Ensure all the latest fixpacks and e-fixes have been applied to WebSphere. See for the latest fixes.
  2. 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 zip file, as directed by the SiteMinder installation manual, into the web agent installation directory.
  3. 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.
    Edit the file (for AIX) located at <was_home>/bin, and add the following lines:
    export LIBPATH

    Make sure that the smjavaagentapi.jar (from the Netegrity SDK) has the same permissions as the wpstai.jar.
  4. Install the TAI class into <WAS_ROOT>/classes.
  5. Enter the property name and value pairs for SiteMinder, by editing the file in the <was_home>/properties directory 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 file.
  6. In the file (which is also in the <was_home>/properties directory), 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 file for information on additional attributes.
    # This is IP address of the policy server 
  7. Launch the WebSphere Administration Console and select Security Center from the console menu.
  8. 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
    WebSphere Application Server Security Console
    WebSphere Application Server Security Console
  9. Restart WebSphere Application Server.

Session validation

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:

  1. 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.
  2. Install the Netegrity libraries through which the TAI communicates with the agent. For example, on Solaris, copy and, provided in the Netegrity SDK, to <WAS_ROOT>/bin. The libraries contain the functions to log onto the Policy Server.
  3. Set validateSessions in the file 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 BadUrlChars in the SiteMinder agent.

  1. 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.
  2. On the left hand menu, select Agent Conf Object.
  3. 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
    SiteMinder 5.5 Adminsitration console
    SiteMinder 5.5 Adminsitration console
  4. 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
    Editing the SiteMinder 5.5 Agent Configuration properties
    Editing the SiteMinder 5.5 Agent Configuration properties
  5. Click Edit. Remove the /. entry from the list and click Apply.
  6. While still in the Netegrity SiteMinder Policy Server Admin Console, from the main menu select Tools, and then select Manage Cache.
  7. Click Flush All to make sure that the changes you made are replicated.
  8. Stop and restart the IBM HTTP Server on the machine on which SiteMinder is installed.
  9. 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 <WAS_ROOT>/bin directory.
  10. Regenerate the WebServer plugin.
  11. 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
SiteMinder authentication prompt to WebSphere Portal
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
Handling Portal Server requests for URLS
Handling Portal Server requests for URLS

There are 2 workarounds:

  1. 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.
  2. 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.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

ArticleTitle=Using Netegrity SiteMinder Authentication for WebSphere Portal