|
|
安全性插件是动态可装载库，当 DB2 UDB 进行身份验证或者从组成员中查找某个用户的时候，便调用这些库。在 8.2 版之前，这些操作是由 DB2 UDB 之外的设施管理的，例如操作系统、域管理器或 Kerberos 安全性系统。图 1 提供的场景说明了在 8.2 版之前 DB2 UDB 安全性的工作原理。
图 1 说明了 4 个安全性场景：
-
客户机系统通过服务器系统连接到数据库时的安全性考虑。
在图 1 左侧，一个用户在 DB2 客户机系统的命令行处理程序（CLP）窗口中发出了语句connect to mydb user raul using raulpsw，以连接到位于 DB2 数据库服务器Aries上的数据库mydb。DB2 客户机与服务器通信，协商采用何种身份验证方法。为简单起见，我们假设客户机使用服务器返回的身份验证方法。在图中，AUTHENTICATION 被设置为 SERVER。这意味着，服务器（I）上的操作系统将通过检查提供的用户 ID 和密码是否与存储在操作系统安全性数据库中的值匹配，来进行身份验证。一旦用户通过身份验证，DB2 将从操作系统获得组成员信息。从此以后，DB2 不再在以后的检查中使用用户 ID 或密码；相反，DB2 将使用授权 ID（authID）。通常，authID 是用户 ID 的大写版本。 -
连接到数据库之后执行 SQL 语句时的安全性考虑。
图 1 的左下部分展示了一条 SELECT 语句，该语句是在以 authIDRAUL连接到数据库mydb的情况下发出的。在这个例子中，内部的 DB2 安全性设施审核 DB2 编目表，以确认 authIDRAUL被授予对表KEVIN.TABLE1执行 SELECT 操作的权限，以此来执行授权（authorization） 检查。如果 authIDRAUL和 PUBLIC 没有被授予这种权限，DB2 将检查该用户是否为几个特殊的组（例如 SYSADM、SYSCTRL、SYSMAINT 或 SYSMON）的成员。对于这些组中的每一个组，都有数据库管理器配置（dbm cfg）参数，可以将这些参数设置为一个操作系统组的值。在连接时，DB2 从操作系统中获取用户的组信息，并缓存在内存中。然后，DB2 审核这个缓存的数据（II），以检查 authIDRAUL是否为这些组中某个组的成员。例如，如果 authID 是 SYSADM 组的成员，那么 SELECT 可以继续，否则将返回一条错误消息（SQLCODE -551）。
在以上每个场景中，都调用了操作系统来进行安全性检查。而从 8.2 版开始，以上每种情况都可以使用安全性插件。因而，不必总是调用操作系统，在场景 1 中可以调用服务器和组插件，在场景 2 中可以调用组插件，在场景 3 和场景 4 中可以调用客户机和组插件。
这个例子介绍了三种类型的安全性插件：
-
客户端身份验证安全性插件（即客户机身份验证插件）
-
组成员查找安全性插件（即组插件）
服务器身份验证插件在数据库服务器上执行身份验证。它还用于检查一个 authID 是否为插件所知。例如，考虑 SQL 语句 grant select on table user1.t1 to FOO，DB2 不知道 FOO 是用户还是组。在这种情况下，DB2 询问所有服务器端插件和组成员插件，以检查 FOO 是用户还是组，或者两者都是，或者无法确定，从而可以对该 SQL 语句作出响应。
客户机身份验证插件在客户机上执行身份验证。在执行实例级命令（例如 db2start、db2stop、db2trc、update dbm cfg 等）时，它还用于执行实例级本地授权。因此，常常可以看到在一个数据库服务器上同时指定了客户机身份验证插件和服务器身份验证插件。
组插件在客户机和数据库服务器上执行组成员查找。它还用于检查一个 authID 是否为插件所知。
每个安全性插件由一组 API 组成，需要实现这些 API。DB2 提供安全性插件基础设施和一些缺省的安全性插件。定制的安全性插件的实现则有待您来决定。(
