You are on page 1of 57

Tivoli Access Manager

WebSEAL SSO, Series - III


Presented by:
Tushar Prasad
Prashant Kamat
Nishant Singhai

IBM Software Group | Tivoli software

Contact Details
Tushar Prasad
tprasad1@in.ibm.com
Prashant Kamat
prashant_kamat@in.ibm.com
Nishant Singhai
nishant.singhai@in.ibm.com

IBM Software Group | Tivoli software

Objective
Understand the available support resources
LTPA Overview
WebSEAL Configuration for LTPA
TAI/TAI++ Overview
Demo, SSO with Web Portal server Using TAI++
Troubleshooting and Known Issues

IBM Software Group | Tivoli software

Important Links
TAM Package information:
http://www-933.ibm.com/support/fixcentral/swg/selectFixes

TAM 6.1.1 System Requirements:


http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ib
m.itame.doc/am611_relnotes14.htm?path=3_1_0_3_1#wq146

TAM 6.1.1 Product Documentation:


http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ib
m.itame.doc/welcome.htm

IBM Software Group | Tivoli software

Important Links
Support Site:
http://www-01.ibm.com/software/tivoli/products/access-mgr-e-bus/

Tivoli Product Lifecycle Site:


http://www-01.ibm.com/software/support/lifecycle/

Developerworks for TAI ++ configuration


http://www.ibm.com/developerworks/tivoli/library/t-tamtai/

Tivoli Software Global User Group Community:


http://www.tivoli-ug.org/

IBM Software Group | Tivoli software

STE Links
Previous STEs:

Deployment scenario with TAM 6.1


http://www-10.lotus.com/ldd/portalwiki.nsf/dx/create-a-transparent-ltpajunction-with-tivoli-access-manager-6.1

WebSEAL SingleSignOn Using BA and GSO


https://www-304.ibm.com/support/docview.wss?uid=swg27022075

IBM Software Group | Tivoli software

LTPA Overview
Single SignOn
Login Once gain access to all
Single Signon is a method, which allows the user to access a resource,
regardless of the resource's location, using only one initial login.
What is Third-Party Authentication?
The initial authentication using LTPA is based on a username and
password stored in an LDAP directory, where the directory is trusted by all
the servers that share the same user registry.
LDAP directory server is referred to as a "trusted third party," hence the
part of the name: "Third Party Authentication.
Why named? Lightweight?
The amount of information contained in the cookie is relatively minimal,
hence the term "Lightweight."

IBM Software Group | Tivoli software

LTPA Overview
Single SignOn
WebSphere/DataPower/other IBM servers provide support for the cookiebased lightweight third-party authentication mechanism (LTPA).
We can configure WebSEAL to support LTPA authentication
The LTPA cookie, serves as an authentication token for
WebSphere/DataPower.
LTPA cookie contains the user identity, key and token data, buffer length,
and expiration information.
LTPA cookie is encrypted with the shared LTPA key between WebSEAL
and backed server.

IBM Software Group | Tivoli software

LTPA Overview
LTPA Cookie
Cookie name: Always set to LtpaToken.
Domain: Set to the Internet domain shared by all servers participating in SSO
Cookie expiration: Set to delete this cookie at the end of the browser's lifetime.
Secure: Set to on 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 value: This is set to the LTPA token as described below. The LTPA token
is an encrypted string that contains the following pieces of information:
User data: Typically set to the user ID but can be any user information used to
uniquely identify the user.
Expiration time: Different 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, defaults to 30 minutes.
Digital signature: Used to validate the token.

IBM Software Group | Tivoli software

LTPA SingleSignOn

IBM Software Group | Tivoli software

LTPA SingleSignOn
A client accesses the Backend Server through Tivoli Access Manager
WebSEAL.
WebSEAL intercepts the request, authenticates and authorizes the user.
Once the authentication has succeeded, WebSEAL passes the request to
Backend Server, together with the authenticated user DN in the form of an
LTPA cookie.
The Backend Server is configured to extract the user DN from the LTPA
token, check that the user exists in the LDAP directory, and sign the user in.
The users browser then connect to the Backend server through WebSEAL,
using the LTPA token for SSO.

IBM Software Group | Tivoli software

LTPA SingleSignOn
LTPA Notes:
All servers using LTPA tokens must reside in the same DNS domain.
RFC-2965 states that a user agent (browser) will not provide a cookie to a
server in a different DNS domain than the host (server) that issued (set) the
cookie. There are proxy architectures that can get around the single DNS
domain limitation, but such are advanced proxy architectures
All application servers must share the same user registry (LDAP directory).
Supported directories include Lotus Domino (configured as an LDAP
directory), IBM Directory Server, MS Active Directory, and iPlanet.
Browsers accessing servers must be configured to accept cookies, which
are used to store token containing authentication information.
Optionally, SSO may be set up to work only on encrypted HTTPS
connections.
LTPA is an IBM-specific solution; it did not get industry wide acceptance.
Other application server vendors provide limited (or no) support.

IBM Software Group | Tivoli software

LTPA SingleSignOn
WebSEAL junction needs to be configured:
To generate LTPA token and pass the LTPA cookie having
authentication data to backend.
The administrator enables forms single signon by:
Creating a junction with -A option, for e.g.
pdadmin sec_master> s t default-webseald-tamwps01 create -t tcp -h
tamwas01 -p 9080 -A -F "c:\ltpa\ltpa01.ks" -Z password /ltpajunction
F option specifies the location of the LTPA key file.
LTPA key is exported from the backend (say Websphere) and used
while creating junction.

IBM Software Group | Tivoli software

LTPA Configuration for Websphere


Login to Websphere
Navigate to Security>Global Security and enable LTPA:

IBM Software Group | Tivoli software

LTPA Configuration for Websphere


Navigate to Security>Global Security>LTPA and click on Export
keys:

IBM Software Group | Tivoli software

LTPA SingleSignOn
Now create a WebSEAL junction using below pdadmin command:
pdadmin sec_master> s t <WebSEAL Server> create -t tcp -h <host-ip>
-p <port> -A -F "<path to LTPA key file>" -Z password /<LTPA Junction>

After this access the Junction and see the snoop.

IBM Software Group | Tivoli software

LTPA SingleSignon
In snoop trace we can see LTPA token like below:
WebSEAL to BackEnd
GET /snoop HTTP/1.1
accept: image/gif, image/jpeg, image/pjpeg,application/x-shockwave-flash ...
accept-language: en-us
host: 9.126.185.243:9080
user-agent: Mozilla/4.0, ... via: HTTP/1.1 tamwps01:85
iv_server_name: default-webseald-tamwps01
Cookie:

LtpaToken=Zu16Jr4fxKNxXRxaKCUWDv2rmVwBzXMuHlYi1KtEwZvxXl1E6AvUCQmYbrOOzh3YbjI3MuCOLqtw/makKipRC0
JCzMEwo66445JiBZYY22ntA/vd8cCW+zBNCELK6lCVCWyN2vfCNhP6Ic3gf0LylY3ppx2xe35gu6PmfxQRdKuLw6Jfxh96bCS
3orP1koS9QfkDNOzgWfLpivXUmeb +C6BjECdt5kGYNWrF
W0cWhW8xg7IbVWUzTnhFFy5MN0PRgYXKUAxUhqEqmtPRaqu8pw5bWbiWrLe YgvJaCjT3KzJvFO10qxIw198nUNr7

IBM Software Group | Tivoli software

TAI Overview
What is TAI?
The use of the Trust Association Interceptor (TAI) is similar to LTPA token
passing. However, the credential is passed in the HTTP headers basic
authentication field, instead of being passed as a cookie.
If authentication is being done on a separate system, the server does not
need to do the exact same authentication as long as it knows requests
come from the authentication system.
The server authentication process should be modified to execute two
tasks:
- Make sure that requests come from the authentication server
- Get the identity of users from requests
This process is called the Trust Association Interceptor (TAI).

IBM Software Group | Tivoli software

TAI Overview

IBM Software Group | Tivoli software

TAI Flow

WebSEAL authenticates the user, acquires credentials for the user from the
user registry and authorizes the request.
WebSEAL augments the request with an additional HTTP header (iv-user)
that contains the username. The password contained in the Basic
Authentication header is changed so it matches a configured SSO user. This
request is sent to WAS.
WAS receives the request and calls a TAI method to determine whether the
request is from a perimeter authentication service that has already
authenticated the user.
WAS calls a TAI method to establish trust with the perimeter authentication
server and retrieve the credentials. This method establishes trust with
WebSEAL by checking the BA header contains the correct password for the
configured SSO user. WAS queries ldap and builds credential for the user
presented in iv-user.

IBM Software Group | Tivoli software

TAI++ Overview
What is TAI++?
Advanced TAIs or TAI++ can assert more than just the user's ID. In fact,
they can assert an entire identity including all the group memberships
required to support authorization. In such a case, WebSphere Application
Server will not need to query the user registry.

IBM Software Group | Tivoli software

TAI++ Overview

Build Credential

IBM Software Group | Tivoli software

TAI++ Flow

WebSEAL authenticates the user, acquires credentials for the user from the
user registry and authorizes the request.
WebSEAL augments the request with an additional HTTP header (iv-creds)
that contains the user's credentials. The password contained in the Basic
Authentication header is changed so it matches a configured SSO user. This
request is sent to WAS.
WAS receives the request and calls a TAI++ method to determine whether
the request is from a perimeter authentication service that has already
authenticated the user.
WAS calls a TAI++ method to establish trust with the perimeter
authentication server and retrieve the credentials. It establishes trust with
WebSEAL by contacting TAM Authorization server and checking the BA
header contains the correct password for the configured SSO user.

IBM Software Group | Tivoli software

TAI++ Flow

The iv-creds header is then extracted from the request and used to
construct a PDPrincipal object.
A credential object containing user and group information is constructed
from information contained in the PDPrincipal.
The Principal and the Credential objects are inserted into a JAAS Subject
which is returned from the call.
At this point WAS has valid credentials that it can use for making
authorization decisions in the usual J2EE manner.
In addition, the Subject now contains the PDPrincipal object which
application code can access if needed.

IBM Software Group | Tivoli software

TAI v/s TAI++


TAI
Uses iv-user

TAI++
Uses iv-cred

Only WebSEAL builds credentails


Both WebSEAL and Backend and Backend consumes it for
query ldap to build credential making authoriZation decision
More ldap lookup overhead
Authorization server is not
required

Less ldap lookup overhead


Authorization server is required

IBM Software Group | Tivoli software

TAI++ Configuration : Access Manager

Enable use of Authorization Server


configure WebSphere AMJRTE into TAMs secure domain
create application server using SvrSslCfg

Create a TAM user that represents the trusted server


pdadmin> user create webSealUser "cn=webseal,c=us" webseal WebSEAL passw0rd
pdadmin> user modify webSealUser account-valid yes

For WebSEAL, create a junction that supplies BA header


pdadmin> s t <webseal> create -t tcp -h <host> -p 81 -c iv_creds -b supply /ihs

Configure WebSEAL to supply the dummy password in BA


basicauth-dummy-passwd = passw0rd

Restart WebSEAL

IBM Software Group | Tivoli software

TAI++ Configuration : WebSphere Admin Console

next slide

Configure & Test Global Security Before TAI++

incremental configuration changes best practice

IBM Software Group | Tivoli software

TAI++ Configuration : WebSphere Admin Console II

Stop and restart WebSphere

IBM Software Group | Tivoli software

USE CASE: WebSEAL Integration with IBM Portal Server


This scenario will discuss SingleSignOn using TAI++ between Webseal and the
Portal server
Environment
Tivoli Access Manager:
Pdmgrd V6.1.1 ; ivacld-V6.1.1 ;Webseal-V6.1.1
LDAP IBM Directory Server V6.1
PortalServer: V7.0

IBM Software Group | Tivoli software

Prerequisites
Portal server and Tivoli access manager should share same user registry in this
case, IBM directory server.
Configure the portal server to use federated repository or standalone repository
Make sure the appropriate suffixes are created in IDS and portal server users are
valid TAM users.
Make Sure Authorization server is up and running
Note down the username and password of sec_master, webseal instance name,
authorization server listening port, policy server listening port, policy server
hostname
Note down the WAS and Portal admin password.

IBM Software Group | Tivoli software

LDAP details
In this Demonstration, LDAP has following configuration
TAM suffix secAuthority=Default
TAM suffix c=in
WPS suffix c=wpsin
WPS users cn=users,c=wpsin
WPS groups cn=groups,c=wpsin
Federated Repository is used in Portal Server, which is configured with LDAP
details

IBM Software Group | Tivoli software

Steps to enable TAI++ in portal server


Verify the configured ldap repository
Configure Java runtime and SvrSslCfg Parameter
Validate pdadmin connection
Run-svrssl-config
Configure junction and TAI parameters
Create sso user

IBM Software Group | Tivoli software

Verify Configured Repository


ConfigEngine.bat validate-federated-ldap -DWasPassword=password

IBM Software Group | Tivoli software

Configure AMJRTE and SvrSslCfg Parameter


Modify wkplc_comp.properties at
C:\IBM\WebSphere\wp_profile\ConfigEngine\properties
Modify following parameters
wp.ac.impl.PDAdminId=sec_master
wp.ac.impl.PDAdminPwd=object00
wp.ac.impl.PDPermPath=$
{WasHome}/java/jre/PdPermDemo.properties
wp.ac.impl.PDServerName=demotaiserver
wp.ac.impl.SvrSslCfgPort=7245

IBM Software Group | Tivoli software

Continued..

wp.ac.impl.SvrSslCfgMode=remote
wp.ac.impl.TamHost=tamwps01
wp.ac.impl.PDPolicyServerList=tamwps01:7135:1
wp.ac.impl.PDAuthzServerList=tamwps01:7136:1
wp.ac.impl.PDKeyPath=${WasHome}/java/jre/lib/pdpermdemo.ks

IBM Software Group | Tivoli software

Execute run-svrssl-config
ConfigEngine.bat run-svrssl-config
-Dwp.ac.impl.PDAdminPwd=object00 -WasPassword=wpsadmin
The above command performs two actions:
A. Configuration of the Access Manger Java Runtime
B. Configuring a server definition , alongwith creation of user ,
properties and certificate for JAVA application to Communicate
with TAM component.

IBM Software Group | Tivoli software

Configuration of AMJRTE
The run-svrssl-conf, executes following command to configure
AMJRTE
java -cp C:/IBM/WebSphere/AppServer/java/jre/lib/ext/PD.jar
com.tivoli.pd.jcfg.PDJrteCfg -action config -host tamwps01 -was
-cfgfiles_path C:/IBM/WebSphere/AppServer/java/jre -java_home
C:/IBM/WebSphere/AppServer/java/jre/

Note: You dont need to have AMJRTE component installed on


Portal Server Machine. Portal comes with PD.jar, required to
configure AMJRTE.

IBM Software Group | Tivoli software

SvrSslCfg command
java com.tivoli.pd.jcfg.SvrSslCfg -action config -admin_id
sec_master -admin_pwd ****** -appsvr_id demotaiserver -port
7245 -mode remote -policysvr tamwps01:7135:1 -authzsvr
tamwps01:7136:1 -cfg_file
C:/IBM/WebSphere/AppServer/java/jre/PdPermDemo.properties
-key_file
C:/IBM/WebSphere/AppServer/java/jre/lib/pdpermdemo.ks
It uses the parameters specified in the wkplc_comp.properties
file
It will create a server definition in TAM with a username and
properties file PdPermDemo.properties and key file
pdpermdemo.ks

IBM Software Group | Tivoli software

SvrSslCfg continued
A demotaiserver , definition is created in TAM
A user demotaiserver/tamwps01 is also created which java application
uses to communicate with Policy server
All these values will depend on the parameters mentioned in the
wkplc_comp.properties file

IBM Software Group | Tivoli software

Validate-pdadmin-connection
After run-svrssl-config, validate pdadmin connection is used to check
whether the configuration files , users and server definition and
AMJRTE are correctly configured
ConfigEngine.bat validate-pdadmin-connection
Dwp.ac.impl.PDAdminPwd=object00 -DWasPassword=wpsadmin
Successful run of validate-pdadmin-connection will result in this
message:
PDAdmin and PDContext formed successfully for user: sec_master

IBM Software Group | Tivoli software

Junction Parameters
In the wkplc_comp.properties under topic, Webseal junction
Parameters , specify following
wp.ac.impl.JunctionPoint=/wpsv70
wp.ac.impl.WebSealInstance=default-webseald-tamwps01.com
wp.ac.impl.TAICreds=iv-creds
wp.ac.impl.JunctionHost=${WpsHostName}
wp.ac.impl.JunctionPort = ${WpsHostPort}

IBM Software Group | Tivoli software

TAI++ parameters
wp.ac.impl.hostnames=
wp.ac.impl.ports=
wp.ac.impl.loginId=ssouser
wp.ac.impl.TAICreds=iv-creds
wp.ac.impl.checkViaHeader=false
wp.ac.impl.viaDepth=0
wp.ac.impl.ssoPwdExpiry=600
wp.ac.impl.ignoreProxy=false
wp.ac.impl.BaUserName=wpsadmin
wp.ac.impl.BaPassword=wpsadmin

IBM Software Group | Tivoli software

Execute enable-tam-tai command


ConfigEngine.bat enable-tam-tai -DWasPassword=wpsadmin
-Dwp.ac.impl.PDAdminPwd=object00

The above command will do two things:


A. It will create a junction in Webseal, depending on the junction
parameters mentioned earlier
B.It will enable TAI++ in WAS, with Parameters mentioned in the
Tai configuration in wkplc_comp.properties

IBM Software Group | Tivoli software

Junction Creation: As a result of enable-tam-tai


This step can be done through configEngine or through pdadmin or
Web Portal Manager
For the junction parameters mentioned in wkplc_comp.properties,
following junction command is executed during enable-tam-tai :
server task default-webseald-tamwps01 create -t tcp -h
tamwps01.in.ibm.com -p 10039 -c iv-creds -j -J trailer -b supply -f /wpsv70

Or the above command could be executed directly from pdadmin to


create the junction.

IBM Software Group | Tivoli software

Junction continued.
Details of junction created as viewed from pdadmin

IBM Software Group | Tivoli software

TAI++ setting through enable-tam-tai


Second part enable-tam-tai does is that it enables class
com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus
And sets the Custom properties as provided in the
wkplc_comp.properties file
Check the messages in the notes that were generated for TAI++
Configuration in the WPS, make sure you get the Build
Successful , or the SSO will not work
Next slide will show the screenshot of the custom parameters as
a result of enable-tam-tai

IBM Software Group | Tivoli software

TAI++ custom settings

IBM Software Group | Tivoli software

TAI++ continued
After successfully executing enable-tam-tai, restart the portal
server, both server1 and WepSphere_Portal instance
Another step is the creation of ssouser in TAM which is specified
in TAI++ configuration (wp.ac.impl.loginId=ssouser)
password will be specified in webseal conf file,
basicauth-dummy-passwd = object00

IBM Software Group | Tivoli software

SSO configuration completed


At this point SSO configuration completed
Points to Check
Validate pdadmin is working fine
TAI++ is initializing successfully during startup
The ssouser is valid and password correctly configured
The junction is created and processes are up and running
Portal sever is able to authenticate the users through LDAP

IBM Software Group | Tivoli software

Trouble Shooting Checks


1. Ensure that the TAI initialization is successful.
2. Ensure that Tivoli Access Manager Java runtime environment
(AMJrte) has been configured and that the SvrSslCfg configuration
action has been performed.
3. If only WebSEAL hosts are involved in the source of the request.
Ensure that all trusted WebSEAL hostnames and ports are set correctly
in the respective properties.
4. Ensure that the trusted hostnames are of the correct form. The fully
qualified hostname may be required rather than the short name
5. Ensure that the dummy password in the relevant webseald.conf file for
the WebSEAL instance is set correctly

IBM Software Group | Tivoli software

Trouble Shooting Checks


7. Ensure that the user specified in the login id property has a valid
account.
8. Ensure that the correct headers are being supplied. WebSphere
should get the iv-creds and Basic Authentication headers.
9. Ensure that WebSphere has been restarted if any changes were
made to the configuration.
10. Ensure that the cached password for the single sign-on user has not
been set to never expire and that the single sign-on user password has
changed
11. Invoke TAM java runtime tracing

IBM Software Group | Tivoli software

Tracing
Enable Snoop and Debug to check what is http request and
response between Client , WebSEAL and Backend.
Example:
pdadmin> server task <webseald-server> trace set
pdweb.debug 9 file path=/tmp/webseald.trace/pdweb.debug
pdadmin> server task <webseald-server> trace set
pdweb.snoop 9 file path=/tmp/webseald.trace/pdweb.snoop

IBM Software Group | Tivoli software

Technotes
LTPA Links:

WebSphere Portal prompts a previously-authenticated user to log in again

https://www-304.ibm.com/support/docview.wss?uid=swg21514586

Is the LTPA Cookie supported for use with SAP when no Websphere servers
are involved.

https://www-304.ibm.com/support/docview.wss?uid=swg21424976

Using the "Fewer name variations with higher security" Internet


authentication method to perform single sign-on between Tivoli Access
Manager for e-business and Lotus Domino iNotes/Domino Web Access.

https://www-304.ibm.com/support/docview.wss?uid=swg21441436

IBM Software Group | Tivoli software

Technotes
TAI ++ Links:

TAI++ integration with WebSphere Application Server failing with message


"Basic Authentication Failed"
http://www-01.ibm.com/support/docview.wss?uid=swg21423826

Single sign-on not completing with new TAI++ interceptor


https://www-304.ibm.com/support/docview.wss?uid=swg21305691

IBM Software Group | Tivoli software

Questions & Answers

IBM Software Group | Tivoli software

IBM Software Group | Tivoli software