+

Search Tips   |   Advanced Search

Trusted connections with DB2

Trusted connections allow for the application server to use DB2 Trusted Context objects to establish connections with a user whose credentials are trusted by the DB2 server to open the connection. By establishing a Trusted Context, this user is then trusted to assert other user identities on the DB2 server without the expense of reauthentication. This also enhances the security of our DB2 database by eliminating the need to assign all privileges to a single user. Implementing trusted connections results in client identity propagation while leveraging connection pooling to eliminate the performance penalty of closing and reopening connections with a different identity.

Restriction: To use the trusted connection functionality we must be using DB2 Database for Linux, UNIX, and Windows Version 9.5 or later or DB2 Database v9.1 or later for z/OS . Use trusted connections if version 7.0 is installed on an iSeries system as long as a supported version of DB2 is installed on a platform other than an iSeries system and the DB2 universal driver is being used. See the list of supported software for the application server for more support information.

To reduce the significant expense of establishing new connections, the connection manager maintains a connection pool in which each connection is tracked by the credential originally used to open the connection. When an application needs a connection, the connection manager uses the credential object to match a free connection from the connection pool. If no free connection is available and the maximum number of connections has not been reached, the connection pool manager opens a new connection using that credential object. This connection mapping is the default connection mapping used by the application server and is known as a many-to-one credential mapping because the connection is opened using the credential object in the subject, which is usually not the same as the RunAs identity. This simple mapping supports easy connection pooling, but the caller identity is never propagated to database server.

To propagate the caller identify to the database server, we can plug in a JAAS login module. Using this method, we would map the application server user credential to the user credential suitable for the database server security realm. This approach maintains the caller identity, but does not use connection pooling.

Trusted connections are used instead of the default mapping or a JAAS mapping to connect to the data source. Trusted connections support client identity propagation and can also use connection pooling to reduce the performance penalty of closing and reopening connections with a different identity. Trusted connections use the DB2 trusted context object.

The DB2 trusted context is an object that the database administrator defines and containing a system authorization ID and a set of trust attributes. The trust attributes identify characteristics of a connection required for the connection to be considered trusted. The relationship between a database connection and a trusted context is established when the connection to the DB2 server is created. After a trusted context is defined, and an initial trusted connection to the DB2 database server is made, the application server can use that database connection from a different user without a full reauthentication. This is because an authentication token is required with the user identity. The database authenticates the user and then verifies the user authorization to access the database before allowing any database requests to be processed on behalf of that user.

(ZOS) Restriction: For a z/OS server, the user identity must be the Resource Access Control Facility (RACF ) ID.

Use the trusted connection provides the needed plug-in points to support adding our own secure implementation of the DB2 trusted context. Trusted connections separate the identity used to establish the connection from the identity that accesses the back-end server services. The connection is established by a user whose credentials are trusted by the DB2 server to open the connection. The same user is also then trusted to assert the identity of the other users. This assertion also helps strengthen database security by eliminating the need to grant all privileges to a single user.

When the application requests a connection to the database, the connection manager can find any idle trusted connection and assert the user identity to the backend server. All the operations performed on the backend server are from the asserted user identity. The use of an identity mapping may still be needed if the back-end server uses a different user repository than that of the application server.

A new mapping configuration called TrustedConnectionMapping implements trusted connections. The TrustedConnectionMapping configuration maps the RunAs subject to a resource subject containing the following elements:

The principal object represents the RunAs identity. The PasswordCredential object contains a user ID and password to be used by the resource adapter to establish the trusted connection. The IdentityPrincipal object by default contains the RunAs identity, but can be changed to use the identify of the caller. The IdentityPrincipal object also contains an original user identity that represents the user who sent the request initially, an optional realm name that indicates the set of registries where the user identity is defined and an optional security token, which is a serialized security context of the user.

  • Set the security properties for trusted connections
  • Enable trusted context for DB2 databases
  • Mapping resource manager connection factory references to resource factories
  • Mapping properties for a custom login or trusted connection configuration
  • Map data sources for all 2.x CMP beans settings
  • IBM DB2 Database for Linux, UNIX, and Windows Information Cente