DB2 UDB 安全性: 使用 GSS-API 安全机制（SPKM/LIPKEY）的安全插件

核心提示： 对于 LIPKEY 和 SPKM 机制，请确保用与 DB2 服务器相关联的 X.509 证书的主题名称填充服务器主名称（将为它获得凭证），DB2 UDB 安全性: 使用 GSS-API 安全机制（SPKM/LIPKEY）的安全插件(7)，通常，DB2 实例名称会被假定为服务器名称，有了对这

对于 LIPKEY 和 SPKM 机制，请确保用与 DB2 服务器相关联的 X.509 证书的主题名称填充服务器主名称（将为它获得凭证）。通常，DB2 实例名称会被假定为服务器名称。在这种情况下，应确保与 DB2 服务器相关联的 X.509 证书中的主题名称（或者至少是主题名称的公共名称组件）与 DB2 实例名称相匹配。否则，gss_acquire_cred() 函数将不能取得服务器凭证。

在 db2secGenerateInitialCred() 函数的实现中，请确保明确地获得了用于所希望的安全机制的凭证。为此，请向 gss_acquire_cred() 传递适当的机制 OID（如在 GSS-API 产品的头文件中所定义的）。尤其对于 LIKEY 机制而言，在执行 db2secGenerateInitialCred() 的过程中，客户将被要求输入用户 ID 和口令，以用于客户端身份验证。

在 db2secProcessServerPrincipalName() 函数的实现中，将会把一个文本服务主名称转换为 GSS-API 的内部格式，以用于其他 API。为此，请使用 gss_import_name() 函数。通常，文本服务主名称应该与同 DB2 服务器相关联的 X.509 证书中的主题名称（或者至少是主题名称的公共名称组件）相匹配，或者与在服务器端获得凭证的服务器主名称相匹配。

需要封装或覆盖 gss_init_sec_context() 函数，以确保传递正确的所希望机制的 OID，从而为它启动安全上下文。GSS-API 的默认行为是为 Kerberos 安全机制启动上下文。

实现其余的 DB2 UDB API 函数类似于编写 DB2 UDB 文档中所描述的 GSS-API 安全插件，并且这些函数已经在与 DB2 UDB 一起发布的示例 Kerberos 安全插件中实现了。

结束语

有了诸如 SPKM 和 LIPKEY 之类的由 GSS-API 所支持的附加安全机制，DB2 UDB 管理员/程序员就应该考虑实现支持这些机制的较新的 GSS-API 安全插件。有了对这些未来的 GSS-API 机制（SPKM3 和 LIPKEY）的支持，使用 GSS-API 插件将有利于 DB2 UDB 管理员基于公钥技术或传统对称密钥机制进行 DB2 UDB 身份验证，而不需要做太多的代码修改。