Types of federated trusted connections

Federated trusted connections are either end-to-end trusted connections or outbound trusted connections. Which type of connection is made depends on how you configure the system and whether or not the inbound connection request is trusted.

A typical federated configuration is multi-tier; that is, it includes an application server, a federated server, and a remote data source server. In this configuration, the federated server receives inbound connection requests from the application server and sends outbound connection requests to the data source server.

End-to-end federated trusted connections

An end-to-end federated trusted connection provides connection reuse and identity assertion for both inbound and outbound connections. For example, when an inbound connection to the federated server is trusted, either explicitly or implicitly, the federated server automatically requests an outbound trusted connection. If the data source provides identity-assertion functionality, a trusted outbound connection is made; and the user's identity is propagated to the remote data source. The inbound and outbound connections are reused each time another user requests to reuse the trusted connection, and that new user's identity is propagated through the system.

For data sources that do not provide identity-assertion functionality, the federated server provides end-to-end identity assertion but does not provide connection reuse. In those cases, each time the user is switched, the federated server closes the outbound connection for the previous user and creates a new connection for the new user. By doing so, the user's identity is propagated through the system, even though the outbound connection is not reused.

Outbound federated trusted connections

An outbound federated trusted connection leverages the ability of data sources to reuse trusted connections without authentication to eliminate the need to store data-source passwords in user mappings. If the inbound connection is trusted, the federated server automatically requests a trusted outbound connection that is reused without authentication. For non-trusted inbound connections, outbound federated trusted connections provide the ability to reuse connections without requiring users to authenticate.

In this configuration, you use the FED_PROXY_USER option in the server definition to specify the authorization ID that initially establishes the outbound connection. The authorization ID that you specify must have a user mapping that includes both the REMOTE_AUTHID and REMOTE_PASSWORD options.

Depending on how you configure the trusted context on the remote data source server, you can reduce the number of user mappings in the database catalog to as few as one. For example, if you allow PUBLIC to connect without authentication, then only the federated proxy user requires a user mapping. However, if the federated trusted context on the remote data source specifies that certain users must authenticate or if users do not use the same user ID on the federated server and on the remote data source, you must create or alter the user's user mapping to use only the REMOTE_AUTHID option, to use only the REMOTE_PASSWORD option, or to use both the REMOTE_AUTHID option and the REMOTE_PASSWORD option; and you must set the USE_TRUSTED_CONTEXT option to 'Y'.

Because there are significant additional configuration and maintenance tasks affiliated with outbound federated trusted connection, design the federated system to implement end-to-end trusted connections wherever possible. Then use outbound federated trusted connections only where absolutely necessary.

Example

In this example, the administrative task scheduler (ATS) runs a task that is calling a federated stored procedure. The authorization ID for the ATS task is the db2admin ID. When you use the ATS and federation, you need to use the current user ID and ensure that you establish the following settings:
  • Use the current user ID rather than the administrative ID (that runs db2acd) to run ATS tasks.
  • Create user mappings for both the current user ID and the administrative ID.
  • Set the USE_TRUSTED_CONTEXT user mapping option to Y for both IDs.