postgresql 登陸使用GSS方式驗證的實現原理分析

postgresql登陸驗證功能提供了trust, reject, md5, password, gss, sspi,ident, peer, pam, ldap, radius,cert等多種驗證方式。用戶可使用其中的任何一種方式用來進行登陸驗證，固然DBA能夠針對不一樣的客戶端採用不一樣的驗證方式。本文主要介紹下GSS方式在postgresql中的實現原理。

1. GSS簡介

  GSS是Generic security service的簡寫，其API稱爲GSS-API（Generic Security service Application Program Interface）。GSS-API在對等應用程序之間提供安全通訊。GSS-API還提供驗證、完整性和保密性服務。在Solaris中實現的GSS-API可使用Kerberos v五、SPNEGO和Diffie-Hellman加密。GSS-API主要用於設計或實現安全的應用程序協議。GSS-API能夠向其餘類型的協議（如SASL)提供服務。GSS-API經過SASL來向LDAP提供服務。更多能夠參考oracle的文檔說明。

2. GSS使用的條件

  GSS在默認條件下編譯出來的數據庫版本是不支持gss的。直接配置驗證方式爲gss會在啓動時直接報以下的錯誤：

這是由於代碼中使用了下面所示的宏來隔離GSS的相關的實現：

查看configure --help,能夠看到有--with-gssapi的選項，經過這個選項來編譯支持GSS。

3. 使用GSS的配置方法

  postgresql的登陸驗證方式都是在pg_hba.conf文件中配置的，能夠在對應的客戶端的驗證方式修改成GSS，以下所示：

從上面的內容，能夠看到全部的客戶端登陸到服務端都是採用gss的驗證方式的。也能夠經過指定具體的IP地址來指定具體的客戶端的驗證方式。

4. GSS的創建過程

  GSS的創建過程的說明是根據postgresql中的代碼來講的，不一樣的程序可能有不一樣的創建的過程。

  1）客戶端先調用gss_import_name函數導入服務器的名稱。

其中conn->krbsvrname默認狀況下爲NULL，conn->pghost是主機IP地址。

  2）客戶端調用gss_init_sec_context函數啓動安全上下文

當成功建立上下文時，函數gss_init_sec_context返回GSS_S_COMPLETE，或者返回GSS_S_CONTINUE_NEEDED，須要繼續調用函數來建立安全上下文。

3）服務端調用gss_accept_sec_context函數來接收安全上下文

其中port->gss->ctx是空上下文GSS_C_NO_CONTEXT ，port->gss->cred是缺省憑證GSS_C_NO_CREDENTIAL。gbuf保存從客戶端發送過來的令牌。

4）服務端調用gss_display_name函數獲取客戶端名稱

經過上面的函數調用，就把客戶端的名稱保存到了gbuf中。提取出客戶端的用戶名與服務端的用戶名想比較，若是相同則驗證經過，不然就出現錯誤。