DB2 数据库应用中使用受信任上下文

　　在三层应用程序模型中，中间层（例如 WebSphere Application Server 或 Domino）负责运行客户机应用程序的用户身份验证和管理与数据库服务器的交互。中间层的授权 ID 需要拥有与终端用户相关的所有权限，以便执行终端用户所需的任何操作。虽然三层应用程序模型有很多优点，但是，如果将与数据库服务器的所有交互（例如用户请求）都放在中间层，那么会引起下面提到的一些安全问题。

　　用户身份的丢失： 有些企业想知道访问数据库的所有用户的身份，以便进行访问控制。

　　用户可说明性（accountability）的减弱： 在数据库安全性中，通过审计说明责任是一项基本原则。对于中间层自身执行的事务与中间层代表某些用户执行的事务，数据库应该能够加以区分。

　　权限的过度授予： 中间层的授权 ID，应该拥有执行来自所有用户的所有请求所需的一切权限。但是，这会导致安全问题，即让一些不需要访问某些信息的用户得到这些信息的访问权。

　　安全性的减弱： 除了过度授予权限的问题外，当前的方法还要求，中间层使用的用于连接的授权 ID 必须被授予用户请求可能访问的所有资源上的权限。如果中间层授权 ID 被泄漏，那么所有那些资源都将被暴露。

数据库应用中使用受信任上下文" width="402" height="522" border="0" onload="return imgzoom(this,550);" style="cursor: pointer;" onclick="javascript:window.open(this.src);"/>

　　图 1. 三层应用程序模型

　　显然，需要用一种机制来确保对于中间层代表用户执行的数据库请求，仅使用实际的用户身份和数据库权限。达到这一目标的最简单的方法是让中间层使用用户 ID 和密码建立一个新连接，然后由这个新连接重定向用户请求。这种方法虽然简单，但是存在一些缺陷。很多中间层服务器并没有建立一个连接所需的用户的身份验证凭证。为数据库服务器上的每个用户创建一个新的物理连接，显然会带来额外的性能开销。

　　为了确保对于中间层代表每个用户执行的任何数据库请求，都使用那个用户特定的数据库身份和数据库权限，需要一种更好的方法。为了提高性能，这种方法应允许中间层重用相同的物理连接，而不需要重新在数据库服务器上对用户进行身份验证。这就引出了受信任连接的思想。

　　使用受信任连接

　　为了建立一个受信任连接，必须在 DB2 上创建一个称作受信任上下文的新对象，以便在 DB2 与外部实体（例如一个中间件服务器）之间建立信任关系。受信任上下文 的定义包括要使用受信任上下文并被视作一个受信任的连接的特定连接所需满足的标准。

　　当尝试建立一个受信任连接时，需要评估一系列的信任属性，以决定一个特定的上下文是否是受信任的。当第一次创建到服务器的连接时，就建立了该连接与一个受信任上下文之间的关系，并且在该连接尚未断开期间该关系一直存在。当建立一个受信任连接时，通过允许中间层指定一个新的用户 ID，即可将该连接用于不同的授权 ID，而无需对该用户 ID 进行身份验证（见图 2）。