Use trusted context in DB2 database applications

In a layer-3 Application model, the middle layer (such as WebSphere Application Server or Domino) is responsible for user authentication for running client applications and managing interaction with database servers. The authorization ID of the intermediate layer must have all the permissions related to the end user to perform any operations required by the end user. Although the three-tier application model has many advantages, if you place all the interactions with the database server (such as user requests) in the middle layer, it will cause the following security issues.

Loss of user identity: some enterprises want to know the identity of all users accessing the database for access control.

Reduction in user accountability: In database security, it is a basic principle to describe responsibility through audit. For transactions executed by the middle layer itself and transactions executed by the middle layer on behalf of some users, the database should be able to differentiate.

Excessive permission granting: The authorization ID of the middle layer, which must have all permissions required to execute all requests from all users. However, this may cause security issues, that is, users who do not need to access certain information can obtain access to this information.

Security compromise: In addition to excessive permission granting, the current method also requires that the authorization ID used by the middle layer for connection must be granted permissions on all resources that the user may access. If the authorization ID of the intermediate layer is leaked, all those resources will be exposed.

Figure 1. layer-3 Application Model

Obviously, a mechanism is needed to ensure that only the actual user identity and database permissions are used for database requests that the middle layer represents the user. The simplest way to achieve this goal is to allow the middle layer to establish a new connection using the user ID and password, and then redirect the user request by the new connection. This method is simple but has some defects. Many Intermediate Layer servers do not have the authentication creden。 required for establishing a connection. Creating a new physical connection for each user on the database server clearly introduces additional performance overhead.

A better method is required to ensure that the user-specific database identity and database permissions are used for any database requests that the middle layer represents each user. To improve performance, this method should allow the middle layer to reuse the same physical connection, without re-Verifying the user's identity on the database server. This leads to the idea of trusted connections.

1 2 3 4 Next Page

[Content navigation]
Page 1st: Use trusted context in DB2 database applications	Page 1: Use trusted connections
Page 1: Define a trusted Context	Page 1: Trusted connections in CLI applications