首页 > Linux操作系统 > Linux操作系统 > DB2安全机制(1)-受信任连接
在三层应用程序模型中,中间层(例如 WebSphere Application Server 或 Domino)负责运行客户机应用程序的用户身份验证和管理与数据库服务器的交互。中间层的授权 ID 需要拥有与终端用户相关的所有权限,以便执行终端用户所需的任何操作。虽然三层应用程序模型有很多优点,但是,如果将与数据库服务器的所有交互(例如用户请求)都放在中间层,那么会引起下面提到的一些安全问题:
显然,需要用一种机制来确保对于中间层代表用户执行的数据库请求,仅使用实际的用户身份和数据库权限。达到这一目标的最简单的方法是让中间层使用用户 ID 和密码建立一个新连接,然后由这个新连接重定向用户请求。这种方法虽然简单,但是存在一些缺陷。很多中间层服务器并没有建立一个连接所需的用户的身份验证凭证。为数据库服务器上的每个用户创建一个新的物理连接,显然会带来额外的性能开销。
为了确保对于中间层代表每个用户执行的任何数据库请求,都使用那个用户特定的数据库身份和数据库权限,需要一种更好的方法。为了提高性能,这种方法应允许中间层重用相同的物理连接,而不需要重新在数据库服务器上对用户进行身份验证。这就引出了受信任连接的思想。
为了建立一个受信任连接,必须在 DB2 上创建一个称作受信任上下文的新对象,以便在 DB2 与外部实体(例如一个中间件服务器)之间建立信任关系。受信任上下文 的定义包括要使用受信任上下文并被视作一个受信任的连接的特定连接所需满足的标准。
当尝试建立一个受信任连接时,需要评估一系列的信任属性,以决定一个特定的上下文是否是受信任的。当第一次创建到服务器的连接时,就建立了该连接与一个受信任上下文之间的关系,并且在该连接尚未断开期间该关系一直存在。当建立一个受信任连接时,通过允许中间层指定一个新的用户 ID,即可将该连接用于不同的授权 ID,而无需对该用户 ID 进行身份验证(见下图)。
受信任上下文是根据系统授权 ID 和一组或多组连接信任属性定义的一种新对象。每个受信任上下文都用一个相关的系统授权 ID 和一组或多组连接信任属性标识,其中每组定义至少一个连接信任属性:
假设一个管理员希望当系统授权 ID 为 NEWTON,且 TCP/IP 地址属性为 9.26.146.201 时,任何连接都被视作受信任连接。那么,该管理员可以像下面这样定义受信任上下文:
CREATE TRUSTED CONTEXT ctxName1 BASED UPON CONNECTION USING SYSTEM AUTHID newton ATTRIBUTES ( PROTOCOL 'TCPIP', ADDRESS '9.26.146.201', ENCRYPTION 'NONE' ) ENABLE ALLOW USER zurbie |
如果从 IP 地址 9.26.146.201 使用 TCP/IP 协议和授权 ID NEWTON 建立一个连接,那么在这个连接的属性和前面定义的受信任上下文 ctxName1 之间存在匹配,而加密则被忽略。
管理员还可以通过使用 ALTER TRUSTED CONTEXT 和 DROP TRUSTED CONTEXT 语句修改和删除受信任上下文对象。
JDBC 应用程序中使用受信任连接
IBM DB2 Driver for JDBC 和 SQLJ 提供了允许在 Java 程序中建立和使用受信任连接的方法。为了避免对安全漏洞的攻击,使用这些受信任方法的应用服务器不应该使用不受信任的连接方法。
DB2ConnectionPoolDataSource 类提供了几种版本的 getDB2TrustedPooledConnection 方法,DB2XADataSource 类提供了几种版本的 getDB2XAConnection 方法,这些方法使应用服务器可以建立初始受信任连接。可以根据传递的连接属性的类型以及是否使用 Kerberos 安全性,选择其中一个方法。当应用服务器调用其中一个方法时,IBM DB2 Driver for JDBC 和 SQLJ 返回一个包含两个元素的 Object[] 数组:
DB2PooledConnection 类提供了几种版本的 getDB2Connection 方法,DB2Connection 类提供了几种版本的 reuseDB2Connection 方法,这些方法使应用服务器可以以新用户的身份重用已有的受信任连接。应用服务器使用该方法将以下项目传递给新用户:
JDBC 驱动程序检查提供的 cookie 是否与底层受信任物理连接相匹配,以确保连接请求是由建立受信任的物理连接的应用服务器发起的。如果 cookie 匹配,则这个新用户可以直接用新的连接属性使用该连接。
#--------------------------------------------------------------------------- #-- JDBC example #-- Test a Trusted Context on the connection #--------------------------------------------------------------------------- /* The first item that was obtained from the previous */ getTrustedPooledConnection /* Call is a connection object. Cast it to a PooledConnection object. */ javax.sql.PooledConnection pooledCon = (javax.sql.PooledConnection)objects[0]; properties = new java.util.Properties(); // Set new properties for the reused object using // properties.put("property", "value"); // The second item that was obtained from the previous getTrustedPooledConnection /* call is the cookie for the connection. Cast it as a byte array. */ byte[] cookie = ((byte[])(objects[1]); /* Supply the user ID for the new connection. */ String newuser = "newuser"; // Supply the name of a mapping service that maps a workstation user // ID to a z/OS RACF ID String userRegistry = "registry"; /* Do not supply any security token data to be traced. */ byte[] userSecTkn = null; /* Do not supply a previous user ID. */ String riginalUser = null; // Call getDB2Connection to get the connection object for the new // user. java.sql.Connection con = ((com.ibm.db2.jcc.DB2PooledConnection)pooledCon). getDB2Connection(cookie,newuser,password,userRegistry,userSecTkn,originalUser,properties); |
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25714482/viewspace-760059/,如需转载,请注明出处,否则将追究法律责任。