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.

Back to top

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.

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:

The LTPA cookie contains the following pieces of information:

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

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.

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.

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.

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

Create a new self sign certificate as shown below

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

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.

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.

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

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.

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.

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>
	

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

				
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

				
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.

				
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.

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.

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

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.

				
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

				
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:

				
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.

				
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:

				
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.

				
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.

				
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:

				
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.

				
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:

				
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.

				
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

				
[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:

				

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.

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.

Back to top

Download

Information about download methods

Resources

• Article related Tivoli and WebSphere product guides
  • IBM® Tivoli Access Manager 6.0 Install Guide
  • IBM® Tivoli Directory Server 6.0 Documentation
  • IBM® WebSphere Application Server Documentation
  • IBM® WebSphere portal v6.0 Documentation
  
  
• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus ®, Rational®, Tivoli®, and WebSphere®.
  
  

About the authors

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.

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

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Single sign-on techniques
• Lightweight third-party authentication
• Trust Associations Interceptor
• Enabling SSL between WebSEAL and back-end servers using GSKit Utility
• Configuring single sign-on for WebSphere Portal
• WebSphere Portal session management and logout using the WebSEAL server
• Integration scenario
• Troubleshooting
• Conclusion
• Download
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: Tivoli Access Manager Enterprise Single Sign-on
• Demo: Demo: Tivoli Access Manager for Enterprise Single Sign-On solution overview
• Briefing: Introduction to Tivoli service management environment
• Buy: Tivoli Access Manager Enterprise Single Sign-on

Dig deeper into Tivoli on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers