Introduction

In SOA environments, composite applications can span different administrative domains. Managing user identities across administrative domains is one of the challenges in securing an SOA environment. This article introduces a solution for identity propagation in tiers of a traditional J2EE application where the database tier requires username and password authentication. The concepts used as a basis for implementing a solution are equally applicable across more complex composite applications.

J2EE applications that connect to relational databases via JDBC typically use a single application identity to bind to the database, rather than providing user-specific credentials that would provide greater accountability of the users' activity. Performance reasons are often cited for these design decisions.

Relying on security in the application server as the last line of defense is another common justification. While these reasons might be valid in some circumstances, a stricter audit and compliance requirement demands a more secure solution. Moreover, some flexibility may be required because the user credentials that are presented to the application (e.g. stored in LDAP) may not be the same as the database credentials (for example, stored in the database or on the local operating system).

The solution proposed in this article is to use the Tivoli Federated Identity Manager Security Token Service (TFIM STS) in conjunction with the Tivoli Access Manager Global Sign-On (TAM GSO) capabilities to perform an identity mapping of application server user credentials to database user credentials. To do this, the J2EE application running on WebSphere® Application Server (WAS) invokes a JAAS login module to retrieve authentication credentials for the database. The JAAS module constructs a WS-Trust request and sends it to the TFIM STS to get the identity. The TFIM STS uses a TAM GSO mapping module to call out to TAM and get the database credentials for the user. TFIM then sends this information back to WAS and the J2EE application.

The differences between the typical configuration and the solution proposed in this article are illustrated in Figure 1 and Figure 2.

Obtaining the integration components

Components used in this solution are available from the IBM Support site. Consult the Resources section at the end of this article for links on where to obtain these components.

The TFIM JAAS Login Module is contained in the "TFIM 6.1 CICS Integration Pack".

Note that this particular component has no dependencies on CICS®.

The TAM GSO Mapping Module is contained in the "TFIM 6.1 STS Module for TAM GSO".

Overview of the FIMPrincipalMapper JAAS login module

An application's resource reference for a JDBC datasource can be configured to use a JAAS application login chain to retrieve bind credentials for the database. This is the integration point that the FIMPrincipalMapper leverages. When the JDBC application tries to find the authentication credentials for the data source connection it invokes the JAAS application login chain. This chain contains the FIMPrincipalMapper module. The FIMPrincipalMapper module takes the existing JAAS principal and creates a WS-Trust request. The WS-Trust request contains the JAAS principal in a UsernameToken, along with information about the origin and purpose of the request, via the Issuer and AppliesTo attributes.

The request is then sent to the TFIM STS that is specified by the stsendpoint custom property. After receiving a response from the TFIM STS, the JAAS login module places the credentials in the returned UsernameToken into the JAAS subject. The JDBC application then uses these credentials when making the connection to the database.

Overview of the TFIM STS

The TFIM STS is a WS-Trust compliant service that validates, exchanges and issues security tokens. Within the service is a set of configured module chains called Trust Chains. It is possible to have many trust chains within the service. In order to determine which chain to invoke it looks at the AppliesTo and Issuer elements in the request.

Each trust chain consists of one or more modules that can either validate, map, issue or exchange tokens. The standard chain has the following sequence:

The Validate and Issue modules tend to be modules that are token specific, such as UsernameToken, X509 or SAML. Traditionally, the Map module is a module that runs an XSL stylesheet.

For this article, since the FIMPrincipalMapper module sends and receives Username tokens, it means that the Validate and Issue modules need to be UsernameToken modules. The Map module used in this article is the TAM GSO mapping module.

Overview of the TAM GSO mapping module

This module is a custom TFIM STS module that is configured in Map mode. The module's configuration is performed through TFIM's Management Console. The configuration options are shown in the table below.

The module works by first extracting the name element from the STS Universal User that it receives. Then it uses the TAM Administration API to retrieve mapped user credentials from the GSO data store in TAM. From the result, the returned username and password are retrieved and used to populate the STS Universal User principal attributes Username, name and Password with the corresponding values.

Initial environment

Before you start, you need to have the following components installed and configured to the correct level:

It is also recommended for educational purposes to use tcpmon or a similar TCP proxy so that the WS-Trust request from the FIMPrincipalMapper JAAS module to the TFIM STS can be easily inspected.

Lab environment

The lab environment used for this article is shown in Figure 3.

Configuring static credentials for database access

Before setting up the more advanced configuration of having the mapped credentials presented to the database, the environment needs to be working using a static username and password. This section describes how to do this. If you already have a working data source, JDBC connection and query mechanism (something similar to the Sample JSP that comes with this article), then you can skip this section and go straight to Enabling dynamic credentials for database access.

Setting up a DB2 database

The database that is the backend for the system in this example is a DB2 database. Any JDBC enabled datasource supported by WAS will be sufficient. The important part here is to make sure that only certain users have permission to access the data source.

This example creates a database in the db2admin instance and then grants permission to the webappsvr user. This user must already exist on the system as a valid user (for this example the password for webappsvr is passw0rd). The process consists of:

1. Starting the database manager
2. Creating the database
3. Connecting to the database
4. Creating a table
5. Populating the table
6. Granting privileges for the table

                
# su - db2admin
$ db2start
$ db2
db2 => create database sampledb
DB20000I  The CREATE DATABASE command completed successfully. db2 => connect to sampledb

   Database Connection Information

 Database server        = DB2/LINUX 8.2.1
 SQL authorization ID   = DB2ADMIN
 Local database alias   = SAMPLEDB

db2 => create table employees ( id smallint, name varchar(50) )
DB20000I  The SQL command completed successfully.
db2 => insert into employees values ( 1, 'paul' )
DB20000I  The SQL command completed successfully.
db2 => insert into employees values ( 2, 'alison' )
DB20000I  The SQL command completed successfully.
db2 => insert into employees values ( 3, 'emily' )
DB20000I  The SQL command completed successfully.
db2 => select * from employees

ID     NAME
------ --------------------------------------------------
     1 paul
     2 alison
     3 emily

  3 record(s) selected.

db2 => grant select on employees to user webappsvr
DB20000I  The SQL command completed successfully.
      

Configuring the JDBC datasource

Before you can use a JSP or EJB that utilizes JDBC connections in WAS you must configure the resources in the application server. There are three things needed to configure:

• A J2C alias, which is a static username and password used for authentication to the backend. This is the option that we will be changing later on in the article.
• A JDBC provider for the database type.
• The datasource that utilizes the JDBC provider.

The J2C alias is the traditional way for J2EE datasource connections to be authenticated. A static username and password is given for authentication. In this example we will be using the webappsvr/passw0rd credentials to authenticate. To create the alias in WAS V6.1 do the following:

1. Log into the WebSphere Administration Console: https://WAS_HOST:9043/ibm/console
2. Go to Security -> Secure administration, applications, and infrastructure -> Java Authentication and Authorization Service -> J2C authentication data.
3. Click New.
4. Enter the information for the webappsvr user. An example is shown in the table below.
   
   

   Name	Value
   alias	webappsvr
   username	webappsvr
   password	passw0rd
   Description	User for connection to DB2 datasource

   
   
   
5. Click OK and save the configuration.

Now that you have a J2C alias, if a JDBC provider for your database is not already configured in WAS then you will need to configure one. Before you start do the following:

• Verify that the database and JDBC provider is supported by WAS. For more information see the information center.
• Create and configure any required databases or tables and verify that you can connect to the databases using the database vendor tools.
• Install the database client drivers on the same node as the WAS that accesses the database. This normally involves copying jars onto the Node from the machine hosting the database. For DB2 it is all the files in the DB2_HOME/java directory.

To create the JDBC provider in WAS 6.1 do the following:

1. Log into WAS administation console: https://WAS_HOST:9043/ibm/console
2. Go to Resources -> JDBC -> JDBC Providers
3. Change scope to: Node=node-name, Server=server1
4. Click New
5. Select the options specified in the table below.
   
   

   Name	Value
   Database type	DB2
   Provider type	DB2 Universal JDBC Driver Provider
   Implementation type	Connection pool datasource
   Name	DB2 Universal JDBC Driver Provider
   Description	Leave as the default unless you want to write something special

   
   
   
6. Click Next.
7. Place into the Class path the directory that corresponds to the location of the client drivers that were copied to the WAS node. This gets stored in WAS as ${DB2UNIVERSAL_JDBC_DRIVER_PATH}. For example: /opt/IBM/db2/V8.1/java. You can leave Native library path ${DB2UNIVERSAL_JDBC_DRIVER_NATIVEPATH} blank.
8. Click Next.
9. Review summary and then press Finish.
10. Save the configuration and then restart the application server.

The next step is to create a datasource that uses the JDBC provider. To do this follow the following steps:

1. After logging into the WAS Administrative Console, select the JDBC Provider created in the previous section. This is done by going to Resources -> JDBC -> JDBC Providers and clicking on the JDBC provider created earlier.
2. Under Additional Properties click on Data sources.
3. Click New.
4. Enter a JNDI name, for example: jdbc/sampledb. Even though you will be overriding the authentication alias at the application's resource reference it helps for debugging to choose to the J2C alias created earlier. So under Component-managed authentication alias and XA recovery authentication alias select the webappsvr J2C alias.
5. Click Next.
6. Add the configuration options for your database. Look at the table below for examples.
   
   

   Name	Value
   Database name	sampledb
   Driver type	4
   Server name	rhel-ldap.dp.gc.au.ibm.com
   Port number	3700 Note: The default for DB2 is 50000
   Use this datasource in container managed persistence (CMP)	selected

   
   
   
7. Click Next.
8. Review the summary and click Finish.
9. Save the configuration.
10. Navigate to the datasource screen (Resources -> JDBC -> Data sources), select the newly created JDBC datasource and then click Test Connection. You should not receive any errors and the test should complete successfully. If errors occur, these need to be resolved before proceeding.

Installing the sample application

To install the sample application that uses JDBC from the resources section of this article, complete the following steps.

1. Log in to the WAS Administrative Console.
2. Go to Applications -> Install New Application.
3. Navigate to the location of the supplied JDBCWebApp.war.
4. Specify a Context root such as JDBCWebApp.
5. Click Next.
6. Accept the installation options by clicking Next.
7. Check which servers you want the application deployed to and accept the module to server mappings by clicking Next.
8. On the Resource reference page, click the Browse button below the textbox referring to the JDBCWebApp module in the Target Resource JNDI Name column. Select the datasource created earlier and then click Apply. Select the datasource created earlier and have the JNDI name of the datasource in the textbox.
9. Still on the Resource reference page, select the JDBCWebApp module. Under Specify authentication method, select Use default method (many-to-one mapping) and then choose the J2C authentication alias that corresponds to the database user (webappsvr). Click the Apply button in the Specify authentication method section.
   
   Figure 6. Specifying a static authentication alias
   
   
   
10. Click Next.
11. Review the summary and click Finish.
12. Wait for installation to successfully complete and save the configuration.
13. The application should now show in the list of installed applications (Applications -> Enterprise Applications).
14. Now set the security roles by first clicking on JDBCWebApp_war on the list of installed applications. Click on Security role to user/group mapping and select All authenticated?. At this moment, anyone is authenticated. Later we will set it so that only Web database users are allowed to access the JSP.
    
    Figure 7. Specifying initial security role mappings
    
    
    
15. Click OK and save the configuration.
16. Start the application by selecting it from the list of installed applications and then clicking Start. You should receive a success message and a green arrow next to the application to show that it has started.

Please note that if you receive an Error 500 code while using the JSP with DB2 it could be due to APAR LI70602. Basically, some DB2 JCC JDBC drivers fail when they try to retrieve error messages from the database server. The JSP cannot catch the exception and will fail. To fix this you, can install the latest fix pack or set the retrieveMessagesFromServerOnGetMessage to false. Please refer to http://www-1.ibm.com/support/docview.wss?uid=swg1LI70602 for details.

Enabling dynamic dredentials for database access

This section describes how to present mapped user credentials to the database. This is achieved using a JAAS login module which calls the TFIM STS. The STS then maps the identity using TAM GSO resource identity mapping. The new credentials are returned to the application server and used for database access.

Configuring the GSO resource in TAM

If you haven't already done so, you need to install and configure a TAM Policy Server and Authorization Server. Please refer to the product documentation for details on how to do this. After you have a configured TAM, then follow these steps:

1. Create a TAM user for the Web user who will be allowed to access the JSP. Make sure that they are a GSO user:
   
   Listing 2. Creating the Web user in TAM
   

   # pdadmin -a sec_master pdadmin sec_master> user create -gsouser webuser1 cn=webuser1,o=ibm,c=au "Web User" User passw0rd pdadmin sec_master> user modify webuser1 account-valid yes

   
   
2. Create a GSO resource and a resource credential for the web user associated with that resource:
   
   Listing 3. Creating the GSO resource and resource credential
   

   pdadmin sec_master> rsrc create backend_database pdadmin sec_master> rsrccred create backend_database rsrcuser dbuser1 rsrcpwd passw0rd rsrctype web user webuser1

   
   

Configuring the TFIM STS trust chain

The TFIM STS is used to call TAM and do the credential mapping. It receives a WS-Trust request from the JAAS login module in the application server hosting the JDBC application. This request contains a Username token representing the user logged into WAS. The chain then uses the TAM GSO STS Module to map the credential. Finally, the new credential is passed back as a Username token with a username and plaintext password.

A TFIM runtime and domain must already exist and be operational before continuing.

1. First, the TAM GSO STS Module is installed:
   • Place the tamgso_sts_module.jar in a temporary directory and then expand it into the TFIM plug-ins directory.
     
     Listing 4. Placing the TAM GSO STS module into the TFIM plug-ins directory
     

     # cd /opt/IBM/FIM/plugins # /opt/IBM/WebSphere/AppServer/java/bin/jar -xvf /wdir/tamgso_sts_module.jar created: META-INF/ extracted: META-INF/MANIFEST.MF created: com.tivoli.am.fim.tamgsoplugin_1.0/ extracted: com.tivoli.am.fim.tamgsoplugin_1.0/module.xml extracted: com.tivoli.am.fim.tamgsoplugin_1.0/tam_gso_classes.jar # ls -al com.tivoli.am.fim.tamgsoplugin_1.0/ total 25 drwxr-xr-x 2 root root 120 Oct 24 07:30 . drwxr-xr-x 17 root root 808 Oct 24 07:30 .. -rw-r--r-- 1 root root 2648 Oct 24 07:30 module.xml -rw-r--r-- 1 root root 17703 Oct 24 07:30 tam_gso_classes.jar

     
     
   • For the console to be able to display the labels for the module, it needs to have the module's labels class in its classpath. To fix this, copy tam_gso_classes.jar to the following path on the machine hosting the ISC: ISC_HOME/PortalServer/installedApps/FIMConsole_*.ear/*.war/WEB-INF/lib/tam_gso_classes.jar . Restart the ISC portal to load the classes.
   • TFIM needs to know that there has been a change to the runtime's plug-ins. To do this, edit software.properties located in FIM_HOME/pkg. Increment the com.tivoli.am.fim.rte.software.serialId value by one.
   • Deploying the new runtime is done through the ISC. Log on to the ISC and then navigate to the domains runtime management (Tivoli Federated Identity Manager -> Domain Management -> Runtime Node Management). There should be a message that a new runtime is available. Click the Deploy Runtime button and then restart the server.
2. You then need to configure TFIM, so that the module is available for the TFIM STS:
   • Log into the ISC and navigate to Tivoli Federated Identity Manager -> Configure Trust Service -> Module Types.
   • Click Create and enter the information shown in the table below Click OK after completing the input.
     
     

     Name	Value
     Module Name	com.tivoli.am.fim.sts.tamgso
     Module Version Number	1.0
     Exposed Class ID	TAMGSOSTSModule

     
     
     
     
     Figure 9. Creating the TAM GSO mapping module type
     
     
     
   • Restart the server (the TFIM runtime).
3. Create an instance of the TAM GSO Module so that it can be used in chains. To do this:
   • Log into the ISC and navigate to Tivoli Federated Identity Manager -> Configure Trust Service -> Module Instances, clicking Create.
   • Select the TAMGSOSTSModule token type and click Next.
     
     Figure 10. Creating the TAM GSO mapping module instance
     
     
     
   • Enter an appropriate instance name and description and then click Finish.
   The same must be done to create a Username Token module instance. The difference being that the UsernameTokenSTSModule token type is used.
4. Now we can create a Trust Service Chain that will handle our request. To do this:
   • Log in to the ISC and navigate to Tivoli Federated Identity Manager -> Configure Trust Service -> Trust Service Chains, and click Create.
   • Read the introduction and click Next.
   • Name the chain something relevant, for example UT-TAMGSO-UT and then click Next.
   • Leave the request type as Validate and fill in the attributes as shown in the table below. Take note of the Applies To and Issuer addresses as you will need these for the FIMPrincipalMapper JAAS module configuration as shown in Figure 15.
     
     

     Name	Value
     Applies To Address	http://appliesto/tamgso
     Issuer Address	http://issuer/websphere

     
     
     
     
     Figure 11. Specifying issuer and applies to for the trust chain
     
     
     
   • Click Next.
   • Add the modules listed in the table below with their corresponding modes to the chain.
     
     

     Order	Module instance	Module type	Mode
     1	UTModuleInstance	UsernameTokenSTSModule	validate
     2	TAMGSOInstance	TAMGSOSTSModule	map
     3	UTModuleInstance	UsernameTokenSTSModule	issue

     
     
     
     
     Figure 12. Specifying trust chain tokens
     
     
     
   • Click Next.
   • For the validating Username Token module, check the Skip password validation checkbox and click Next.
   • For the mapping TAM GSO STS Module, enter the information specific for environment. You can use the amconfig.conf file that was generated for the runtime. This file is located in WAS_HOME/profiles/PROFILE_NAME/config/itfim/TFIM_DOMAIN_NAME/nodes/CELL_NAME/NODE_NAME/server1/amconfig.conf The example uses the values in the table below.
     
     

     Name	Value
     The TAM Administrative user, default: sec_master	sec_master
     The TAM Administrative user password	passw0rd
     The URL that points to the TAM configuration file amconfig.conf, example: file:///var/amwas/amconfig.conf.	file:///opt/IBM/WebSphere/AppServer/profiles/AppSrv01/config/itfim/sles9-fim61-server1/nodes/sles9-fim61Node01Cell/sles9-fim61Node01/server1/amconfig.conf
     The TAM GSO resource name	backend_database

     
     
     
     
     Figure 13. TAM GSO module trust chain configuration
     
     
     
   • Click Next.
   • For the issuing Username Token module, make sure that the password is being sent as plaintext. Do this by changing the Options for including password in the token to 3 and then clicking Next.
   • Review the summary and then click Finish.
   • Restart the server (the TFIM runtime).

Configuring WAS to call the TFIM STS

The application server that is hosting the JSP must to be configured to call out to the TFIM STS to get the credentials for the back-end datasource. This is done by creating a JAAS application login chain. This login chain contains the FIMPrincipalMapper JAAS login module only. The chain is then specified as the authentication mechanism for the JDBC application's resource reference.

To do this follow these steps:

1. Place the jar files that contain the FIMPrincipalMapper and its supporting classes into the WAS classpath. Copy soa-common.jar, soa-wstrust-client-impl.jar, soa-jaas-login.jar and soa-wstrust-client-intf.jar into WAS_HOME/lib/ext/ for the application server hosting the Sample JSP.
2. Restart the application server.
3. Log in to the WAS administrative console and navigate to Security -> Secure administration, applications, and infrastructure -> Java Authentication and Authorization Service -> Application logins.
4. Click New.
5. Give the chain an appropriate name, for example FIMforDB2.
6. Click Apply.
7. Click JAAS login modules.
8. Click New.
9. Enter the Module class name as com.tivoli.am.fim.jaas.login.loginmodules.FIMPrincipalMapper. Select the Use login module proxy checkbox, specify the Authentication strategy as REQUIRED and then click Apply.
   
   Figure 14. Application login JAAS module chain
   
   
   
10. Click Custom properties.
11. Leave the delegate property as it is (should be com.tivoli.am.fim.jaas.login.loginmodules.FIMPrincipalMapper). Create the properties as shown in the table below.
    
    

    Name	Value
    cache_cleanup_interval	10
    cache_expiration_interval	30
    appliesto	http://appliesto/tamgso
    issuer	http://issuer/websphere
    stsendpoint	http://TCPMON_HOST:TCPMON_PORT/TrustServer/SecurityTokenService

    
    
    Please note that tcpmon must be configured to forward requests to the TFIM STS. If you don't have tcpmon then you can set the value for stsendpoint to point directly to the be TFIM STS.
    
    Figure 15. FIMPrincipalMapper module configuration
    
    
    
12. Save the configuration.
13. Now change the applications resource reference so that it uses the login module for the authentication method. This is done by:
    • In the WebSphere Administration Console navigate to Applications -> Enterprise Applications -> JDBCWebApp_war -> Resource references
    • Select the JDBCWebAPP QueryReference resource reference. While it is selected, choose Use custom login configuration and then select the FIMforDB2 JAAS login chain.
    • Click Apply.
    • Save the configuration.
    
    
    Figure 16. Selecting JAAS login chain for resource reference
    
    
    
14. Now change the security roles for the JDBCWebApp so that only the Web user can access the JSP. This is done by:
    • In the WebSphere Administration Console navigate to Applications -> Enterprise Applications -> JDBCWebApp_war -> Security role to user/group mapping.
    • Select the role inboundUser and click Look up users.
    • Click the Search button to bring up a list of users in the Available column.
    • Select webuser and then press the >> button so that it appears in the Selected column.
    • Press OK and make sure that webuser shows up in Mapped users.
    • For the role inboundUser unselect All authenticated? and then press OK.
      
      Figure 17. New security role mappings for sample JDBC application
      
      
      
    • Save the configuration.
15. Restart the JDBCWebApp application.

Following the credential flow

When using the application, there are five different events of interest when monitoring which user is being used. They are:

1. Who is logging into the JSP application.
2. The user in the UsernameToken being sent to the TFIM STS.
3. The mapping of the GSO user at the TAM authorization server.
4. The user in the UsernameToken being sent back from the TFIM STS.
5. The user being presented to the datasource.

The first event is enforced by WebSphere Application Server application security. The users that are granted access to the JDBCWebApp are specified in the application's security roles. For this exercise, you can see what user is logged in on the JSP. This should be webuser1. You can also view the trace file for the server. Just turn on tracing, and add com.tivoli.am.fim.jaas.login.loginmodules.FIMPrincipalMapper=all to the Log Details Levels of the server hosting the JDBC application. Look at trace.log in the profile's server1 log directory.

To view the second event you have two options. The first is to look at the WS-Trust message sent over the wire. This is done by looking at the tcpmon output for the communication between WAS and TFIM. The second is to use the tracing logs of the TFIM runtime. To turn on tracing, add com.tivoli.am.fim.*=all to the Log Details Levels of the server hosting the TFIM runtime. Look at trace.log in the profile's server1 log directory. You should see webuser1 being sent to the STS. The third and fourth events can also be seen in the TFIM runtime trace log. This can be viewed by looking at the audit logs of DB2 or by viewing the trace log of the application server hosting the JDBC application. Take a look at Listing 5 for details on how to record and look at DB2 audit events.
Listing 5. Configuring auditing for checking in DB2

                    
db2admin$ # Before making a connection run:
db2admin$ db2audit configure scope all status both
db2admin$ db2audit start
db2admin$ # After making a connection to the database run:
db2admin$ db2audit flush
db2admin$ db2audit extract file TMP_DIR/db2audit_sampledb.log database sampledb
      

Provisioning GSO credentials

In the example provided in this article, a user's identity needs to be configured in multiple locations:

• Configured directory for WebSphere Application Server
• Configured directory for Tivoli Access Manager (the same directory as used by WAS in this case)
• The TAM GSO storage (in the TAM directory)
• DB2 database (or local OS)

Tivoli Identity Manager (TIM) is a user provisioning solution that provisions accounts across a variety of systems, incorporating workflow and a high degree of automation. TIM can provision user accounts for the systems described immediately above. Then, with TIM password synchronization capabilities, the credentials in the TAM GSO repository can be kept synchronized with the credentials in the store used by DB2 (database or OS).

Conclusion

This article provided an example of how the identity of a requester can flow through the tiers of an application, all the way to the database. To achieve this, two published integrations with Tivoli Federated Identity Manager are utilized:

• JAAS login module that invokes the TFIM Trust Service
• TAM GSO mapping module for TFIM Trust Service

Examples such as these show how the challenging identity management requirements of composite applications in SOA environments can be met.

Back to top

Download

Information about download methods

Resources

Learn

• " Implementing and deploying custom trust modules " (developerWorks, Nov 2005) explains the basics of developing custom token modules for TFIM.
  
  
• For reference information and product documentation for Tivoli Federated Identity Manager, visit the Federated Identity Manager Information Center .
  
  
• For reference information and product documentation for WebSphere Application Server, visit the WebSphere Application Server Version 6.1 Information Center , WebSphere Application Server, Version 6.0 Information Center or the WebSphere Application Server Library
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Get products and technologies

• Download the TFIM 6.1 CICS Integration Pack.
  
  
• Download the TFIM 6.1 STS Module for TAM GSO.
  
  

Discuss

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the authors

Paul Winters is an Identity Management Consultant for Loop Technology, an IBM business partner. His focus is on Enterprise Security and he specializes in SOA Security. His role includes designing and deploying security and integration solutions using the Tivoli Security and WebSphere product suites. His previous role was Software Engineer in the Tivoli Security section of the Australia Development Labs.

Neil Readshaw is a Senior Security Architect in the Tivoli Security Team based on the Gold Coast, Australia. In this role, Neil works with customers to define solutions using the Tivoli Security software suite, and works in an enablement role with IBM Business Partners and the IBM technical sales team in the Asia Pacific region.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Initial environment
• Configuring static credentials for database access
• Enabling dynamic dredentials for database access
• Following the credential flow
• Provisioning GSO credentials
• 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

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers