Configuring SSO for TRIRIGA on traditional WebSphere with IIS and AD

There are several steps for configuring single sign-on (SSO) with traditional WebSphere® Application Server, Microsoft Internet Information Services (IIS), and Microsoft Active Directory (AD).

Contents

I. Installing WebSphere Application Server web server plug-in on IIS

Install the WebSphere Application Server web server plug-ins. The plug-ins are available in 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-ins.

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).

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 IIS to pass web requests to WebSphere Application Server

About this task

If you are using an already installed web server plug-in on the web server, reconfigure it to use the web server plug-in by using the following procedure.

Note: If the web server plug-in is not installed, then install it, but do not use the following procedure since it is completed automatically during web server plug-in installation. You need to complete the steps below only if you are reconfiguring IIS Version 8.x to use an existing web server plug-in.

Procedure

  1. On the Server Manager screen, click Tools > Internet Information Services (IIS) Manager. This action starts the IIS application, and creates a new virtual directory for the website instance that you intend to use with WebSphere Application Server. These instructions assume that you are using the default website.
  2. Expand the tree until you see Default Web Site.
  3. Right-click Default Web Site and select Add Virtual Directory to create the directory with a default installation.
  4. On the Virtual Directory Alias window, enter sePlugins in the Alias field.
  5. In the Physical Path field of the Web Site Content Directory window, browse to and select the plugins_root\bin\IIS_web_server_name directory and click OK. For example, select C:\Program Files\IBM\WebSphere\Plugins\bin\IIS_webserver1.
  6. Click Test Settings. If the settings test fails, then either change the permissions of the physical directory, or select Connect As, and let IIS connect as a Windows user account that has authority to files in that physical path.
    Attention: When you click Test Settings, you might encounter the following warning message if you use the default Pass-thru authentication setting: "Cannot verify access to path". For more information, see the Microsoft documentation on this subject.
  7. Click OK to add the sePlugins virtual directory to your default website.
  8. In the navigation tree, select the sePlugins virtual directory that you created.
  9. On the Features panel, double-click Handler Mappings, and then click Edit Feature Permissions on the Actions panel.
  10. Select Script and Execute, if they are not already selected then click OK.
  11. Manually copy the plug-in binaries to the plugins_root\bin\IIS_web_server_name directory. For example, copy the plug-in binary files to the C:\Program Files\IBM\WebSphere\Plugins\bin\IIS_webserver1 directory.
    Note: The plugin-cfg.loc file resides in this directory. The first line of the plugin-cfg.loc file identifies the location of the plugin-cfg.xml file.
  12. Return to the IIS Manager window, and expand the Web Sites folder in the left-hand navigation tree of that window.
  13. Select Default Web Site in the navigation tree.
  14. Add the Internet Services Application Programming Interface (ISAPI) filter into the IIS configuration.
  15. On the Default Web Site Properties panel, complete the following steps.
    1. Double-click the ISAPI Filters tab.
    2. Click to open the Add/Edit Filter Properties dialog.
    3. Enter iisWASPlugin in the Filter name field.
    4. Click Browse to select the plug-in file that is located in the plugins_root\bin\IIS_web_server_name\iisWASPlugin_http.dll directory.
    5. Click OK to close the Add/Edit Filter Properties dialog.
  16. In the navigation tree, select the top level server node.
  17. On the Features panel, double-click ISAPI and CGI Restrictions, and then, on the Actions panel, click Add.
  18. To determine the value to specify for the ISAPI or CGI Path property, browse to and select the same plug-in file that you selected in the previous step. For example, plugins_root\bin\IIS_web_server_name\iisWASPlugin_http.dll.
  19. Enter WASPlugin in the Description field, select Allow extension path to execute, and click OK to close the ISAPI and CGI Restrictions dialog.
  20. Set the value in the plugin-cfg.loc file to the location of the configuration file at plugins_root \config\webserver_name\plugin-cfg.xml.
    • The default location of plugin-cfg.xml is C:\Program Files\IBM\WebSphere\Plugins\config\IIS_webserver1\plugin-cfg.xml. The location varies depending on how you have configured your system. If the web server and WebSphere Application Server are on separate machines, you have a remote installation.
    • If the web server and WebSphere Application Server are on the same machine, then you have a local installation, and the correct location of the configuration file might be set. For example, C:\IBM\WebSphere\Plugins\config\webserver1\plugin-cfg.xml.
    • If the two servers are on the same machine, and the application server is federated, you have a local distributed installation. For example, C:\IBM\WebSphere\AppServer\profiles\custom01\config\cells\dmgrcell\nodes\managed_node\servers \webserver1\plugin-cfg.xml.

IV. Configuring SSO with Microsoft IIS

About this task

After configuring IIS to pass web requests to WebSphere, the next step is to set up SSO.

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

    If AD contains usernames with inconsistent cases (for example, if TRIRIGA users have been entered in lower case, and users in AD are in mixed cases), use the following setting to turn off the case-sensitive check upon login:

    USERNAME_CASE_SENSITIVE=N 

    If you want to force users to log in through SSO, you must prevent them from using the default login page. Provide an alternative login page that does not contain a username, password, or login button. Use the following settings to specify the alternative login page and directory:

    ALTERNATE_INDEX_HTML=<indexFileName.html>
    ALTERNATE_RESOURCE_DIRECTORY=/<pathToTRIRIGA>/userfiles/alt
  2. Restart the application server to use the new settings.
  3. On the IIS server, right-click My Computer and select Manage.
  4. Expand Services and Applications. Select and expand Internet Information Services (IIS) Manager.
  5. Under IIS, expand Web Sites.
  6. Right-click Default Web Site and select Properties.
  7. In the Default Web Site Properties panel, select the Directory Security tab. In Authentication and access control, click Edit.
  8. In the Authentication Methods panel, uncheck the box next to Enable anonymous access.
  9. Select the type of authentication. If you do not know which one to set, do not choose all three. Try checking one at a time, restarting IIS after the change, and testing to see if the setting works correctly. The correct setting depends on your company's security setup.
    • Integrated Windows authentication
    • Digest authentication for Windows domain servers
    • Basic authentication (password is sent in clear text)
  10. Enter the domain name in Default Domain and Realm. The fields that are available depend on the check boxes selected in Authenticated access.
  11. Click OK.
  12. Restart IIS and make sure that the application server has been restarted.
  13. Make sure you have a login within TRIRIGA that matches your domain login. If your domain login is john.doe, the user name in the profile of the TRIRIGA Employee record should be john.doe.
    Note: Logins are case-sensitive. Some logins in Active Directory are stored in mixed case.
  14. Open your browser to http://<<webserver>>/. It should take you directly to TRIRIGA.