簡介
DB2 UDB 提供一種框架，用於編寫定制的安全插件，管理員可使用這些插件進行 DB2 UDB 身份驗證。該框架是在 DB2 UDB V8.2 中引入的，也支持基於通用安全服務應用程序編程接口（Generic Security Service Application Programming Interface，GSS-API）的插件身份驗證。
許多 DB2 UDB 管理員利用 GSS-API 插件進行基於 Kerberos 的身份驗證。由於 NFS V4（Network File System Version 4, [IETF RFC-3530]）的順利開發，以及 RFC 要求使用較新的 GSS-API 機制，如 SPKM（Simple Public Key Mechanism, [IETF RFC-2025]）和 LIPKEY（A Low Infrastructure Public Key Mechanism Using SPKM, [IETF RFC-2847]），DB2 UDB 很快會具有支持這些新的安全機制的 GSS-API 產品。
DB2 UDB 安全性系列文章 第 2 部分 介紹並解釋了用於身份驗證的 DB2 UDB 安全插件架構。本文將進一步介紹有關新的 GSS-API 安全機制的信息。然後還將描述：如何通過使用新的具有可定制的 DB2 UDB 安全插件的 GSS-API 安全機制來實現基於公鑰技術的身份驗證。
用於身份驗證的 DB2 UDB 安全插件
身份驗證是使用安全機制對用戶提供的憑證進行確認的過程，這已在 DB2 安全系列文章的 第 1 部分 中進行了討論。在 DB2 UDB 中，用戶和組身份驗證由 DB2 UDB 的外部設備以插件的形式來管理，如操作系統、域控制器或者 Kerberos 安全系統。
安全插件是 DB2 UDB 所加載的動態可加載庫，用來提供以下功能：
組檢索插件：檢索給定用戶的組成員信息。
客戶機身份驗證插件：管理 DB2 客戶機上的身份驗證。
服務器身份驗證插件：管理 DB2 服務器上的身份驗證。
DB2 UDB 支持兩種插件身份驗證機制：
使用用戶 ID 和口令的身份驗證。
使用 GSS-API 的身份驗證，其正式稱法為 Generic Security Service Application Program Interface Version 2 [IETF RFC2743] 和 Generic Security Service API Version 2: C-Binding [IETF RFC2744]。
在 DB2 Version 8.2 中，默認行為是使用在操作系統級別實現身份驗證機制的用戶 ID/口令插件。下圖提供了 DB2 UDB 安全插件基礎設施的高級視圖：
圖 1. DB2 UDB 安全插件基礎設施的高級視圖
利用 DB2 UDB 安全插件架構，您可以通過開發自己的插件或從第三方購買插件的方式來定制身份驗證行為。為了允許定制 DB2 UDB 身份驗證行為，DB2 UDB 提供了可用來修改現有插件或構建新的安全插件的 API。本文將集中討論使用 GSS-API 進行身份驗證，並展示如何利用新的 GSS-API 安全機制，如 SPKM（Simple Public Key Mechanism, [IETF RFC-2025]）和 LIPKEY（A Low Infrastructure Public Key Mechanism Using SPKM, [IETF RFC-2847]）進行 DB2 UDB 身份驗證。
GSS-API 及其未來對 SPKM/LIPKEY 安全機制的支持
Generic Security Service Application Program Interface 簡稱為 GSS-API，如在 [IETF RFC-2743] 中所定義：“以一般的形式向調用者提供安全服務，可由廣泛的底層機制和技術所支持，從而允許應用程序到不同環境的源代碼級可移植性。”（參見 參考資料 中的（RFC）2743）。 這是一套編程接口，抽象了身份驗證、消息源驗證和完整性。因此，用 GSS-API 開發的安全應用程序可以在不同的安全機制上運行，不用改變應用程序。
到目前為止，大部分 GSS-API 產品所支持的惟一的安全機制就是名為 Kerberos [IETF RFC-1964] 的流行的基於對稱密鑰的機制。但是，隨著 NFS V4[IETF RFC-3530] 的開發勢頭日益加強，程序員們不久將會看到出現這樣的供應商：他們的 GSS-API 產品支持諸如 SPKM 和 LIPKEY 這樣的附加安全機制。這種支持增長的主要原因是，NFS V4 [IETF RFC-3530] 強制規定其安全模塊使用 SPKM 和 LIPKEY 安全機制。因此，上述要求會迫使供應商擴展 GSS-API 框架，以支持 Kerberos 之外還支持 SPKM 和 LIPKEY，而 Kerberos 將繼續作為默認的 GSS-API 機制。Kerberos 和 SPKM-3/LIPKEY 的主要區別是：前者只是基於對稱密鑰的安全機制，而後者則是基於對稱密鑰的安全機制與公鑰技術的混合體。下文對 SPKM 和 LIPKEY 機制的概述，有助於了解其為應用程序帶來的好處。
SPKM（Simple Public Key Mechanism, IETF RFC-2025）
SPKM 是一種 GSS-API 機制，其基於公鑰而非對稱密鑰基礎設施。SPKM 使用公鑰基礎設施在一個聯機分布式應用程序環境下提供身份驗證、密鑰設立、數據完整性和數據機密性。它不需使用安全時間戳即可完成單向和雙向身份驗證。SPKM 使用算法標識符（Algorithm Identifier）來指定各個通信方所使用的不同算法。它允許基於真正的不對稱算法在與簽署和加密消息有關的 GSS-API 函數中——比如 gss_sign() 和 gss_seal() 操作（目前在 [GSSv2] 中稱之為 gss_getMIC() 和 gss_wrap()）——選擇數字簽名，而不是基於使用對稱算法（如 DES）得出的 Mac 來選擇完整性校驗和。SPKM 的數據格式和過程被設計成在實用性方面與 Kerberos 機制的類似。這樣做的目的是為了使 SPKM 容易在已實現了 Kerberos 的環境中實現。因此，當應用程序需要一種基於公共密鑰基礎設施的 GSS-API 機制時，SPKM 就能滿足它的要求。關於 SPKM 的更多信息，請參閱 IETF RFC 2025（參閱 參考資料）。
LIPKEY（A Low Infrastructure Public Key Mechanism using SPKM, IETF RFC-2847）：
諸如 Kerberos V5[IETF RFC-1964] 和 SPKM [IETF RFC-2025] 之類的 GSS-API 機制需要大量的基礎設施。正如在 IETF RFC 2847 中所提到的，LIPKEY 是一種基於 GSS-API 安全機制的低基礎設施，該安全機制對應於典型的 TLS（Transport Layer Security）部署場景。其包括一台沒有公鑰證書的客戶機，該客戶機通過公鑰證書訪問服務器。
在該機制中，客戶機：
獲得服務器證書。
核實證書是由受信任的認證權威（Certification Authority ，CA）所簽署的。
生成隨機會話對稱密鑰。
使用服務器公鑰對會話密鑰進行加密。
將加密的會話密鑰發送給服務器。
此時，客戶機和服務器有了一條安全通道。然後，客戶機就可以向服務器提供用戶名稱和口令，以驗證客戶機身份。當發起者（客戶機）沒有證書而是使用用戶 ID 和口令進行驗證身份時，就可以使用 LIPKEY 機制。
使用較新的受支持的 GSS-API 機制的 DB2 UDB 身份驗證
DB2 UDB V8.2 支持 GSS-API 身份驗證機制。事實上，IBM 為 DB2 UDB 提供的示例 Kerberos 安全插件是基於 GSS-API 的。換言之，IBM 的 Kerberos 支持是作為一個 GSS-API 安全插件來提供的，您可將該插件用於服務器身份驗證和用戶身份驗證。此外，用於 DB2 UDB 的 GSS-API 安全插件可以帶來更大的價值，因為 NFS V2 的實現使您將會具有這樣的 GSS-API 庫：其既支持傳統的對稱密鑰安全機制（即 Kerberos），又支持未來的非對稱密鑰安全機制，如 SPKM 和 LIPKEY。
要允許 DB2 UDB 使用 SPKM/LIPEY 機制進行身份驗證：
編寫支持 SPKM/LIPKEY 安全機制的定制的 GSS-API 安全插件。當然，這將需要支持 SPKM/LIPKEY 機制的 GSS-API 產品。為了定制身份驗證，DB2 UDB 通過向開發人員提供某些 API 使其可以編寫自己的身份驗證插件，從而提供一種框架。在開發安全插件時，需要實現 DB2 UDB 調用的標准身份驗證函數。編寫支持 SPKM/LIPKEY 的 GSS-API 插件非常類似於編寫 Kerberos 安全插件，只是存在非常微小的差別，後面將進行說明。為了更好地理解如何編寫 GSS-API 安全插件，應閱讀並且理解 IBM 提供的用於 DB2 UDB 的 Kerberos 安全插件，其基於 GSS-API（參閱 參考資料）。
為了進行基於 SPKM 的身份驗證，通常需要：
在 DB2 UDB 服務器中：一張 X.509 證書，一個 PKI（Public Key Infrastructure）環境，以及一個支持 SPKM 的服務器端 GSS-API 安全插件。
在 DB2 UDB 客戶機中：一張 X.509 證書，一個 PKI 環境，以及一個支持 SPKM 的客戶端 GSS-API 安全插件。
為了進行基於 LIPKEY 的身份驗證，通常需要：
在 DB2 UDB 服務器中：一張 X.509 證書，一個 PKI 環境，以及一個支持 LIPKEY 的服務器端 GSS-API 安全插件。DB2 服務器還需要具有對用戶 ID/口令數據庫的訪問權，以進行客戶端身份驗證。通常，支持 LIPKEY 機制的 GSS-API 產品會提供用戶 ID/口令數據庫的詳細信息。
在 DB2 UDB 客戶機中：一個支持 LIPKEY 的客戶端 GSS-API 安全插件。注意，客戶機不需要具有任何 X.509 證書，但是可能需要具有 PKI 環境，以確認服務器的 X.509 證書。通常，這將由支持 LIPKEY 機制的 GSS-API 產品進行詳細記載。
下圖描繪的高級視圖是，當使用支持 SPKM 或 LIPKEY 的 GSS-API 插件時，DB2 UDB 身份驗證的工作原理。
圖 2. 使用 SPKM 安全機制的 DB2 UDB 身份驗證的高級視圖
圖 3. 使用 LIPKEY 安全機制的 DB2 UDB 身份驗證的高級視圖
由上面兩圖可知：身份驗證是通過交換 GSS-API 令牌來實現，這對於 GSS-API 安全模型非常典型。提請大家注意的關鍵點是：
對於 SPKM 安全機制，DB2 UDB 客戶機和 DB2 UDB 服務器是基於其所持有的 X.509 證書來完成身份驗證的。
對於 LIPKEY 機制，X.509 證書僅用於服務器身份驗證，而客戶機身份驗證是通過由客戶輸入的用戶 ID 和口令來完成的（因此將其視為一種低基礎設施公鑰機制）。而且，LIPKEY 機制被設計成使用戶 ID、口令及身份驗證結果的數據交換均在客戶機和服務器之間的安全網絡通道上進行。
除了將在本節列出的少數修改內容之外，開發支持 SPKM 或 LIPKEY 的 GSS-API 插件類似於開發用於 DB2 UDB 的 Kerberos 安全插件。下面的討論假設您熟悉 DB2 UDB 安全插件編程以及與 DB2 UDB 一起發布的 Kerberos 安全插件。關於更多信息，請參閱 DB2 UDB 文檔（參見 參考資料）。
在開發 DB2 UDB 安全插件時，需要實現 DB2 UDB 將會調用的標准身份驗證函數：db2secClientAuthPluginInit()、db2secClIEntAuthPluginTerm()、db2secServerAuthPluginInit()、db2secServerAuthPluginTerm()，等等。對於 GSS-API 身份驗證插件，也需要實現在 DB2 UDB 文檔中所提及的 GSS-API 函數：gss_init_sec_context()、gss_accept_sec_context()、gss_acquire_cred()，等等。您可在 IBMkrb5.c 中找到一個示例實現，IBMkrb5.c 與 DB2 UDB 一起發布的一個示例 Kerberos 安全插件。下面幾點說明了在開發用於 DB2 UDB 支持 SPKM 或 LIPKEY 的 GSS-API 插件時需要考慮的關鍵問題。
獲得一份支持 SPKM 或 LIPKEY 機制（或同時支持兩者）的 GSS-API 產品的副本，並設置所需的 PKI 環境。
在實現用於插件的 db2secServerAuthPluginInit() 函數時：
請確保明確地獲得了用於所希望的安全機制的憑證。為此，請向 gss_acquire_cred() 傳遞適當的機制 OID（如在 GSS-API 產品的頭文件中所定義的）。注意，若指定 GSS_C_NO_OID_SET 作為所希望機制的 OID，那麼 gss_acquire_cred() 將會為默認的安全機制（通常是 Kerberos）取得憑證。
對於 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 身份驗證，而不需要做太多的代碼修改。
