Scenario: End-to-end federated trusted connections, without user mappings

User mappings require a significant amount of administrative maintenance. This scenario illustrates how to configure federated trusted connections so that the federated system does not require user mappings.

User ID and password requirements

To set up federated trusted contexts without using user mappings, the user IDs and passwords must meet these requirements:
  • The user ID and password for the connection originator must be available to the federated server, and the connection originator's user ID and password must be the same on the federated server and on the data source. The credentials are identified in a CONNECT statement that the connection originator issues or in an API call that the application makes. If the CONNECT statement is used, an implicit trusted connection is created, and the connection cannot be reused. If the application makes an API call and explicitly requests a trusted connection, an explicit trusted connection is created, and the connection can be reused.
  • If the remote trusted context allows connection reuse without authentication, connection re-users must have the same user ID on the federated server and on the remote data source.
  • If the remote trusted context allows connection reuse with authentication, connection re-users must have the same user name and password on the federated server and on the remote data source.

The scenario

The following figure illustrates a typical multi-tier federated system that is configured to use end-to-end federated trusted connections. Although this scenario includes an application server, any database client can establish a trusted connection.
Federated system that illustrates end-to-end federated trusted connections that do not require user mappings
This scenario has two users, neither of whom require a user mapping:
  • BOSS has the same user ID and password on the federated server and on the data source. Therefore, BOSS does not require a user mapping.
  • Mary uses the same user ID on the federated server and on the data source, and the federated context allows her to connection without authenticating. Therefore, she does not require a user mapping.
The scenario has three servers:
  • The application server, which hosts the insurance application and has the IP address 9.44.111.111.
  • The federation server, which has the IP address 9.44.111.222.
  • The remote database server, which is cataloged on the federated server as JUPITER.

The following steps describe the configuration of this scenario.
Note: In the commands, object names that are variable display in italics. When you implement trusted contexts, specify variable names that apply to your specific system configuration.
  1. On the remote database server, create this trusted context object: 
    CREATE TRUSTED CONTEXT MY_DB2_TCX

BASED UPON CONNECTION USING

SYSTEM AUTHID BOSS

ATTRIBUTES (ADDRESS '9.44.111.222')

WITH USE FOR PUBLIC WITHOUT AUTHENTICATION

ENABLE

    This trusted context specifies that BOSS is the trusted connection originator and that the connection request must come from IP address 9.44.111.222, which identifies the federation server. The trusted context specifies WITH USE FOR PUBLIC WITHOUT AUTHENTICATION. Consequently, after the trusted connection is established, any valid user of the remote data source can reuse the connection by providing only a user ID.

  2. On the federation server, create this trusted context object:
    CREATE TRUSTED CONTEXT MY_WFS_TCX

BASED UPON CONNECTION USING

SYSTEM AUTHID BOSS

ATTRIBUTES (ADDRESS '9.44.111.111')

WITH USE FOR PUBLIC WITHOUT AUTHENTICATION

ENABLE

    This trusted context specifies that BOSS is the trusted connection originator and that the request for the connection must come from the IP address 9.44.111.111, which identifies the application server. After the trusted connection is established, any valid user of the federated server can reuse the connection by providing only a user ID.

  3. On the federation server, create this server definition: 
    CREATE SERVER JUPITER TYPE db2/udb

 VERSION 9.5 WRAPPER drda... 

 OPTIONS(DBNAME 'remotedb', ...);

    This server definition contains the information that the federated server requires to connect to the remote database named remotedb.

The scenario, step-by-step

This is a brief step-by-step description of how trusted connections are made and how users are switched in this scenario. The scenario code includes comments that describe how the application accomplishes these tasks.
  1. The application server requests a trusted inbound connection for BOSS.
  2. BOSS performs a task, and the federated server establishes an explicit outbound trusted connection for BOSS. User ID BOSS is propagated from the application server through the federation server to the database server, where the actions that BOSS performs can be audited.
  3. Mary logs into the insurance application which is on her laptop. The application server switches the inbound connection to the federated server from BOSS to Mary.
  4. Mary performs a task within the application.
  5. The federation server switches the outbound connection from BOSS to Mary, and her ID is propagated through the federation server to the server, where the actions that Mary performs can be audited.