Single sign on to a IBM WebSphere Portal through IBM Tivoli Access Manager WebSEAL

Concrete scenarios offer Tivoli security tips

This article highlights some of the important points to be considered while integrating IBM® Tivoli® Access Manager for e-business with IBM WebSphere® Portal for the purpose of providing authentication to a portal through single sign-on (SSO). It provides detailed steps for configuring a Trust Association Interceptor++ (TAI++), which is one of several ways to configure SSO. It also discusses WebSphere Portal (WP) session management. This article provides very useful information about SSO mechanisms, such as LTPA, TAI, TAI++. This information is very helpful to differentiate between these SSO mechanisms and make selections among them. This article also covers steps required to create keys for enabling security using the IBM Key Management Utility. Command line options are also provided along with GUI options so that a user cannot get stuck even if the GUI is not available. These steps are also useful for those who are using IBM Key Management Utility for key management purpose.

Mr. Mandar Vilas Deshmukh (mandar_deshmukh@in.ibm.com), Staff Software Engineer, IBM India Pvt. Ltd.

Mandar Deshmukh Mandar is Staff Software Engineer, currently working with Tivoli® Directory Server Java development team as Technical lead. He has total 5+ years of experience in IBM® India Pvt. Ltd. He is Tivoli Certified Advanced Deployment Professional - Tivoli Security Management Solutions (ITAM, ITIM, ITIL Foundation Certified). He is also EC-Council certified Ethical Hacker, Sun certified Java Professional and IBM® Certified DB2 V 8.1 Associate.



Mr. Nagesh Bhagwat (nagesh_bhagwat@in.ibm.com), Systems Software Engineer, IBM India Pvt. Ltd.

Nagesh BhagwatNagesh is Systems Software Engineer, currently working with Tivoli Security Team, IBM® India Software Labs. He holds Bachelor of Engineering Degree in Computer Science. He is IBM®Tivoli Access Manager for e-business V6.0 Implementation-certified, IBM® Certified DB2 V 8.1 Associate and SUN Certified Java Professional.



18 February 2009

Also available in Portuguese

Introduction

IBM WebSphere Portal runs as an application on IBM WebSphere Application Server, and provides the aggregation of contents, applications, processes, personalization, and other services. WebSphere Application Server and WebSphere Portal can integrate with an external security manager product, such as IBM Tivoli Access Manager for e-business or Netegrity SiteMinder.

One of the components of Tivoli Access Manager is its reverse proxy security server called WebSEAL. WebSEAL can front-end any Web application server or Web server in an enterprise e-business infrastructure. When WebSphere Application Server and WebSphere Portal are implemented with WebSEAL, it is usually necessary to provide a SSO experience for the end user. In order to achieve SSO, the WebSphere Application Server needs to be configured to "trust" the WebSEAL server so that if WebSEAL has already authenticated a user, Application Server will not challenge the user again.

WebSphere Application Server provides the Web Trust Association framework that you use to configure for third party security servers. An implementation of the TAI is required for every type of security server. WebSphere Application Server comes with a TAI for Access Manager, which you configure. Based on the established trust, Application Server can map the WebSEAL resultant credential to a valid WebSphere Application Server credential.

This article is useful for Application Server administrators, portal administrators, and others who need to provide SSO for their WebSphere Portal applications. To make the best use of this article, you should be familiar with WebSphere Application Server, WebSphere Portal, and Tivoli Access Manager administration tasks. You should also be familiar with configuring an LDAP directory server, such as IBM Tivoli Directory Server, which is used in the example scenario explained in this article.

The information about SSO mechanisms and the IBM Key Management Utility is useful for security programmers, deployment professionals and designers.


Single sign-on techniques

Lightweight third-party authentication

Lightweight Third-Party Authentication (LTPA)" LPTA is an authentication technology used in IBM WebSphere and Lotus Domino products.

LTPA token

LtpaToken: The LtpaToken is used for inter-operating with previous releases of WebSphere Application Server. This token contains the authentication identity attribute only. LtpaToken is generated for releases prior to WebSphere Application Server v5.1.0.2 (for z/OS) or version 5.1.1 (for distributed).

LtpaToken2: LtpaToken2 contains stronger encryption and enables you to add multiple attributes to the token. This token contains the authentication identity and additional information such as the attributes that are used for contacting the original login server and the unique cache key for looking up the Subject when considering more than just the identity in determining uniqueness. LtpaToken2 is generated for WebSphere Application Server Version 5.1.0.2 (for z/OS®) and for v5.1.1 (for Distributed) and beyond.

If a user is accessing Web servers leveraging the LTPA technology, then it is possible for a Web user to automatically propagate their identity across all participating physical servers.

Such an environment is also called a single sign-on (SSO) environment.

Figure 1. SSO with LTPA
Illustration of SSO with LTPA

Request flow:

1. User requests a resource protected by WebSEAL. User is challenged by WebSEAL for credentials, and the user supplies them.

2. WebSEAL authenticates the user by communicating with its user registry. It also determines whether the user is authorized to open the requested URL. Upon successful authentication of the end user, WebSEAL creates the LTPA token cookie.

3. The request is passed to the IBM HTTP Server using the junction that is configured for it. The junction from WebSEAL to IBM HTTP Server is configured to pass the iv-user, iv-groups information, and the LTPA Token that was created in Step 2, in the HTTP header.

4. The request is forwarded to the appropriate WebSphere Application Server or clone, as determined by the Application Server plug-in.

5. In WebSphere Application Server, the TAI is not enabled and Application Server gets the LTPA token in the header. Application Server only creates the session cookie for this user and assumes that this user has been authenticated. WebSphere Portal searches LDAP for the group information, gets the resource mapping from the database, and then displays the portal page.

LTPA token:

The LTPA token is an encrypted element that contains the following pieces of information:

Table 4. The LTPA token
Element Details
User dataTypically set to the user ID, but can be any user information used to uniquely identify the user.
Expiration timeDifferent from the cookie expiration, this field is used to enforce a time limit that starts from the moment of login and is unaffected by browser activity or inactivity. The time limit is a configurable LTPA setting that defaults to 30 minutes.
Digital signatureUsed to validate the token.

The LTPA cookie contains the following pieces of information:

Table 3. The LTPA cookie
Element Details
Cookie nameAlways set to LtpaToken/LtpaToken2
DomainSet to the Internet domain shared by all servers participating in single sign-on (example: mycompany.com
Cookie expirationSet to delete this cookie at the end of the browser's lifetime.
SecureSet to force the use of Secure Sockets Layer (SSL). There is an LTPA configuration setting that creates cookies that are sent only through SSL.
Cookie valueThis is set to the LTPA token as described below.

LTPA requirement and support

LTPA requires that the configured user registry be a centrally shared repository such as an LDAP registry or a Windows® domain-type registry, so that users and groups are the same across the SSO domain.

The following table summarizes the authentication mechanism capabilities and user registries with which LTPA can work. This is for WebSphere Application Server v6.1

Table 5. LTPA support information
Authentication mechanism Forwardable credentials SSO Local OS user registry LDAP user registry Custom user registry
LTPAYesYesYesYesYes
SWAMNoNoYesYesYes

Simple WebSphere Authentication Mechanism (SWAM): The SWAM authentication mechanism is intended for simple, non-distributed, single application server runtime environments. The single application server restriction is due to the fact that SWAM does not support forwardable credentials, because SWAM is intended for a single application server process, single sign-on (SSO) is not supported.

The SWAM authentication mechanism is suitable for simple environments, software development environments, or other environments that do not require a distributed security solution.

Trust Associations Interceptor

TAI and TAI++

The intent of the Trust Association Interceptor interface is to have reverse proxy security servers (RPSS) exist as the exposed entry points to perform authentication and coarse-grained authorization, while WebSphere Application Server enforces further fine-grained access control. Trust associations improve security by reducing the scope and risk of exposure.

WebSphere Application Server supports single sign-On (SSO) with perimeter authentication services, such as reverse proxies through "trust associations". When trust associations are enabled WebSphere Application Server is not required to authenticate a user if a request arrives via a trusted source that has already performed authentication.

Figure 2. SSO with TAI
Illustration of SSO with TAI

Request flow:

1. A user requests a resource protected by WebSEAL, which serves as the proxy and intercepts all requests. The user is challenged by WebSEAL for credentials and the user supplies them.

2. WebSEAL authenticates the user by consulting with its LDAP user registry. It also determines if the user has access to (that is, is authorized to open) the requested URL.

3. If authentication is successful, WebSEAL passes the request to the IBM HTTP Server using the junction that has been configured for it. The junction from WebSEAL to the IBM HTTP Server is configured to pass the iv-user, iv-groups information in the HTTP header. The identification of the end user must be passed to the TAI in a header called "iv-user", which is inserted by WebSEAL into the HTTP request header sent from WebSEAL to the Application Server. Even though WebSEAL can be configured to pass the end user identity in other ways, the iv-user header is the only one supported by the TAI. The end user password is not passed in the HTTP header.

4. The Application Server plug-in file checks the context root of the requested URL, determines the target Application Server or clone, and forwards the request to it.

5. The TAI in the WebSphere Application Server (for which TAI must be enabled), processes the request. After TAI processes successfully, Application Server creates an encrypted user authentication cookie called an LTPA Token. This cookie, which is unique for every user for every session, (that is, if the same user logs in multiple times he will see a different cookie created each time) is long lived (typically two hours), and lasts to the end of the user session. Therefore, the TAI does not need to process every user request.

6. After the TAI has accepted the end user identification and created an LTPA token, WebSphere Portal performs additional queries against LDAP, such as group information. It queries the resource mapping from the database, and then displays the portal page.

  • Differences between TAI and TAI++

The TAI implementation works with the credential data. WebSphere Application Server uses the information to enforce security policies.

Table 6. The TAI and TAI++ differences
TAM TAI (Trust Associations Interceptor) TAM TAI++ (Trust Associations Interceptor plus plus)
This is deprecated.This is the preferred version
TAI returns a user ID that represents the end user.TAI++ returns a subject that represents the end user.
Trust associations have been supported since WebSphere Application Server v3.5. A limitation of the TAI is that is can only provide the user ID to the WebSphere Application Server runtime.The TAI interface has been extended in WebSphere Application Server v5.1.1 and WebSphere Application Server v6.0 and above to support the return of complete credential information.
After the TAI was invoked, further user registry searches were required to create the various credentials required for authorization (even if this information was already contained in the request).No additional user registry searches are required after the TAI++ invocation. (However WebSphere Portal can make additional calls to the registry to build identity attributes)
Not applicable for TAI.Be aware that if the WebSphere Application Server participates in a cluster or makes downstream EJB calls, credential propagation must be enabled in WebSphere Application Server.
This is supported in WebSEAL v4.1, 5.1 and v6.0.The TAI++ interface supports WebSEAL v5.1 and v6.0, but does not support WebSEAL v4.1.

The reader of the article can use the above differences as an input for making a selection of SSO technique to be used in there environment.

Enabling SSL between WebSEAL and back-end servers using GSKit Utility

SSL can be a good way to fulfill your security requirements. At the protocol level, SSL provides identification, authentication, integrity, and confidentiality. In the real world, it is very important to use secured communication between these enterprise servers. To enable SSL, we have to generate certificates and distribute them among the keystores of communicating servers.

In this section, you will see the complete procedure to create a new set of keys. Here only for demonstration purposes, we are using self-signed certificates.

IBM Global Security Kit (GSKit) provides both a graphical user interface (GUI) and command line interface (CLI) for creating keys for SSL. The GUI utility is known as "gsk7ikm" and the CLI utility us known as "gsk7cmd". The procedure for the GUI is explained in the following sections. The CLI file for the same is provided in a download.

Figure 3. Key distribution
Illustration of a key distribution

Key distribution

High level steps:-

1) Creation of server keystore file

2) Creation of client keystore file

3) Creation of plug-in keystore file and adding server certificate

4) Creation of server trust keystore file and adding server, client and plug-in certificates

5) Creation of client trust file and adding server and client certificates

6) WebSphere Application Server and plug-in configuration

7) WebSEAL server configuration

1) Creation of server keystore file

Figure 4. Server keystore creation
Screen shot of creating a new server keystore creation

Create a new self sign certificate as shown below

Figure 5. Server keystore creation
Screen shot of creating a self-signed certificate

Extract the certificate to the file named "Server.arm".

Figure 6. Server keystore creation
Screen shot of extracting the certificate to a file

2) Creation of client keystore file

Follow the same procedure as server keystore above for creating the client keystore file. Specify the name of the key database file as "ClientKey.jks". Create the new self sign certificate and extract the certificate to file as "Client.arm".

3) Creation of plug-in keystore file

Follow the same procedure as that for server key creation. Select the key database type as "CMS" instead of JKS and create key file as "PluginKey.kdb". Create new self sign certificate and extract certificate to file as "Plugin.arm".

Add the server certificate from file to plug-in key database file.

Figure 7. Creation of plug-in keystore file
Screen shot of adding a CA certificate from a file

Specify the label as "WebSphere Server CA" and click "OK".

4) Creation of Server trust keystore file and adding server, client and plug-in certificates.

Figure 8. Creation of server trust keystore file
Screen shot of the creation of server trust keystore file

Add the client certificate from file to "Servertrust.jks"

Figure 9. Creation of server trust keystore file
Scrren shot of adding a CA certificate from a file

Specify the label as "WebSphere Client CA" and click "OK".

In a similar way, add the "Serverkey.arm" and "plugin.arm" certificate from file to "ServerTrust.jks".

Your console should now display "WebSphere Plug-in CA", "WebSphere Server CA" and "WebSphere Client CA" in the list as shown below.

Figure 10. Creation of server trust keystore file
Scrren shot of a window displaying WebSphere Plug-in CA, WebSphere Server CA and WebSphere Client CA in the list

5) Creating client trust keystore file and adding server and client certificates.

Follow the same procedure as above for creation of the client trust key file named as "ClientTrust.jks" as well as adding the server and client certificate to the existing certificate

Your console should now contain "WebSphere Server CA" and "WebSphere Client CA" in the list as shown in the figure below.

Figure 11. Creating the client trust keystore file
Screen shot of a window displaying WebSphere Server CA and WebSphere Client CA

6) Updating WebSphere Application Server

Configure WebSphere Application Server to use the new keys.

Go to Admin Console:

1) Select Security -> SSL -> <cell>/DefaultSSLSettings

2) Change the following entries to reflect the path and passwords of the new keys -> Click OK

Key File Name: ${USER_INSTALL_ROOT}/etc/ServerKey.jks
Key File Password: <ServerKey.jks Password>
Trust File Name: ${USER_INSTALL_ROOT}/etc/ServerTrust.jks
Trust File Password: <ServerTrust.jks Password>
Figure 12. WebSphere SSL configuration
Screen shot of WebSphere SSL configuration

Click to see larger image

Figure 12. WebSphere SSL configuration

Screen shot of WebSphere SSL configuration

Note: If you are in an ND environment, you will need to update the <dmgr>/DefaultSSLSettings as well with the entries above.

3) Save changes and logout

4) Restart the WebSphere Server

Note: If you are in an ND environment, you need to restart all servers, node agents and the Deployment Manager for the new settings to take effect cell-wide

Updating the sas.client.props file
1) Open the $WAS_HOME/properties/sas.client.props file in an editor
2) Change the following lines in the sas.client.props file to reflect the new SSL
settings -> Save the file
com.ibm.ssl.keyStore=C\:/Program Files/WebSphere/AppServer/etc/ClientKey.jks
com.ibm.ssl.keyStorePassword=<ClientKey.jks Password>
com.ibm.ssl.trustStore=C\:/Program Files/WebSphere/AppServer/etc/ClientTrust.jks
com.ibm.ssl.trustStorePassword=<ClientTrust.jks Password>

Note:-  The path to your key files will be relative to your WebSphere installation and
platform
Updating The soap.client.props file
1) Open the $WAS_HOME/properties/soap.client.props file in an editor
2) Change the following lines in the soap.client.props file to reflect the new SSL
settings -> Save the file
com.ibm.ssl.keyStore=C\:/Program Files/WebSphere/AppServer/etc/ClientKey.jks
com.ibm.ssl.keyStorePassword=<ClientKey.jks Password>
com.ibm.ssl.trustStore=C\:/Program Files/WebSphere/AppServer/etc/ClientTrust.jks
com.ibm.ssl.trustStorePassword=<ClientTrust.jks Password>

Note:-  The path to your key files will be relative to your WebSphere installation and
platform
Updating tghe plugin-cfg.xml file
1) Open the $WAS_HOME/config/cells/plugin-cfg.xml file in an editor.
2) Change the following lines in the "plugin-cfg.xml" file to reflect the new plug-in SSL
key ->. Save the file.
<Property Name="keyring"
	Value="C:\Program Files\WebSphere\AppServer\etc\PluginKey.kdb"/>
<Property Name="stashfile"
	Value="C:\Program Files\WebSphere\AppServer\etc\PluginKey.sth"/>

Note:-  The path to your key files will be relative to your WebSphere installation and
platform.
Note:-  You will need to change all transports that use HTTPS in the "plugin-cfg.xml" file.

3) Restart your Web server for the new changes to take effect.
Importing certificate to WebSEAL
1) Open a key database file (KDF) of WebSEAL by selecting "Key Database File" -> "open"
2) Enter the following information to create the key file -> Click OK .
Select from Location : C:\Program Files\Tivoli\pdweb\www-default\certs\pdsrv.kdb
3) Enter a password for your key file -> Click OK.
4) Click on Import key Button.
5) Enter the following information to add the server's public certificate -> Click OK.
Certificate File Name: ServerKey.arm
Location: C:\Program Files\WebSphere\AppServer\etc
6) Enter a password for the server key public certificate -> Click OK.
7) Save and Exit.

Configuring single sign-on for WebSphere Portal

WebSphere Portal session management and logout using the WebSEAL server

WebSEAL maintains a session cache that contains security information referencing all authenticated users. As part of maintaining this cache, timers are used to enforce security constraints upon the length of a user session as well as the amount of idle time permitted. Expired sessions are removed from the WebSEAL cache, destroying the session of the user.

WebSphere Portal also maintains a session cache for all authenticated users. This cache is managed by the WebSphere Portal Server and has similar time-based security constraints. When integrating WebSEAL and WebSphere Portal, it becomes necessary to understand the implications of these distinct session caches and how they need to be managed.

WebSEAL is usually configured to provide single sign-on (SSO) to back-end HTTP servers. This means that users authenticate one time to the WebSEAL server. Their identity is then securely propagated to the back-end applications. In this case, WebSEAL is providing the management of the user authentication data, and as such, should be considered the master source of session information. For this reason we generally recommended that WebSEAL sessions expire shortly before any back-end HTTP server sessions. This recommendation helps to ensure that a consistent user experience is provided for a user. If a back-end HTTP application timed-out session data before the WebSEAL session for example, the user might experience errors from the back-end application.

The WebSphere Portal, by default, has a 30-minute idle time-out and 2-hour session time-out on its user sessions. These values can be changed as shown in figure below.

Figure 13. Session time-out configuration
Screen shot of a session time-out configuration

If SSO is configured between WebSEAL and WebSphere Portal and the WebSphere Portal session times out before the WebSEAL session, the session expired error page is displayed to the user. In many cases, administrators can simply configure WebSphere Portal to not show this error. Set the "timeout.resume.session=true" parameter to turn this off.

Figure 14. Session time-out configuration
Screen shot of a session time-out configuration with entries highlighted

When WP is configured not to show this error, if a user session idles out or expires, the user is simply reauthenticated and a new session is created. This will occur without interaction by the user, and it will occur via the SSO integration provided by WebSEAL and WebSphere Portal.

Integration scenario

ITDS and WP Integration steps

Note:

In this scenario, WebSphere Portal and Tivoli Access Manager are sharing a common user registry.

The following section describes steps to configure WebSphere Portal with IBM Tivoli Directory Server.

Search for file PortalUser.ldif in WebSphere portal home directory, modify the suffix your LDAP server is configured for and import the ldif file to Tivoli Directory Server using the following idsldapadd command.

Listing 7. LDIF import command
cmd>idsldapadd -D cn=root -w <password> -p <port> -c -f PortalUser.ldif

Run pdadmin commands to import the following users and group to Tivoli Access Manager after successfully completing the above command: Group: wpsadmins Users: wpsbind and wpsadmin

Listing 8. pdadmin import command
pdadmin -a sec_master -p <password>
pdadmin sec_master> group import wpsadmins cn=wpsadmins,cn=groups,o=ibm,c=in
pdadmin sec_master> user import wpsbind uid=wpsbind,cn=users,o=ibm,c=in
pdadmin sec_master> user import wpsadmin uid=wpsadmin,cn=users,o=ibm,c=in
pdadmin sec_master> user modify wpsbind account-valid yes
pdadmin sec_master> user modify wpsadmin account-valid yes

Run the following commands to verify users and groups in TAM:

Listing 9. verify users and groups
pdadmin -a sec_master -p passw0rd user list * 0
pdadmin -a sec_master -p passw0rd group list * 0

Now we can start using WPSconfig.bat to configure WebSphere Portal with other Tivoli products.

We will now disable Websphere Portal security; for that we need to modify some parameters from wpconfig.properties. Use the key name from the following table to search in properties file and use values given in the table.

Listing 10. Portal configuration changes
Section: WeSphere Application Server configuration
WasUserid						wpsbind
WasPassword 					wpsbind

Section: WebSphere Portal configuration
PortalAdminid 					wpsadmin
PortalAdminPwd 					wpsadmin
PortalAdminGroupId 				wpsadmins

Open the command prompt and go to the portal_server_root/config directory.

Enter the following command to run configuration task:

Listing 11. Disable security
WPSconfig.bat disable-security

Note:- Proceed only if you get a Build Successful message. If any of the configuration tasks fail, verify the values in the wpconfig.properties file.

After every step, use the following command to check that states of the servers.

Listing 12. Checking server state
C:\Program Files\WebSphere\AppServer\bin>serverStatus.bat -all

Note:- The Application Server status must be STARTED

Now it is time to configure WebSphere Portal to use LDAP security. In this article, we are using Tivoli Directory Server as the user registry. Before running the command to enable lDAP security, we need to modify some parameters from wpconfig.properties. Use the key name from following table to search in the properties file and use values given in the table.

Note:- For demonstration purposes, we are using same user and group for all roles. You can create and use different users and groups for each role.

Listing 13. Integrate Portal with LDAP and TAM
Section: WebSphere Portal configuration
PortalAdminId 				uid=wpsadmin,cn=users,o=ibm,c=in
PortalAdminIdShort 			wpsadmin
PortalAdminPwd 				wpsadmin
PortalAdminGroupId 			cn=wpsadmins,cn=groups,o=ibm,c=in
PortalAdminGroupIdShort 		wpsadmins
WpsContentAdministrators 		uid=wpsadmin,cn=users,o=ibm,c=in
WpsContentAdministratorsShort		wpsadmin
WpsDocReviewer 				uid=wpsadmin,cn=users,o=ibm,c=in
WpsDocReviewerShort 			wpsadmin

Section: LDAP configuration
LDAPHostName 				dw_server.in.ibm.com
Lookaside 				true
LDAPPort 				389
LDAPAdminUId 				cn=root
LDAPAdminPwd 				passw0rd
LDAPServerType 				IBM_DIRECTORY_SERVER
WWmmSystemId 				uid=wpsbind,cn=users,o=ibm,c=in
WmmSystemIdPassword 			wpsbind
LDAPSuffix 				o=ibm,c=in
LdapUserPrefix 				uid
LDAPUserSuffix 				cn=users
LdapGroupPrefix 			cn
LDAPGroupSuffix 			cn=groups
LDAPUserObjectClass 			inetOrgPerson
LDAPGroupObjectClass 			groupOfUniqueNames
LDAPGroupMember 			uniqueMember
LDAPUserFilter 				(&(uid=%v)(objectclass=inetOrgPerson))
LDAPGroupFilter 			(&(cn=%v)(objectclass=groupOfUniqueNames))
LTPAPassword 				passw0rd
LTPATimeout 				120
SSODomainName 				in.ibm.com

Section: Tivoli Access Manager related configuration entries
PDAdminPwd 				passw0rd
PDServerName 				dw_server.in.ibm.com
TamHost 				dw_server.in.ibm.com
PDPolicyServerList 			dw_server.in.ibm.com:7135:1
PDAuthzServerList 			dw_server.in.ibm.com:7136:1
JunctionPoint 				/dw_server_tai
WebSealInstance 			Webseal_instance-webseald-dw_server.in.ibm.com
WebSealHost 				dw_server.in.ibm.com
WebSealPort 				80,443
WebSealUser 				wpsbind
BaUserName	 			wpsbind
BaPassword 				wpsbind
PDRoot 					/dw_server

Save and close the wpconfig.properties file. Open command prompt and go to portal_server_root/config directory.

Enter the following command to run the configuration task:

Listing 14. Enable security
WPSconfig.bat enable-security-ldap

Note:- Proceed only if you get Build successful message for the above command.

After every step, use the following command to check states of the servers.

Listing 15. Checking server status
C:\Program Files\WebSphere\AppServer\bin>serverStatus.bat -all

Note:- The Application Server status must be STARTED

If build successfully completes, start the server1 and WebSphere Portal. Verify that LDAP (ITDS) security is enabled or not using console login.

Section: Steps to turning on SSL between different components

Note:- Skip this section if SSL is not required.

Refer to the section "Enabling SSL between WebSEAL and Back-end servers using GSKit V7" for this.

Save and close the wpconfig.properties file. Open the command prompt and go to the portal_server_root/config directory.

Enter the following command to run the configuration task:

Listing 16. TAM configuration
WPSconfig.bat run-svrssl-config
WPSconfig.bat validate-pdadmin-connection
WPSconfig.bat enable-tam-all

Note:- Proceed only if you get Build successful message for all the above commands.

After every step, use the following command to check states of the servers.

Listing 17. Server status
C:\Program Files\WebSphere\AppServer\bin>serverStatus.bat -all

Note:- The Application Server status must be STARTED

Section: WebSEAL configuration

Note:- This is only an example configuration; there are many ways that WebSEAL can be configured. The only items which are relevant to TAI are iv-creds and the dummy password.

The default location of the WebSEAL configuration file is: <TAM-install>/PDWeb/etc/webseald-default.conf

Listing 18. WebSEAL configuration
[ba]
ba-auth = none

[junction]
basicauth-dummy-password = wpsbind
http-timeout = 300
https-timeout = 300

[forms]
forms-auth = both

[script-filtering]
script-filter = yes

Configuring the logout page of WebSphere Portal

You might also need to change the logout behavior. The preferred and default behavior is for users to logout of WebSphere Portal and to retain their Access Manager SSO credentials. Access Manager is, after all, an enterprise SSO product and is likely providing SSO to more than just WebSphere Portal. However, in some cases you might prefer that, when users logout of WebSphere Portal, their Access Manager credentials are also destroyed. If you want this behavior, do the following:

Modifying ConfigService.properties

  • Make a backup copy of the ConfigService.properties file in:
    • <WP_ROOT>\config\properties\ConfigService.properties.
  • Edit the file as specified below:
Listing 19. WP logout configuration
redirect.logout= true
redirect.logout.ssl= true or false, depending on your environment
redirect.logout.url= <protocol>://<host_name>/pkmslogout

Where:

  • <protocol> is the protocol of the WebSEAL machine (HTTP or HTTPS).
  • <host_name> is the fully qualified WebSEAL URL.

The value for redirect.logout.url must appear on a single line.

Perform the following steps to run the update-properties configuration task:

  • Locate the directory /PortalServer/config
  • Type the following configuration task appropriate for your operating system on a command line:
    • WPSconfig.bat update-properties

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

Test TAI++:

Now we are done with all the steps, Verify that you get SSO by going to your version of this URL: https://<websealhost>:<port>/dw_server_tai/wps/myportal

Username: wpsbind

Password: wpsbind

Result: You must get THE myportal page without any portal login.

Figure 15. WebSphere Portal home
Sreen shot of the IBM Websphere Portal myportal Web page

Congratulations! You have successfully configured SSO between Tivoli Access Manager and WebSphere Portal

Test TAI++ Logout page:

Currently you are logged in to the myportal page. Test the changes by logging in to the portal and clicking the Logout link. Your page should redirect to a WebSEAL pkmslogout page with a message saying: "User wpsbind has logged out"

Troubleshooting

Problem-I:- Session time-out while single sign-on through WebSEAL to WebSphere Portal

Solution :- Login to the WebSphere admin console Select Resources-> Resources Environment providers -> WP ConfigService -> Custom properties Add new parameter as "timeout.resume.session" with value "true" as type "Boolean". Restart WebSphere Application Server.

Problem-II:- validate-pdadmin-connection configuration task failed

Solution :- Issuing the message "Cannot contact server", the validity of the PDAdmin ID and password values need to be verified in the wpconfig.properties file.

Problem-III:- Debugging the IBM® Tivoli Access Manager for E-business login module

Solution :- The WebSphere Application Server Administrative Console maintains the login modules for WebSphere Portal. To debug the Tivoli Access Manager supplied PDLoginModule, access the WebSphere Application Server Administrative Console, look for the application Portal_Login JAAS Login, and add a custom property to PDLoginModule with a property name of "debug" and a value "=true".

Problem-IV:- Verifying TAM-TAI configuration

Solution :-

  • In the WebSphere Application Server Administrative Console, click Security > Global security > Authentication > Authentication mechanisms >LTPA. Click Trust Association under Additional Properties
  • Under General Properties, find Enable trust association. If its box is checked, then the trust association is already enabled. If it is not checked, select the check box and click "OK" to enable trust association
  • Click "Save" at the top of the screen under Message(s). Click "Save" again, when prompted, to confirm your changes
  • Click Security > Global security > Authentication > Authentication mechanisms >LTPA. Click Trust Association under Additional Properties. Click Interceptors under Additional Properties
  • The following interceptor should be listed:
    • com.ibm.ws.security.web.WebSealTrustAssociationInterceptor
  • If it is not listed, review the ConfigTrace.log for errors encountered during the enable-tam-tai configuration task, and re-run the task if necessary.
  • Click "Save" at the top of the screen under Message(s). Click "Save" again when prompted, to confirm your changes

For more Troubleshooting refer to IBM WebSphere Portal v6.0 Documentation from the Resource section

Conclusion

This article provides different ways in which LTPA, TAI can be configured for integrating Tivoli Access Manager with WebSphere Portal for authentication. It also explains how these mechanism helps WebSphere Portal and Tivoli Access Manager WebSEAL Server to achieve single sign-on. You walked through a scenario where you set up SSL environment for WebSphere Portal, Tivoli Access Manager, and WebSphere plug-ins.


Download

DescriptionNameSize
IBM Command Line Reference for SSL Key Generationcli.zip1KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Security on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • Security

    Pragmatic, intelligent, risk-based IT Security practices.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • IBM evaluation software

    Evaluate IBM software and solutions, and transform challenges into opportunities.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Security, Tivoli (service management), Tivoli
ArticleID=368070
ArticleTitle=Single sign on to a IBM WebSphere Portal through IBM Tivoli Access Manager WebSEAL
publish-date=02182009