5.4 Configuring TAM for authentication for WebSphere Portal Server

< Day Day Up >

Before continuing with the configuration steps for this task, it is necessary to ensure that the following installation tasks have been carried out:

On the Security Node

Installation of Access Manager Policy Server, Authorization Server and WebSEAL Server as per sections 4.5.1, "Installing Policy Server" on page 96 and 5.2.2, "Modifying LDAP Access Control" on page 120.

Before continuing with the configuration steps for this task, it is necessary to ensure that the following configuration tasks (together with all their prerequisite tasks) have been carried out:

On the Application Node

Configuration of WebSphere for SSL as per section 5.3, "Configuring WebSphere for SSL" on page 143.
On the Security Node

Configuration of WebSphere for SSL as per section 5.3, "Configuring WebSphere for SSL" on page 143.

5.4.1 Configuring the WebSEAL Key Ring Database

Copy the extracted certificate file (C:\program files\IBMHTTPServer\conf\ihs_ssl.arm) generated in "Creating an SSL certificate for the Web server" on page 143 from the Portal server to a secure temporary directory on the Access Manager server.

Select Start -> Run then browse to C:\Program Files\IBM\GSK5\bin (in our environment) and run the gsk5ikm.exe file. Choose Key Database File -> Open, click Browse and navigate to the C:\program files\tivoli\pdweb\www\certs directory. Select the pdsrv.kdb file and click Open. You will be prompted for the password. Type pdsrv and click OK.

Select Signer Certificates from the drop-down list and click the Add button. Ensure that the data type is set to Base64-encoded ASCII data. Click Browse and navigate to the temporary directory. Select the IHS_SSL.arm file copied previously. Click Open and OK. Enter the value IHS_SSL as the label for the certificate. The Key Database files signer certificates should look similar to the following.

click to expand
Figure 5-58: WebSEAL Key Database - Signer Certificates

Select Personal Certificates from the drop-down list. Click New self-signed. Type in the key label name WebSEAL-client, set the version to x509 v3, the key size to 1024, the common name to the fully qualified hostname, the organization to ibm.com and the country to US as shown in Figure 5-59 on page 185.

click to expand
Figure 5-59: New WebSEAL Self-signed certificate

Click OK. When prompted to set the key as the default key, select no. Highlight the WebSEAL-client certificate just created and click Extract Certificate. Ensure that the data type is set to Base64-encoded ASCII data. Type in WebSEAL-client.arm as the certificate file name. Click OK. Close the key file and exit the key management utility.

Use the Services application to restart the Access Manager WebSEAL Service. This will allow WebSEAL to read its updated key ring file.

5.4.2 Creating the WebSEAL junction

On the Security node, select Start -> Programs -> Access Manager for e-business -> Administration Command Prompt. At the pdadmin> prompt, type the command login. Enter the user ID sec_master. Type in the password sah309r (in our environment). Type in the command server list. Take note of the name of the WebSeald server (this includes the server hostname). Also note that m23x2896 is the ApplicationNodeHostName; m23x2896 is in our environment.

Example 5-4: PDAdmin commands showing WebSEAL server name

 pdadmin> login Enter User ID: sec_master Enter Password: pdadmin> server list     ivacld-m23caatk     webseald-m23caatk pdadmin>

Type in the command:

    server task webseald-hostname create -t ssl -h webserver_hostname -p 443 -j    -w -i -c all -K "WebSEAL-client" -D    "CN=ApplicationNodeHostname,O=ibm.com,C=US" /portal

M23x2896.itso.ral.ibm.com in the example below is the ApplicationNodeHostname above.

Example 5-5: Command to create the WebSEAL junction

 pdadmin> server task webseald-m23caatk create -t ssl -h m23x2896.itso.ral.ibm.com -p 443 -j -w -i -c all -K "WebSEAL-client" -D "CN=m23x2896.itso.ral.ibm.com,O= ibm,C=US" /portal Created junction at /portal pdadmin>

Note

The quotes surrounding the values specified for the -K and -D arguments are mandatory. The -D argument has to match whatever is stored in the certificate returned by the host specified to the -h argument. Note that the format might be different according to what is in the certificate. For example, a Lotus Domino-based certificate might have an entry like:

    "/C=US/O=ibm.com/CN=m23x2672.itso.ral.ibm.com"

You now need to edit the webseald.conf file as follows:

    {forms}    #--------------------------    #Forms    #--------------------------    #Enable authentication using forms    #One of <http, https, both, none>    forms-auth = https    ba-auth = none

This step forces WebSEAL to use forms instead of basic authentication for its authentication challenge to the user. With basic authentication, the user would need to close his/her browser in order to log out. Since we have changed this to forms, we will be able to make Portal's default logout button work to log out the user.

Restart WebSEAL to enable this configuration change.

5.4.3 Importing WebSphere Portal users and groups

Note that although the users and groups used by WebSphere Portal have been already created in the LDAP directory, Tivoli Access Manager does not have entries for them in its own database. To import the WebSphere Portal users and groups into Tivoli Access Manager, you have to enter the following commands on the Tivoli Access Manager pdadmin command line, where <wpsadmin> is the user ID for the portal administrator and <wpsadmins> is the portal administrator's group name.

    user import <wpsadmin> uid=<wpsadmin>,cn=users,dc=ibm,dc=com    user modify <wpsadmin> account-valid yes    group import <wpsadmins> cn=<wpsadmins>,cn=groups,dc=ibm,dc=com

You can test the results of these commands with the user list and group list commands as shown in Example 5-6. Please note that dc=ibm,dc=com is specific to our environment.

Example 5-6: PDAdmin Import commands

 pdadmin> user import wpsadmin uid=wpsadmin,cn=users,dc=ibm,dc=com pdadmin> user modify wpsadmin account-valid yes pdadmin> group import wpsadmins cn=wpsadmins,cn=groups,dc=ibm,dc=com pdadmin> user list * 100 wpsadmin sec_master ivmgrd/master ivacld/m23caatk webseald/m23caatk pdadmin> group list * 100 iv-admin webseal-servers secmgrd-servers su-excluded remote-acl-users ivacld-servers webseal-mpa-servers ivmgrd-servers securitygroup su-admins wpsadmins pdadmin>

5.4.4 Enabling Trust Association Interceptor

One the Application Node, use the WebSphere Application Server Administrative Console to enable the Trust Association Interceptor.

In the WebSphere Application Server Administrative Console, click Security -> Authentication Mechanisms -> LTPA. Click Trust Association under Additional Properties. Select the Trust Association Enabled check box. Click Apply.

click to expand
Figure 5-60: Enable Trust Association

Click Interceptors under Additional Properties. Click com.ibm.ws.security.web.WebSealTrustAssociationInterceptor. Click Custom Properties under Additional Properties.

Click New and enter the General Properties name and value pairs specified below. Click OK after entering each name and value. The values below work for this environment. For more information on the possible values that these properties might have, please refer to the WebSphere Portal InfoCenter.

Table 5-2: Custom properties for WebSEAL Trust Association Interceptor
Name	Value
com.ibm.websphere.security.trustassociation.types	webseal
com.ibm.websphere.security.webseal.id	iv-user
com.ibm.websphere.security.webseal.hostnames	security node hostname (m23caatk, in our environment)
com.ibm.websphere.security.webseal.ports	443
com.ibm.websphere.security.webseal.ignoreProxy	false
com.ibm.websphere.security.webseal.mutualSSL	true

After you have created all these properties, the Custom Properties should look as shown in Figure 5-61 on page 190.

click to expand
Figure 5-61: Trust Association properties

Some friendly advice: check and double-check the names and values of all the Custom properties before saving the configuration changes.

Save these configuration changes and restart the WebSphere_ Portal server.

5.4.5 Verifying Trust Association Interceptor operation

Use this address to test the Trust Association Interceptor from a Web browser:

https://<WebSEAL_hostname>/portal/wps/myportal

WebSEAL should challenge you to authenticate. Once you log in as wpsadmin, you should be directed to the user's secure and personalized myportal page.

click to expand
Figure 5-62: TAI test

If you are directed to the portal login screen at wps/portal/.scr/Login or the public page, there is a problem with the Trust Association Interceptor configuration. Currently, the login and logout links will not function properly until you carry out the steps detailed in 5.4.7, "Changing Portal Logout and Login pages" on page 196.

At the moment, the Portal Signup link will only add a user to the LDAP directory and not to the Tivoli Access Manager User Repository. This link will have to be disabled. From now on, a user will have to be created within Access Manager (using pdadmin or the Web Portal Manager or the Access Manager Self-Registration application). To further test the TAI, we will create a new user (any random user); to do so, execute the following command from the pdadmin console on the Access Manager server after you have logged in as sec_master:

    user create <user_name> <user_dn> <common name> <surname> <password>    user create andrew uid=andrew,cn=users,dc=ibm,dc=com "Andrew"    "Hatzikyriacos" "passw0rd"    user modify andrew account-valid yes

Tip

The user password chosen has to conform to the Access Manager password policy. It requires a minimum length of eight characters formed by at least four alphabetical characters and one non-alphabetical character with no more than two repeated characters. Password policy can be changed on a user base or global base. For information, refer to the IBM Tivoli Access Manager 4.1 Base Administration Guide.

Log in to the portal site using this newly created user. To verify it, go to Edit my profile and you will see the user ID used to log in.

click to expand
Figure 5-63: Newly created user in TAM accessing WebSphere Portal - Edit my profile page

If you are not having problems completing this section successfully, please skip to section 5.4.7, "Changing Portal Logout and Login pages" on page 196.

5.4.6 Tracing Trust Association

To find out the cause of your problem, you will have to enable tracing. In the WebSphere Administrative Console, go to Troubleshooting-Logs and Traces.

Click WebSphere_Portal. Click Diagnostic Trace. Make sure that the Enable Trace checkbox is checked and change the Trace Specification to:

    com.ibm.ws.security.web.*=all=enabled:

Confirm that the location of the Trace Output Filename is:

    ${SERVER_LOG_ROOT}/trace.log

Click OK, save the changes and restart the application server. Once the server is restarted with the new settings, you will find a trace.log file in your server's log directory (C:\program files\websphere\portal\log).

Example 5-7: Trace of successful TAI initialization

 TrustAssociat > initialize TrustAssociat d Trust Association enabled: Trying to load the interceptors TrustAssociat A SECJ0121I: Trust Association Init class com.ibm.ws.security.web.WebSealTrustAssociationInterceptor loaded successfully TrustAssociat d Trust Properties= {com.ibm.websphere.security.trustassociation.types=webseal, com.ibm.websphere.security.webseal.ignoreProxy=false, com.ibm.websphere.security.webseal.ports=443, com.ibm.websphere.security.webseal.hostnames=m23caatk, m23caatk.itso.ral.ibm.com, com.ibm.websphere.security.webseal.id=iv-user, com.ibm.websphere.security.webseal.mutualSSL=true} WebSealTrustA > Initializing WebSealTrustAssociationInterceptor... WebSealTrustA > getElements WebSealTrustA < getElements WebSealTrustA > getElements WebSealTrustA < getElements WebSealTrustA > getElements WebSealTrustA < getElements WebSealTrustA d WebSeal Login ID = null WebSealTrustA W SECJ0225W: PD Authentication disabled. WebSealTrustA > addASource WebSealTrustA d WebTAInterceptor: Added source = m23caatk:443 WebSealTrustA < Exiting addASource WebSealTrustA > addASource WebSealTrustA d WebTAInterceptor: Added source = m23caatk.itso.ral.ibm.com:443 WebSealTrustA < Exiting addASource WebSealTrustA d Ignore the proxy = false WebSealTrustA < Exiting initialization: SUCCESS TrustAssociat A SECJ0122I: Trust Association Init Interceptor signature: WebSeal Interceptor Version 1.1 TrustAssociat A SECJ0120I: Trust Association Init loaded 1 interceptor(s) TrustAssociat d Adding Interceptor: com.ibm.ws.security.web.WebSealTrustAssociationInterceptor TrustAssociat d Number of Interceptors added are: 1 TrustAssociat < initialize

The messages PD Authentication disabled and WebSeal Login ID = null are present because of the way we have configured the WebSEAL junction (in particular, because we have set the custom property mutualSSL=true). They are not an indication that the Trust Association Interceptor will not perform authentication.

Next, you will find an example of an error that might occur if the custom property .id is missing or the WebSEAL junction is passing through the correct headers (which is given by the -c argument in the WebSEAL junction create command).

Example 5-8: Trace of unsuccessful TAI call: missing WebSEAL ID

 WebAuthentica d handleTrustAssociation WebAuthentica d TrustAssociation is enabled. TrustAssociat > getInterceptor TrustAssociat d Check if target interceptor ... WebSealTrustA > getCheckID WebSealTrustA < getCheckID WebSealTrustA d There is no WebSeal ID. Hence, it is not via WebSeal. TrustAssociat < getInterceptor WebAuthentica < handleTrustAssociation: (null user)

The trace output found below demonstrates what occurs when the TAI is contacted by a host it does not trust or when you have set an incorrect value for the .hostnames custom property.

Example 5-9: Trace of unsuccessful TAI call: untrusted host connection

 WebAuthentica d handleTrustAssociation WebAuthentica d TrustAssociation is enabled. TrustAssociat > getInterceptor TrustAssociat d Check if target interceptor ... WebSealTrustA > getCheckID WebSealTrustA < getCheckID WebSealTrustA d isTargetInteceptor: header name=accept WebSealTrustA d isTargetInteceptor: header name=accept-encoding WebSealTrustA d isTargetInteceptor: header name=accept-language WebSealTrustA d isTargetInteceptor: header name=connection WebSealTrustA d isTargetInteceptor: header name=host WebSealTrustA d isTargetInteceptor: header name=iv-creds WebSealTrustA d isTargetInteceptor: header name=iv-groups WebSealTrustA d isTargetInteceptor: header name=iv-user WebSealTrustA d isTargetInteceptor: header name=user-agent WebSealTrustA d isTargetInteceptor: header name=via WebSealTrustA d isTargetInterceptor: VIA=HTTP/1.1 m23caatk:443 WebSealTrustA > checkVia for m23caatk:443 WebSealTrustA < getCheckID: -1 WebSealTrustA d Host and port: m23caatk:443 is not trusted. TrustAssociat < getInterceptor WebAuthentica < handleTrustAssociation: (null user)

The output for a successful connection would be similar to that shown in Example 5-10.

Example 5-10: Trace of successful TAI call

 WebAuthentica d handleTrustAssociation WebAuthentica d TrustAssociation is enabled. TrustAssociat > getInterceptor TrustAssociat d Check if target interceptor ... WebSealTrustA > getCheckID WebSealTrustA < getCheckID WebSealTrustA d isTargetInteceptor: header name=accept WebSealTrustA d isTargetInteceptor: header name=accept-encoding WebSealTrustA d isTargetInteceptor: header name=accept-language WebSealTrustA d isTargetInteceptor: header name=connection WebSealTrustA d isTargetInteceptor: header name=host WebSealTrustA d isTargetInteceptor: header name=iv-creds WebSealTrustA d isTargetInteceptor: header name=iv-groups WebSealTrustA d isTargetInteceptor: header name=iv-user WebSealTrustA d isTargetInteceptor: header name=user-agent WebSealTrustA d isTargetInteceptor: header name=via WebSealTrustA d isTargetInterceptor: VIA=HTTP/1.1 m23caatk:443 WebSealTrustA > checkVia for m23caatk:443 WebSealTrustA < getCheckID: 0 WebSealTrustA d Yes, it is via WebSeal. WebAuthentica d A TrustAssociation interceptor is available for this request. WebSealTrustA > Entering validateEstablishedTrust... WebAuthentica d TrustAssociation has been validated successfully. WebSealTrustA > getAuthenticatedUsername WebSealTrustA < Exiting getAuthenticatedUsername: wpsadmin WebAuthentica d Username retrieved is [wpsadmin] WebAuthentica d Map credentials for wpsadmin. WebAuthentica > validate WebAuthentica < validate WebAuthentica d Mapped credential for TrustAssociation was validated successfully. WebAuthentica < handleTrustAssociation: OK

To disable tracing, you have to click Troubleshooting -> Logs and Traces in the WebSphere Administrative Console. Click WebSphere_Portal. Click Diagnostic Trace and change the Trace Specification to:

    *=all=disabled

Click OK. Save the configuration changes and restart the WebSphere Portal Server.

5.4.7 Changing Portal Logout and Login pages

By default, when unauthenticated users attempt to access the myportal page, they are redirected to the login screen to provide a user name and password. When using a WebSEAL or SiteMinder TAI for authentication, you no longer need to use the WebSphere Portal login screen. Instead, the login icon should point to the myportal page. There are several steps to be taken to accomplish this task.

Modifying ToolBarInclude.jsp

To remove the ability of end users to self-register, remove the link to the self-registration screen from the public portal page. Make a back-up copy of the <was_root>/installedApps/<hostname>/wps.ear/wps.war/themes/html/ <theme_name>/ToolBarInclude.jsp file located in the subdirectory of each theme. Open the file in a text editor and comment out the enroll button as shown below:

 <!-- <%-- enroll button --%>             <wps:if loggedIn="no">             <%                 String dt = com.ibm.wps.puma.UserManager.instance().getDirectoryType();                 if (dt==null)                 {                     dt = "";                 }                 if (!dt.equals("SSPM"))                 {             %>               <td  valign="middle" align="<%=bidiAlignRight%>" nowrap>                 <a  href='<wps:url command="PrepareEnrollment" home="public" req/>'><wps:text key="link.enrollment" bundle="nls.engine"/></a>               </td>             <%                 }             %>             </wps:if> -->

Edit the login button section in each file as shown below:

 <%-- login button --%>             <wps:if loggedIn="no" notScreen="Login">                <td  valign="middle" align="<%=bidiAlignRight%>" nowrap>                 <a  href='<wps:url home="private" screen="Home" ssl="true"/>'><wps:text key="link.login" bundle="nls.engine"/></a>                </td>             </wps:if>

Open and save the versions of Default.jsp that include each of the files you edited above. This is necessary to make the application server recompile the JSP pages in order to have the changes take effect.

Modifying web.xml

Make a back-up copy of the <was_root>/installedApps/<node_name>/wps.ear/wps.war/WEB-INF/web.xml file. Edit the file as shown in bold below:

 <login-config > <auth-method>FORM</auth-method> <realm-name>WPS</realm-name> <form-login-config > <form-login-page>myportal</form-login-page> <form-error-page>/error.html</form-error-page> </form-login-config> </login-config>

Modifying ConfigService.properties

Make a back-up copy of the <wp_root>/shared/app/config/services/ConfigService.properties file. Edit the file as specified below:

 redirect.login     = true redirect.login.ssl = true redirect.login.url = ... redirect.logout= true redirect.logout.ssl= true redirect.logout.url= https://<host_name>/<logout_page>

where:

<host_name> is the fully qualified host name of the WebSEAL machine.

<logout_page> is the page that users will be directed to when they log out. For Tivoli Access Manager, this value is pkmslogout.

The value for redirectlogout.url must appear on a single line.

After having performed all of these steps, you will have to restart WebSphere_Portal.

Testing the Logout link

Test the changes by logging in to the portal and clicking the Logout link. You should be redirected to a page similar to the one shown in Figure 5-64.

click to expand
Figure 5-64: Logout screen

Testing Signup Link

You can also go to the URL:

https://m23caatk.itso.ral.ibm.com/portal/wps/portal

Note that m23caatk.itso.ral.ibm.com is the <security node hostname> used in our environment. You will be able to see that the Signup link does not appear any longer.

click to expand
Figure 5-65: Signup link removed

5.4.8 Configuring mutual SSL: WebSEAL and IBM HTTP Server

Copy the extracted certificate file (C:\program files\Tivoli\PDweb\www\certs\webseal-client.arm) generated in 5.4.1, "Configuring the WebSEAL Key Ring Database" on page 183 from the Security Node to a secured temporary directory on the Application Node.

On the Portal server go to Start -> Programs -> IBM HTTP 1.3.26 -> Start Key Management Utility. Select Key Database File -> Open. Browse to C:\program files\IBMHttpServer\conf and select the IHS_certs.kdb file. Click Open. Type in the password, which is WebIHS.

Select all the existing Signer Certificates and click the Delete button; respond Yes to the confirmation dialog.

Select Signer Certificates and click Add. Ensure that the data type is set to Base64-encoded ASCII data. Click Browse and go to the secure temporary folder, then select the file webseal-client.arm which was copied in the previous step. Click Open. and then OK. You will be prompted for a label for the certificate. Type in WebSEAL-client. Click OK. The window should look as shown in Figure 5-66.

click to expand
Figure 5-66: IHS Key Database - Signer Certificates

Close the file and the utility.

Tip

Before proceeding, we recommend that you back up the httpd.conf file.

To access the IBM HTTP Server Administration you will have to go to the URL:

https://localhost/apadminred.html

Log in as the user ihsadmin with password sah309r. Go to Security -> Host Authorization. Ensure the scope is Global and select the Required radio button for the Mode of Client Authentication to Use property. Click Submit. Change the scope to the virtual host, select the Required radio button for the Mode of Client Authentication to Use property. Click Add in the Client certificate groups section. Type in a group name, for example the WebSEAL server name m23caatk (in our environment). Select Common Name from the List of Attributes drop-down list. Click the = sign. Type in the WebSEAL fully qualified server name m23caatk.itso.ral.ibm.com (in our envirnoment). Click Apply, then Submit.

click to expand
Figure 5-67: IHS Mutual SSL Authentication configuration

Go to Basic Settings -> Core Settings. Ensure that the scope is set to Global. Delete the value 80 in the Specify port field. Click Submit and restart the server through the Services application. Refer to 5.4.5, "Verifying Trust Association Interceptor operation" on page 190 to test and verify the TAI configuration again.

Note

This step could have been performed earlier but we have addressed it here so as to simplify the tests for each of the previous steps.

< Day Day Up >