端到端联合可信上下文是在 IBM® WebSphere® Federation Server V9.5 中首次出现的功能集。该功能加强了与多层模型相关的安全性，可以将最终用户身份传播到整个应用程序模型层，而不会影响整体性能。本文描述了端到端联合可信上下文，并介绍了详细的配置步骤和一些技巧。

当代企业应用程序逐渐转向多层应用程序模型，该模型中用户请求将通过多个中间层从数据库客户端传送到数据库服务器。通用中间层的一些示例有：应用服务器（用于包含应用程序）、联合服务器（用于透明地访问异构数据源）。以前，联合多层企业应用程序必须在安全和性能之间做出选择。但是 WebSphere Federation Server V9.5 在纳入 之后改变了这种状况，它可以利用联合服务器和数据源内置的可信上下文功能。由此，您可以在可信的环境中实现端到端的身份断言（identity assertion），不一定需要重新验证。

有两种方法可以利用该功能：

1. 端到端的联合可信上下文在涉及 WebSphere Federation Server 的所有多层应用程序模型中提供身份断言。
2. 出站联合可信上下文可以减少大部分用户映射，因此可以减少对 WebSphere Federation Server 和数据源中的密码进行重复维护的管理工作。

本文描述第一种场景。（即将发布的有关 WebSphere Federation Server 中的用户身份管理的文章将讨论第二种场景。敬请关注！）

由于应用服务器（允许以用户友好的方式通过 Web 访问数据库）和联合服务器（透明地访问异构数据源）之类的中间层服务器不断增多，企业现在逐渐开始采用多层应用程序模型。以下是典型场景：

您拥有一个保险应用程序，可以从远程 IBM DB2® 数据源访问人寿保险理赔，以及从远程 Oracle 数据源访问家庭保险理赔，然后向给定客户返回综合报告。您的应用程序运行在应用服务器上，成千上万个用户可以登录到应用程序查看他们的理赔。

通常，所有与数据库服务器的交互都通过客户端（例如，IBM WebSphere 应用服务器）建立的数据库连接发生，WebSphere Federation Server 使用用户 ID 和标识该客户端的凭据将交互传播到数据库服务器。例如， 中的所有应用程序请求都通过一个应用程序用户 APP_USER 建立的连接传播到数据库服务器。换句话说，数据库服务器使用与 APP_USER 关联的数据库权限进行所有数据库访问的身份验证和审核。

从图 1 可以看到，在这种多层场景中使用 APP_USER 之类的通用应用程序用户存在几个问题：

• 最终用户身份丢失：为了进行访问控制，企业需要了解实际访问数据库的用户的身份。
• 减少了用户责任：通过审核确定责任是数据库安全的基本原则。如果不知道用户的身份，则很难将应用服务器为自己执行的事务与应用服务器代表某个用户执行的事务区别开来。
• 过度授权：应用程序授权 ID 必须具有执行所有用户请求所需的所有权利。这违背了最小特权原则，这是一个基本的安全设计原则，该原则建议只授予用户足够执行其任务的权利。
• 安全性变弱：当前的方法要求应用程序用来建立连接的授权 ID 必须具有足够的权限，以允许任何用户请求访问所有资源。因此应用程序授权 ID 成为了安全瓶颈，它的泄漏将造成所有企业资源的曝光。
• 使用相同连接的用户溢出：当几个用户共享一个连接时，一个用户的更改将影响所有其他用户。例如，一个用户创建的保留指针或新的临时表可能给共享同一连接的其他用户带来不可预料的更改。

出于这些问题，我们需要一种更好方法将实际用户的身份传播到各层乃至数据库服务器，同时又不会导致过高的开销，也不需要对每个新的最终用户重新建立物理连接。

端到端的联合可信上下文是 WebSphere Federation Server 的解决方案，可以有效地解决多层身份断言问题。

端到端的联合可信上下文解决了 WebSphere Federation Server V9.5 涉及的多层场景中的身份断言问题。要配置该功能，可以在联合服务器上创建一个可信上下文对象，在远程数据源上创建一个身份断言对象（DB2 可信上下文或 Oracle 代理用户）。 WebSphere Federation Server 上的可信上下文对象为可信的入站连接封装信任属性。远程数据源上的身份断言对象为建立可信出站连接定义信任属性。

配置好该属性后，它的工作方式如下：

• 当 WebSphere Federation Server 的入站连接可信时（通过新的可信上下文 API 显式请求，或者通过匹配连接属性隐式授权），向数据源请求可信出站连接。
• 切换入站连接用户后，也切换了出站连接用户。

下面的 说明了如何使用端到端的联合可信上下文解决与图 1 中介绍的多层保险应用程序有关的各种安全问题。

要支持端到端联合可信连接，相应的安全管理员（即具有 SECADM 权限的用户）必须首先在远程 DB2 数据源和联合服务器上配置可信上下文对象。WebSphere Federation Server 上的可信上下文对象定义 WebSphere Federation Server 和保险应用程序所在的应用服务器之间的信任关系。远程 DB2 数据源上的可信上下文对象定义 WebSphere Federation Server 和远程数据源之间的信任关系。

从图 2 中的步骤 1 可以看到，当第一次在应用服务器上启用保险应用程序时，应用服务器将建立 WebSphere Federation Server 到数据源的连接。将在应用程序用户 APP_USER 的身份下建立显式的可信连接。应用程序用户现在可以使用该可信连接执行一些初始配置任务并为最终用户准备好环境。完成所有初始化任务之后，APP_USER 提交工作单元并为处理最终用户请求做准备。

从图 2 中的步骤 2 可以看到，用户 Bob 现在可以访问保险应用程序查看他的所有保险理赔。入站与出站可信连接上的当前用户 ID 现在从 APP_USER 切换为 BOB。实际上，Bob 的身份现在在同一个物理连接中断言，一直到远程数据源。Bob 的保险理赔请求由他在数据源上的相应授权进行处理。Bob 的请求也在远程数据源中自己的身份下进行审核。完成 Bob 的请求后，提交他的工作单元，该可信连接现在可以用于处理其他用户请求。

现在用户 Alice 可以访问保险应用程序检索理赔（如图 2 的步骤 3 所示），她的身份可以在同一个物理连接上断言，只需将连接用户 ID 从 BOB 切换为 ALICE。

从上述场景中可以看到，端到端联合可信上下文可以基于正确的最终用户身份准确地检查授权、完成用户会计和审计处理。除了显而易见的安全好处外，与常规非可信连接相比，端到端联合可信上下文能实现更好的性能：

• 不同的用户身份可以在同一个物理入站和出站连接上断言，无需针对每个新用户释放连接并创建新连接。
• 如果将 WebSphere Federation Server 上的可信上下文对象和远程数据源上的身份断言对象配置为无需验证的连接重用，则可以获得更多性能提升。

以下逐步指南可以帮助您设置端到端联合可信上下文环境，如图 3 所示：

1. 远程数据源设置
   这是使用联合可信上下文的先决条件。DB2 远程数据源和 Oracle 远程数据源的设置有所不同。

   DB2：安全管理员应该在远程 DB2 数据源上配置联合可信上下文，以定义数据源和 WebSphere Federation Server 之间的信任关系。以下语句（）将建立一个可信连接，其中假设发起方为 APP_USER，客户端在 WebSphere Federation Server 上的 IP 地址为（9.44.111.222）。连接建立后，任何有效用户都可以使用该可信连接，无需重新验证。确保您启用了可信上下文。

   CREATE TRUSTED CONTEXT MY_DB2_TCX BASED UPON CONNECTION USING SYSTEM AUTHID APP_USER ATTRIBUTES (ADDRESS ‘9.44.111.222') WITH USE FOR PUBLIC WITHOUT AUTHENTICATION ENABLE

   Oracle：在远程 Oracle 服务器配置代理验证。指定 MARY、ALICE 和 BOB 都可以使用代理 APP_USER 进行连接，无需重新验证。

   ALTER USER MARY GRANT CONNECT THROUGH APP_USER;ALTER USER ALICE GRANT CONNECT THROUGH APP_USER;ALTER USER BOB GRANT CONNECT THROUGH APP_USER;

   有关特定于数据源的更多信息，请参考 。

2. 联合服务器可信上下文定义
   安全管理员必须在 WebSphere Federation Server 上设置可信上下文对象，以允许建立可信连接。以下语句（）指定 APP_USER 可以建立可信连接，其中假设请求来自客户端 IP 地址（9.44.111.111）。连接建立后，任何有效用户都可以重用该可信连接，无需重新验证。确保您启用了可信上下文。

   CREATE TRUSTED CONTEXT MY_WFS_TCX BASED UPON CONNECTION USING SYSTEM AUTHID APP_USER ATTRIBUTES (ADDRESS ‘9.44.111.111') WITH USE FOR PUBLIC WITHOUT AUTHENTICATION ENABLE
3. 联合服务器数据源配置
   在 WebSphere Federation Server 上，可以使用 中的语句配置对此场景的远程 DB2 数据源的访问。注意，该步骤不需要其他选项。

   CREATE WRAPPER drda; CREATE SERVER udb1 TYPE db2/udb VERSION 9.5 WRAPPER drda AUTHORIZATION "APP_USER" PASSWORD "secret" OPTIONS (DBNAME 'remotedb');

   考虑是否需要在联合服务器上设置用户映射。

   • 如果 APP_USER 在 WebSphere Federation Server 上的用户 ID 和密码与远程用户源上使用的相同，则不需要用户映射。
     注意：如果 APP_USER 在 WebSphere Federation Server 和数据源上的用户 ID 和密码不同，则需要用户映射。
   • 所有有效的数据库用户都可以重用 APP_USER 建立的可信连接，无需重新验证。因此，在 WebSphere Federation Server 和远程数据源上拥有相同 ID 的用户（比如 MARY 和 ALICE 等）不需要任何用户映射。
   • WebSphere Federation Server 上的用户 JOE 映射到远程数据源上的用户 JOESMITH。那么，安全管理员必须使用 中的语句为 JOE 创建一个可信用户映射。选项 USE_TRUSTED_CONTEXT 设置为 ‘Y’ 的映射被视为可信用户映射。只有具有 SECADM 权限的用户才能创建可信用户映射，以防止用户将自己映射到远程数据源上具有更多权限的用户。JOE 的用户映射仅需要在入站和出站授权 ID 之间进行映射。不需要指定 REMOTE_PASSWORD 选项，因为 JOE 可以重用 APP_USER 建立的可信连接，无需重新验证。

     CREATE USER MAPPING FOR JOE SERVER udb1 OPTIONS ( REMOTE_AUTHID 'JOESMITH', USE_TRUSTED_CONTEXT 'Y');

     注意：由于指定该用户映射时没有使用 REMOTE_PASSWORD 子句，因为不需要进行痛苦的密码维护管理。

   • WebSphere Federation Server 和数据源上使用不同用户 ID 和密码的用户定义可信映射时必须定义 REMOTE_AUTHID 和 REMOTE_PASSWORD 选项。
4. 用户应用程序
   完成初始设置后，应用程序用户就可以使用联合可信上下文了：
   1. 建立端到端联合可信连接
      启用应用程序后，应用程序用户 APP_USER 需要可信入站连接。第一个访问远程 DB2 数据源的联合请求将为 APP_USER 建立可信出站连接。如 中的步骤 4d 所示，APP_USER 可以使用此显式的端到端联合可信连接执行数据源上的一些日常任务，并为企业最终用户的使用做好准备。
   2. 切换端到端的联合可信连接上的用户
      最终用户（比如 Bob）开始使用应用程序时，入站用户 ID 将从 APP_USER 切换为 BOB。BOB 发出第一个联合请求（即访问远程 DB2 数据源）时，出站可信连接用户 ID 也切换为 BOB。从 中的步骤 5d 可以看到，BOB 的身份现在一直断言到 DB2 数据源，他的身份将用于准确地授权、审计等。

   int main(int argc, char *argv[]){ SQLHANDLE henv; /* environment handle */ SQLHANDLE hdbc1; /* connection handle */ SQLHANDLE hstmt; /* statement handle */ char origUserid[10] = "APP_USER"; char origPassword[10] = "secret"; char reuseUserid[10] = "BOB"; char dbName[10] = "testdb"; /* Allocate the handles */ SQLAllocHandle( SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv ); SQLAllocHandle( SQL_HANDLE_DBC, henv, &hdbc1 ); /* Set the trusted connection attribute */ SQLSetConnectAttr( hdbc1, SQL_ATTR_USE_TRUSTED_CONTEXT, (SQLPOINTER)SQL_TRUE, SQL_IS_INTEGER ); /* Establish a trusted inbound connection for user APP_USER from WAS to WFS. This requires a password to be specified. */ SQLConnect( hdbc1, (SQLCHAR *)dbName, SQL_NTS, origUserid, SQL_NTS, origPassword, SQL_NTS ); /* Allocate statement handle */ SQLAllocHandle(SQL_HANDLE_STMT, hdbc1, &hstmt); /* The first call to remote DB2 data source will setup trusted outbound connection for user APP_USER from WFS to remote DB2 data source. */ SQLExecDirect (hstmt, (SQLCHAR *) "SELECT * FROM patents_nn", SQL_NTS); /* Perform. some work under user ID "APP_USER" */ . . . . . . . . . . . /* Commit the work. End the transaction. */ SQLEndTran(SQL_HANDLE_DBC, hdbc1, SQL_COMMIT); /* Free statement handle */ SQLFreeHandle(SQL_HANDLE_DBC, hstmt); /* At the transaction boundary, switch the inbound user ID on the trusted connection from APP_USER to BOB. Note: Password is not required since PUBLIC appears in the "with use for" clause "without authentication" in the MY_WFS_TCX trusted context object. */ SQLSetConnectAttr (hdbc1, SQL_ATTR_TRUSTED_CONTEXT_USERID, reuseUserid, SQL_IS_POINTER ); /* Allocate statement handle */ SQLAllocHandle(SQL_HANDLE_STMT, hdbc1, &hstmt); /* The first call to the remote data source after switching inbound user will switch the outbound user ID as well (from APP_USER to BOB). Since no user mapping was specified for user BOB, the same user ID will be passed on to the outbound connection. Password is not required since PUBLIC appears in the "with use for" clause "without authentication" in the MY_DB2_TCX trusted context object. */ SQLExecDirect (hstmt, (SQLCHAR *) "SELECT * FROM patents_nn", SQL_NTS); /* Perform. new work using user ID "BOB" */ . . . . . . . . . /* Commit the work. End the transaction. */ SQLEndTran(SQL_HANDLE_DBC, hdbc1, SQL_COMMIT); . . . . . . . . . /* Disconnect from the database */ SQLDisconnect( hdbc1 ); /* Cleanup, free handles, etc */ . . . . . . . . . return 0;} /* end of main */

• 联合可信连接请求失败
  当请求显式的端到端联合可信连接失败时，返回警告 SQL20360W。当隐式联合可信连接尝试失败时，不会返回任何消息。在这两种情况下，都将创建一个常规的非可信连接（如果可能）。如果应用程序请求一个可信连接，但是得到的是常规的非可信连接，请检查是否存在以下问题：
  • 确保客户端使用 TCP/IP 与联合服务器进行通信。切记如果客户端和联合服务器位于同一个机器上，则默认情况下 DB2 使用 IPC。确保让联合数据库使用 TCP/IP。
  • 确保在联合服务器上创建并启用了可信上下文对象。只有在 CREATE / ALTER TRUSTED CONTEXT DDL 语句中使用 ENABLE 关键字时才执行可信上下文对象。
  • 应用程序请求显式的可信连接时，不能将数据库服务器验证类型设置为 CLIENT。
  • 最后，验证联合数据库服务器可信上下文对象中的信任属性与连接请求中出现的信任属性相匹配。例如，可信上下文对象中指定的 IP 地址可能不正确，或者可信上下文不能接受您的网络加密属性级别。
• 尝试切换联合可信连接上的用户失败
  如果尝试切换联合可信连接上的用户时遇到错误，请检查是否存在以下问题：
  • 如果返回 SQL1060N，请验证用户确实具有连接联合数据库的权限。
  • 如果应用程序收到 SQL20361N，请验证以下内容：
    • 确保在可信上下文中的 WITH USE FOR 子句中定义了用户 ID 或 PUBLIC。
    • 切换用户需要验证，但是应用程序没有任何凭据或者凭据不正确。
    • 验证用户切换请求是否位于事务边界内。在重新提交请求之前要提交或回滚事务。
    • 最后，验证联合服务器上的可信连接对象从建立连接之时起没有被禁用、放弃或改变。
• 尝试添加/修改/删除联合可信上下文选项失败
  如果在使用 USE_TRUSTED_CONTEXT 选项创建或改变用户映射时遇到错误，请检查以下内容：
  • 必须具有 SECADM 权限才能创建或放弃定义了 USE_TRUSTED_CONTEXT 选项的用户映射。
  • 必须具有 SECADM 权限才能改变用户映射，以添加、设置或放弃 USE_TRUSTED_CONTEXT 选项。
  • 只能改变可信用户映射的 REMOTE_PASSWORD 选项。确保新值不为空。

• 联合可信上下文只能为支持身份断言功能的以下数据源提供连接重用：
  1. DB2 for Linux®、UNIX® 和 Windows® V9.5 或更高版本，以及
  2. DB2 for z/OS® V9 或更高版本
  3. Oracle
  对于所有其他数据源，WebSphere Federation Server 仅支持常规的不可信出站连接。当切换入站连接时，WebSphere Federation Server 将断开此类数据源的连接并重新建立连接。因此，对其他数据源使用联合可信上下文并没有性能优势。注意，对于这些不受支持的数据源，重新连接需要用户 ID 和密码。
• 显式可信连接只能通过支持可信连接请求的 API（即 CLI、ODBC、JDBC 和 XA ）进行请求。

WebSphere Federation Server V9.5 中的端到端联合可信上下文是一个新功能，可以提供以下好处：

• 通过保存访问远程数据库的最终用户的身份，提高了对访问的控制力
• 通过审核区分不同用户执行的事务，规范了用户责任
• 支持最小特权原则，仅向用户授予完成任务所需的权限
• 个人化安全管理，确保没有任何一个授权 ID 会成为企业资源泄漏的安全瓶颈
• 在连接切换到新的用户时完全清除用户环境，从而保护用户不受前一个连接用户的影响

联合可信上下文功能为用户提供了改进的安全性、增强的性能和易管理性。联合可信上下文和其他新的安全功能（比如联合数据库角色和 C 用户映射插件）一起，使 WebSphere Federation Server V9.5 成为安全信息集成解决方案的理想选择。

DB2（针对 Linux、UNIX 和 Windows，以及 z/OS）引入了一个新的数据库安全对象，名为可信上下文。可信上下文解决了在 DB2 和外部实体之间建立信任关系的问题，外部实体包括中间件服务器（例如 WebSphere Applicaiton Server）或联合服务器（例如 WebSphere Federation Server）等。将评估一系列信任属性以确定某个特定上下文是否可信。当连接属性匹配 DB2 服务器中定义的惟一可信上下文的属性时，可以将数据库连接当作可信连接。可信连接以以下内容为基础：

• 最主要的是建立物理连接的授权 ID。（注意：只有一个可信上下文对象可以与主要授权 ID 关联。
• 特定的 “信任属性”（可选），即：
  • IP 地址或域名
  • 网络加密级别

第一次连接到服务器时，将在数据库连接和可信上下文之间建立关系，这种关系将在连接期间一直维持。建立关系后，即允许连接发起方获取其他功能。这些额外功能的内容取决于可信连接是显式的还是隐式的。

显式可信连接 是用户显式请求的可信连接。显式可信连接具有某些增强功能：

• 将连接用户切换为不同用户的能力，不一定需要验证。这是通过支持切换用户的 XA、JDBC、ODBC 和 CLI API 实现的。只有具有数据库 CONNECT 权限的用户才能重用可信连接。切换可信连接用户时，它重置所有连接属性，包括保留指针、隔离、绑定选项、代码页面等等。不会留下上一个用户的任何痕迹。事实上，这相当于为切换的用户建立了一个新的连接。
• 显式可信连接用户可以在可信连接范围内获得其他情况下无法获得的其他权限。

隐式可信连接是用户隐式请求的连接。当传入连接请求的所有属性匹配 DB2 服务器上任何可信上下文对象的所有信任属性时，DB2 服务器隐式地授予一个可信连接。这样的连接就称为隐式可信连接。对于连接请求它不需要任何特殊的 API。隐式可信连接允许连接发起人获得其他情况下无法获得的其他权限。但是，隐式可信连接不能供切换用户重用。

DB2 使用 语句创建可信上下文对象。相应的 ALTER、DROP 和 COMMENT DDL 语句也可用。

Oracle 允许中间层在单个数据库连接中设置许多轻量级用户会话，每个会话都惟一地对应于一个连接用户。这些轻量级会话减少了创建中间层与数据库的连接所带来的开销。应用程序可以根据处理用户事务的需要在这些会话之间切换。

Oracle 使用 alter user DDL 语句注册代理用户。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-406662/，如需转载，请注明出处，否则将追究法律责任。