Transparent webseal junction & SSO

Introduction :

In this environment, I would like to illustrate two different features of WebSeal not covered in the WebSphere Portal Information center:

- Transparent Junction
- LTPA Single Sign-on

Concept Explanation :

Transparent Junction Concept:

For standard WebSEAL junctions, a link to a resource on a back-end junctioned server can only succeed if the URL in the request received by WebSEAL contains the identity of the junction.

Transparent path junctions are really the same as standard junctions except that the junction name, instead of being an addition to the URL path, is based on the path already present on the back-end application. Transparent path junctions allow WebSEAL to route requests to a junction based on the URL path of the back-end server resources themselves rather than based on an additional junction name added to the back-end URL paths.

For example, if the configured junction name is /docs, all resources controlled by this junction must be located on the back-end server under a subdirectory called /docs.

To apply this type of junction to WebSphere Portal is very reasonable as all portal URLs, whether they are for accessing the protected area (/wps/myportal), public area (/wps/portal), or portlet application resources (/wps/_PAabcde...) begin with the enterprise app's context root (defaults to wps).

Especially in the new version of WebSphere Portal, many resources are requested, rendered and executed at the client side in the form of javascript. Historically, there have been problems with the junction name insertion in client-heavy sites. This junction type immediately alleviates these problems.

LTPA:

Because Tivoli Access Manager WebSEAL has access to the proprietary composition of an IBM LtpaToken credential, it can provide authentication and authorization services and protection to backend IBM WebSphere environments. WebSphere primarily relies on the cookie-based lightweight third-party authentication mechanism (LTPA) for its authentication token.

When WebSEAL is positioned as a protective front-end to WebSphere, users are faced with two potential login points – WebSeal and WebSphere. To achieve a single signon solution to one or more IBM WebSphere servers across WebSEAL junctions, you can configure WebSEAL junctions to generate LTPA tokens, and pass them to various backend servers configured to use the same token encryption key. This is referred to as a WebSphere security domain.

One of the benefits of allowing WebSEAL to generate and maintain the LtpaToken credential is allowing WebSeal to be the primary manager of the user session. For example, when a WebSeal session expires, the re-authentication prompt will originate from WebSeal, and not the various back-end security forms.

A second benefit involves a heterogenous mixure of back end applications including others IBM software families that accepts LTPA as an authentication mechanism. If WebSeal is generating the token, more fllexibility in accomplishing Single Sign-on to Domino and WebSphere is available.

Environment overview
The environment included the following items:

* IBM WebSphere Portal 6.1 and WebSphere Application Server 6.1.0.15
* IBM HTTP Server 6.1
* Sun One Directory 5.2.4 (pdogwinxp.raleigh.ibm.com)
* IBM Tivoli Access Manager and WebSeal 6.1

Architecture

Image:Deployment Scenario with Tivoli Access Manager 6.1 : LTPA & Transparent Junction

Installation and configuration

Refer to the topics from the WebSphere Portal 6.1 Information Center and Tivoli Access Manager 6.1 infocenter listed in the steps below for more detailed instructions on the steps to install and configure the environment used for this test.

1 Install Sun One Directory 5.2.4
2 Install WebSphere Portal 6.1, using the topic “Setting up a stand-alone production server” in 6.1 Information Center
3 Enable security for WP 6.1 to Sun One Directory, using the topic “Configuring WebSphere Portal to use a user registry”
4 Verify Portal Security against Sun One Directory
5 Install Tivoli Access Manager 6.1, using the topic “Setting up a Policy Server”
6 Install WebSeal 6.1, using the topic “Setting up WebSeal”
7 Export LTPA Key from the WebSphere Admin Console, using the topic “Retrieving LTPA key” in the WebSphere Portal Infocenter. (In this environment, wp.key)
8 Manually copy the WAS LTPA encryption key file to the WebSeal Server.
9 Open a pdadmin command prompt from any node that has a Tivoli Access Manager Runtime component installed.
10 Enter this command on one line :

server task WebSEAL-Instance-webseald-WebSEAL-HostName create -t tcp -A -F LTPA-Keys-Path -Z LTPA-Password -f -x -h Target-Host -p 10040 /
o The -A enables LTPA cookies
o The -F key file option and argument specifies the full path name location on the WebSEAL server of the key file used to encrypt the shared key.
o The -Z keyfile-password option and argument specifies the password required to open the key file
o The -x creates the transparent path junction.

11 Now, you can try to log in into WebSphere Portal through TAM Authentication process
12 Open a new brower windows, enter http://[WebSeal-Hostname]/wps/myportal
13 You should be prompted and authenticated by WebSeal
14 WebSeal creates a LTPA token for the user, and passes this token to WebSphere for the authentication. In contrast to a related mechanism for Single Sign On, this scenario does not require Trust Association (TAI) to be enabled on backend systems, nor does it require the Authorization, -iv-user, or iv-creds headers to be supplied on the junctioned requests.

In addition, because we've created a transparent (-x) junction, there is no longer a requirement to enable scripting support on the junction (-j and -J Trailer).