Configuring SSO for TRIRIGA on traditional WebSphere with IHS and TDS

I. Setting up IBM HTTP Server and WebSphere Application Server web server plug-in

Two things are required to have IBM HTTP Server working with WebSphere Application Server: (1) the IBM HTTP Server itself and (2) the WebSphere Application Server web server plug-in. The WebSphere Application Server package includes the IBM HTTP Server and the web server plug-in. Or you can obtain the plug-in from the Supplements package for WebSphere Application Server on Passport Advantage. As with the WebSphere Application Server installation, you use the IBM Installation Manager to install the web server plug-in.

For details on obtaining the Supplements package from Passport Advantage, see: Part numbers of WebSphere software used by IBM TRIRIGA (http://www-01.ibm.com/support/docview.wss?uid=swg21692375).

Use the following notes for guidance with the IBM HTTP Server installation:
  • Install as a root user.
  • IBM HTTP Server installation instructions can be found in the installation folder (readme > InstallGuide).
    Note: The installer requires X Window System.
  • The web server plug-in installation is part of the IBM HTTP Server installation. Do not forget to install the plug-in.
  • The installation path is usually: /opt/IBM/HTTPServer.
  • After you finish installing IBM HTTP Server, configure the administrative server in: /opt/IBM/HTTPServer/conf/admin.conf.
    # Port used to access the Administration Server
    Listen @LISTENINGPORT@
    # Default user and group settings for the server
    User @USER@
    Group @GROUPNAME@
    # ServerName gives the name and port that the server uses to identify
    # itself. This can often be determined automatically, but
    # specifying it explicitly can prevent problems during startup.
    #
    # If this is not set to a valid DNS name for your host, server-generated
    # redirections do not work. See also the UseCanonicalName directive.
    #
    # If your host does not have a registered DNS name, enter its IP
    # address. You must access it by its address anyway, and this makes
    # redirections work correctly.
    #
    ServerName hostname:@@AdminPort@@
  • Set the IBM HTTP Server administrator password.
    Note: If the administrator password does not exist, you must first run htpasswd with the -c option to create the password.
    1. Switch to the HTTPServer_installdir/bin directory on your machine.
    2. To set the administrator password, enter the following command based on your operating system:
      • In AIX, Linux, or Solaris, enter: ./htpasswd -b ../conf/admin.passwd user password.
      • In Windows, enter: htpasswd -b conf\admin.passwd user password.
  • After the IBM HTTP Server installation is completed, start the web server administration server by using the following commands:
    <ibm_HTTP_server_path>/bin/adminctl start
    <ibm_HTTP_server_path>/bin/apachectl start

II. Configuring traditional WebSphere property trustedSensitiveHeaderOrigin

There was a change on traditional WAS 9.0.0.11 that added a new configuration property named trustedSensitiveHeaderOrigin.

See reference: Potential WebSphere Application Server problems when deployed behind a WebSphere-aware proxy server

On traditional WebSphere, the property is configured as an HTTP channel custom property. This property has a default value of "none", which means that a subset of WebSphere-specific HTTP headers will not be trusted from any host. The property also accepts value a of "*" (all), or a comma-separated list of IP addresses. For a secure deployment in which proxy servers are used, the trustedSensitiveHeaderOrigin property should be configured with a comma-separated list of IP addresses corresponding to those of any WebSphere-aware proxy servers in front of the WebSphere server.

Alternatively, to enable the original unsecured behavior, set trustedSensitiveHeaderOrigin="*", which will direct the WebSphere server to trust all headers sent from any host or proxy. This value must only be used for testing, or if the WebSphere server is isolated from external connections.

For traditional WAS, set trustedSensitiveHeaderOrigin as a custom property of HTTP channel.

See reference: HTTP transport channel custom properties

III. Configuring IHS to pass web requests to WebSphere Application Server

About this task

After you install IBM HTTP Server, you configure it to forward requests to the application server.

The following steps demonstrate how to configure the web server by using the WebSphere Customization Toolbox.

Procedure

  1. Start the WebSphere Customization Toolbox.
  2. In the Web Server Plug-in Configuration box, select Create.
  3. In the Web Server Selection window, select IBM HTTP Server.
  4. In the Web Server Configuration File Selection dialog, select the existing IBM HTTP Server httpd.conf file and port.
  5. Optionally, in the Setup IBM HTTP Server Administration Server dialog, configure an administrative server to administer the web server and create an administrative user ID and password.
  6. Optionally, set up the IBM HTTP Server Administration Server as a Windows Service.
  7. In the Web Server Definition Name dialog, specify a unique web server definition, such as the default webserver1.
  8. In the Configuration Scenario Selection dialog, specify the location of the application server. If your configuration scenario is local, browse to the location of the \AppServer folder. For example, a common location for the application server is C:\Program Files (x86)\IBM\WebSphere\AppServer.
  9. In the WebSphere Application Server Profile Selection dialog, select the WebSphere Application Server profile to configure with the current web server plug-in. For example, AppSrv01.
  10. In the Plug-in Configuration Summary dialog, review the items you chose and select Configure.

IV. Configuring SSO with IBM HTTP Server

About this task

After you configure IBM HTTP Server to forward web requests to WebSphere Application Server, you set up SSO with IBM HTTP Server.

Procedure

  1. On the application server, set the following attributes in the TRIRIGAWEB.properties file. This file should be located in the Tririga/config folder.
    SSO=Y
    SSO_REMOTE_USER=Y
    SSO_REMOVE_DOMAIN_NAME=Y
    SSO_REQUEST_ATTRIBUTE_NAME=sm_user
  2. Configure IBM HTTP Server to use LDAP by editing the httpd.conf.
    1. Activate the LDAP module by adding the following line:
      • LoadModule ibm_ldap_module modules/mod_ibm_ldap.dll
      • On Unix operating systems, the module name will be different:
      • LoadModule ibm_ldap_module modules/mod_ibm_ldap.so
    2. Define the Location. Here is an example:
      <Location "/">
         LdapConfigFile "/opt/IBM/HTTPServer/conf/ldap.prop"
         AuthName "Directory server"
         AuthType Basic
         Require valid-user
      </Location>
    3. Definitions:
      • Location: Defines a scope for the action. In this case, we are authenticating against the scope of the web application.
      • LdapConfigFile "/opt/IBM/HTTPServer/conf/ldap.prop": Defines the path to your LDAP configuration file.
      • AuthName "Directory server": Defines the text that appears in the popup which prompts the user for their login and password.
      • AuthType Basic: Defines that Basic is being used as the authentication method. The login and password are encoded and included in the headers of each request sent by the browser.
      • Require valid-user: Defines which users can access the resources. In this case, any authenticated user has access. It is possible to define a list of user names or groups. See the next step.
  3. Configure the LDAP settings by editing the ldap.prop file.

    Below is an example of a minimal configuration file for a TDS server over SSL.

    An ldap.prop.sample file is available in the conf directory of IHS that you can rename to ldap.prop and customize for you environment. This file contains other options as well as explanations regarding the possible values of these configuration options.

    Make sure each line reflects your configuration. For example, for ldap.URL, substitute tdsserver.company.com with the name of your directory server, as well as the port (sslport), organizational unit (ou), organization (o), etc. Make sure to update the path to the keyfile and stash file.

    ldap.realm=ldaprealm
    ldap.URL=ldap://tdsserver.company.com:sslport/ou=organization,o=company.com?mail
    ldap.group.URL=ldap://tdsserver:sslport/ou=groups,o=company.com
    ldap.transport=SSL
    ldap.application.authType=none
    ldap.user.authType=BasicIfNoCert
    ldap.user.name.filter=(&(objectclass=person)(mail=%v1))
    ldap.user.cert.filter=(&(objectclass=person)(cn=%v1))
    ldap.group.name.filter=(&(cn=%v1)(|(objectclass=groupofnames)(objectclass=groupofuniquenames)))
    ldap.group.memberAttributes=member uniquemember
    ldap.idleConnection.timeout=600
    ldap.waitToRetryConnection.interval=300
    ldap.search.timeout=10
    ldap.cache.timeout=0
    ldap.key.fileName= /opt/IBM/HTTPServer/tds-onlysigners.kdb
    ldap.key.file.password.stashFile= /opt/IBM/HTTPServer/tds-onlysigners.sth
    ldap.group.search.depth=3
  4. Create a key database.

    Since we use an SSL transport channel, this means that we need to have a keystore, a stash file, and likely, some signer certificates in that keystore.

    1. Open iKeyman and create a new key database file with the same name as the one defined in the LDAP configuration file. Make sure the path is accurate for your environment. For details on using iKeyman, see Using iKeyman to create a key database file.
    2. Define the password and select "Stash the password to a file."
    3. Select the Signer Certificates option in the dropdown list and click Populate.
    4. Select the CA Certificates that you need. Make sure you have the correct signer certificates.
    5. Click OK. The certificates will be added to your database key file. Close iKeyman.
  5. Use the ldapstash command to create an LDAP stash file, containing the password for the key database file.

    IHS provides a small executable named ldapstash.exe that can create the stash file.

    Usage: ldapstash <password> <file>

    ldapstash.exe WebAS /opt/IBM/HTTPServer/tds-onlysigners.sth
  6. Restart IBM HTTP Server. You can restart the server from the WebSphere Application Server administrative console.
  7. In the WebSphere Application Server administrative console, select Security > Global Security. Under Application security, make sure that "Enable application security" is not selected. If you make any changes, restart WebSphere Application Server.
  8. Access the TRIRIGA SSO URL in your browser. For example, http://localhost.
  9. You should get prompted for a login and password. Enter your TDS server login and password. You should be authenticated.

V. Configuring SSO without SSL

About this task

If you want to set up your SSO environment without SSL, make the changes below.

Attention: These settings are not recommended for a production server. But they can be useful for a testing environment.

Procedure

  1. Three lines in the ldap.prop file need to be changed for a non-SSL environment as compared to the LDAP configuration with SSL:
    ldap.URL=ldap://tdsserver.company.com/ou=organization,o=company.com?mail
    ldap.group.URL=ldap://tdsserver.company.com/ou=groups,o=company.com
    ldap.transport=TCP
    1. You need to change the ldap.URL from ldap://tdsserver.company.com:sslport (636 is the SSL port for LDAP) to ldap://tdsserver.company.com.
    2. You also need to change the ldap.transport to use TCP instead of SSL.
  2. Comment out these properties:
    ldap.key.fileName=/opt/IBM/HTTPServer/tds-onlysigners.kdb
    ldap.key.file.password.stashFile=/opt/IBM/HTTPServer/tds-onlysigners.sth
    ldap.application.password.stashFile