19.3. 認證方法 · PostgreSQL 中文文檔 9.3

# 19.3\. 認證方法下面的小節更詳細地描述認證方法。 ## 19.3.1\. 信任認證如果聲明了`trust`認證模式，PostgreSQL 就假設任何可以連接到服務器的人都可以以任何他聲明的數據庫用戶名(甚至超級用戶名)連接。當然，在`database`和`user`字段里面的限制仍然適用。這個方法應該用于那些在連接到服務器已經有足夠操作系統層次保護的環境里。 `trust`認證對于單用戶工作站的本地連接是非常合適和方便的。通常它本身并_不_適用于多用戶環境的機器。不過，即使在多用戶的機器上，你也可以使用`trust`，只要你利用文件系統權限限制了對服務器的 Unix 域套接字文件的訪問。要做這些限制，你可以設置`unix_socket_permissions`參數(以及可能還有 `unix_socket_group`)，就像[Section 18.3](#calibre_link-1242)里描述的那樣。或者你可以設置`unix_socket_directories`，把 Unix 域套接字文件放在一個經過恰當限制的目錄里。設置文件系統權限只能幫助 Unix 套接字連接，它不會限制本地 TCP/IP 連接。因此，如果你想利用文件系統權限來控制本地安全，那么刪除`pg_hba.conf`文件中的 `host ... 127.0.0.1 ...`行，或者把它改為一個非`trust`的認證方法。 `trust`認證模式只適合 TCP/IP 連接，只有在你信任那些`trust` 行上所有機器中的所有用戶的時候才是合適的。很少有理由使用`trust`作為任何除來自localhost (127.0.0.1) 以外的 TCP/IP 連接的認證方式。 ## 19.3.2\. 口令認證以口令為基礎的認證方法包括`md5`,`password`。這些方法操作上非常類似，只不過口令通過連接傳送的方法不同：分別是MD5 散列、明文。如果你擔心口令被"竊聽"，那么`md5`比較合適。應該盡可能避免使用`password`。然而，`md5`不能和 [db_user_namespace](#calibre_link-1563)功能一起使用。如果連接通過SSL加密保護，那么`password`可以安全的使用（盡管如果一個用戶依賴于使用SSL， SSL證書認證可能是一個更好的選擇。） PostgreSQL數據庫口令與任何操作系統用戶口令無關。各個數據庫用戶的口令是存儲在`pg_authid`系統表里面。口令可以用 SQL 語言命令[CREATE USER](#calibre_link-15)和[ALTER ROLE](#calibre_link-17) 等管理(比如<kbd class="literal">CREATE USER foo WITH PASSWORD 'secret'</kbd>。如果沒有明確設置口令，那么存儲的口令是空并且該用戶的口令認證總會失敗。 ## 19.3.3\. GSSAPI 認證 GSSAPI是為了在RFC 2743中定義的安全認證的一個工業標準協議。 PostgreSQL根據RFC 1964支持GSSAPI 和Kerberos認證一起使用。GSSAPI 為支持它的系統提供自動身份驗證（單點登錄）。身份驗證本身是安全的，但是數據在數據連接時的傳送將會是未加密的，除非使用了SSL。當GSSAPI使用Kerberos時，它使用一個標準，主要以`_servicename_`/`_hostname_`@`_realm_`的格式。關于主要部分的信息和如何配置所需的秘鑰，請參閱[Section 19.3.5](#calibre_link-504)。 GSSAPI支持在PostgreSQL編譯時必須打開；參閱[Chapter 15](#calibre_link-1156)獲取更多信息。 GSSAPI支持下列的配置選項： `include_realm` 如果設置為1，通過身份驗證的用戶主的域名包含在通過用戶名映射的系統用戶名中([Section 19.2](#calibre_link-1258))。這對處理來自多個領域的用戶是有幫助的。 `map` 允許在系統和數據庫用戶名之間映射。參閱[Section 19.2](#calibre_link-1258)獲取細節。對于一個Kerberos主要的`username/hostbased@EXAMPLE.COM`，如果`include_realm`未啟用，那么用來映射的用戶名是`username/hostbased`，如果`include_realm`啟用了，那么就是`username/hostbased@EXAMPLE.COM`。 `krb_realm` 設置域以匹配用戶主名稱。如果設置了這個參數，那么只接受那個域中的用戶。如果沒有設置，那么任何域中的用戶都可以連接，使無論什么用戶名映射都完成。 ## 19.3.4\. SSPI 認證 SSPI是單點登錄安全身份驗證的一個Windows技術。 PostgreSQL將在`negotiate`模式下使用SSPI，當可能時將使用Kerberos并且在其他情況下會自動回滾至NTLM。 SSPI認證只當服務器和客戶端都運行Windows時工作，否則，在非Windows平臺上，GSSAPI是可用的。當使用Kerberos認證時，SSPI以和GSSAPI 一樣的方式工作；參閱[Section 19.3.3](#calibre_link-505)獲取詳細信息。 SSPI支持下列的配置選項： `include_realm` 如果設置為1，通過身份驗證的用戶主的域名包含在通過用戶名映射的系統用戶名中([Section 19.2](#calibre_link-1258))。這對處理來自多個領域的用戶是有幫助的。 `map` 允許在系統和數據庫用戶名之間映射。參閱[Section 19.2](#calibre_link-1258)獲取細節。 `krb_realm` 設置域以匹配用戶主名稱。如果設置了這個參數，那么只接受那個域中的用戶。如果沒有設置，那么任何域中的用戶都可以連接，使無論什么用戶名映射都完成。 ## 19.3.5\. Kerberos 認證 > **Note:** 本地Kerberos認證已經廢棄了而且應該只在為了向后兼容的時候使用。建議新的和升級安裝使用工業標準GSSAPI認證方法（參閱[Section 19.3.3](#calibre_link-505)）。 Kerberos是一種適用于在公共網絡上進行分布計算的工業標準的安全認證系統。對Kerberos系統的敘述超出了本文檔的范圍；總的說來它是相當復雜(同樣也相當強大)的系統。 [Kerberos FAQ](http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html)或[MIT Kerberos page](http://web.mit.edu/kerberos/www/) 是個開始學習的好地方。現存在好幾種Kerberos發布的源代碼。Kerberos 只提供安全認證，但并不加密在網絡上傳輸的查詢和數據，SSL可以用于這個目的。 PostgreSQL支持 Kerberos 5 ，Kerberos 支持必須在編譯的時候打開。參閱[Chapter 15](#calibre_link-1156)獲取更多信息。 PostgreSQL運行時像一個普通的 Kerberos 服務。服務主的名字是 `_servicename_`/`_hostname_`@`_realm_`。 `_servicename_`可以用[krb_srvname](#calibre_link-1564)配置參數在服務器端設置，或者在客戶端使用`krbsrvname`連接參數設置(又見[Section 31.1.2](#calibre_link-498))。編譯的時候，可以把安裝時的缺省`postgres`修改掉，方法是使用 `./configure --with-krb-srvnam=``_whatever_`。在大多數情況下，我們不需要修改這個參數。但是，如果需要在同一臺主機上同時安裝多套PostgreSQL，那么這個就是必須的了。有些 Kerberos 實現還可能要求其它的服務名，比如 Microsoft Active Directory 就要求服務名必須是大寫的(`POSTGRES`)。 `_hostname_` 是服務器的全限定主機名。服務主的領域就是主機的首選領域。客戶主自己必須用它們自己的PostgreSQL用戶名作為第一個部件，比如`pgusername@realm`。或者，你可以使用一個用戶名映射來從主名的第一個部件到數據庫用戶名映射。缺省的，PostgreSQL沒有檢查客戶的域；因此如果你打開了跨域的認證，并且需要驗證這個域，那么使用`krb_realm`參數或者打開`include_realm`并使用用戶名映射來檢查這個域。確認服務器的密鑰表文件是可以被PostgreSQL服務器帳戶讀取 (最好就是只讀的)。(又見[Section 17.1](#calibre_link-1237)。)密鑰文件(keytab)的位置是用配置參數 [krb_server_keyfile](#calibre_link-1565)聲明的。缺省是`/usr/local/pgsql/etc/krb5.keytab` (或者任何在編譯的時候聲明為`sysconfdir`的目錄)。密鑰表文件(keytab)是在 Kerberos 軟件里生成的，參閱 Kerberos 文檔獲取細節。下面的例子是可以用于 MIT 兼容的 Kerberos 5 實現： ``` <samp class="literal">kadmin%</samp> <kbd class="literal">ank -randkey postgres/server.my.domain.org</kbd> <samp class="literal">kadmin%</samp> <kbd class="literal">ktadd -k krb5.keytab postgres/server.my.domain.org</kbd> ``` 在和數據庫連接的時候，請確保自己對每個主都擁有一張匹配所請求的數據庫用戶名的門票。比如，對于數據庫用戶`fred`，主`fred@EXAMPLE.COM`將能夠連接。為了也允許主`fred/users.example.com@EXAMPLE.COM`，使用一個用戶名映射，在[Section 19.2](#calibre_link-1258)中描述。如果你在Apache服務器上使用了 [mod_auth_kerb](http://modauthkerb.sf.net) 和mod_perl模塊，你可以用一個mod_perl 腳本進行`AuthType KerberosV5SaveCredentials`。這樣就有了一個通過 web 的安全數據庫訪問，不需要額外的口令。 Kerberos支持下列的配置選項： `map` 允許系統和數據庫用戶名之間的映射。參閱[Section 19.2](#calibre_link-1258)獲取詳細信息。 `include_realm` 如果設置為1，通過身份驗證的用戶主的域名包含在通過用戶名映射的系統用戶名中([Section 19.2](#calibre_link-1258))。這對處理來自多個領域的用戶是有幫助的。 `krb_realm` 設置域以匹配用戶主名稱。如果設置了這個參數，那么只接受那個域中的用戶。如果沒有設置，那么任何域中的用戶都可以連接，使無論什么用戶名映射都完成。 `krb_server_hostname` 設置服務主的主機名部分。與`krb_srvname`組合，用來產生全部的服務主，也就是 `krb_srvname``/``krb_server_hostname``@`域。如果沒有設置，缺省為服務器主機名。 ## 19.3.6\. Ident 認證 ident 認證方法是通過從一個ident服務器獲取客戶端的操作系統用戶名，并使用它作為允許的數據庫用戶名（帶有一個可選的用戶名映射）。只在TCP/IP連接上支持。 > **Note:** 當ident指定為本地連接（非TCP/IP）時，將使用peer的認證（參閱[Section 19.3.7](#calibre_link-503)）。 ident支持下列的配置選項： `map` 允許在系統和數據庫用戶名之間映射。參閱[Section 19.2](#calibre_link-1258)獲取詳細信息。 "Identification Protocol"(標識協議)在 RFC 1413 里面描述。實際上每個類 Unix 的操作系統都帶著一個缺省時偵聽 113 端口的身份服務器。身份服務器的基本功能是回答類似這樣的問題："是什么用戶從你的端口 `_X_`初始化出來連接到我的端口`_Y_`上來了?"。因為在建立起物理連接后，PostgreSQL既知道`_X_`也知道`_Y_`，因此它可以詢問運行嘗試連接的客戶端的主機，并且理論上可以判斷發起連接的操作系統用戶。這樣做的缺點是它取決于客戶端的完整性：如果客戶端不可信或者被盜用，那么攻擊者可以在 113 端口上運行任何程序并且返回他們選擇的任何用戶。這個認證方法只適用于封閉的網絡，這樣的網絡里的每臺客戶機都處于嚴密的控制下并且數據庫和操作系統管理員可以比較方便地聯系上。換句話說，你必須信任運行身份(ident)服務的機器。下面是警告：身份標識協議并不適用于認證或者訪問控制協議。 --RFC 1413 有些身份服務器有一個非標準的選項，導致返回的用戶名是加密的，使用的是只有原機器的管理員知道的一個密鑰。在與PostgreSQL配合使用身份認證的時候，你_一定不能_使用這個選項，因為PostgreSQL 沒有任何方法對返回的字符串進行解密以獲取實際的用戶名。 ## 19.3.7\. Peer 認證 peer認證方法通過從內核獲得客戶端的操作系統用戶名和使用它作為允許的數據庫用戶名（使用可選的用戶名映射）工作。這個方法只支持本地連接。 peer支持下列的配置選項： `map` 允許在系統和數據庫用戶名之間映射。參閱[Section 19.2](#calibre_link-1258)獲取詳細信息。 Peer認證只能在提供`getpeereid()`函數、`SO_PEERCRED` 套接字參數或類似的機制的操作系統上適用，目前包括Linux、大多數包含Mac OS X的BSD 和Solaris。 ## 19.3.8\. LDAP 認證這個認證方法操作起來類似`password`，只不過它使用 LDAP 作為密碼驗證機制。 LDAP 只用于驗證用戶名/口令對。因此，在使用 LDAP 進行認證之前，用戶必須已經存在于數據庫里。 LDAP認證可以在兩種模式操作。在第一種模式，我們將調用簡單的綁定模式，服務器將綁定到以`_prefix_` `_username_` `_suffix_` 構造的識別名(Distinguished Name)上。通常`_prefix_` 參數用于在活動目錄環境中指定`cn=`或`_DOMAIN_``\`。 `_suffix_`用來在非活動目錄環境中指定DN的剩余部分。在第二種模式中，我們將調用搜索+綁定模式，服務器首先綁定到LDAP目錄上，帶有固定用戶名和密碼，用`_ldapbinddn_`和`_ldapbindpasswd_`指定，并且為試圖登陸到數據庫的用戶執行一次搜索。如果沒有配置用戶名和密碼，將試圖對這個目錄進行匿名綁定。將對在`_ldapbasedn_` 的子樹執行搜索，并且將試圖對`_ldapsearchattribute_`指定的屬性做一個準確匹配。一旦在這個目錄中發現了用戶，服務器斷開并且重新作為這個用戶綁定到目錄，使用客戶端指定的密碼，以驗證登陸是正確的。這個模式和在其他軟件使用的LDAP認證模式相同，例如Apache mod_authnz_ldap 和 pam_ldap。這種方法允許在目錄中的用戶對象有很大的靈活性，但是將導致兩個獨立的連接到LDAP服務器。下列的配置選項在兩種模式下都使用： `ldapserver` 連接到的LDAP服務器的名字或IP地址。可能指定多個服務器，用空格分開。 `ldapport` 連接到的LDAP服務器的端口號。如果沒有指定端口，將使用LDAP庫缺省端口。 `ldaptls` 設置為1以使PostgreSQL和LDAP服務器之間的連接使用TLS加密。注意這只加密去往LDAP服務器的流量，也就是連接到客戶端將仍然是未加密的，除非使用了SSL。下列的選項只在簡單綁定模式中使用： `ldapprefix` 當做簡單的綁定認證，綁定到DN時，前綴到用戶名的字符串。 `ldapsuffix` 當做簡單的綁定認證，綁定到DN時，附加到用戶名的字符串。下列的選項只在搜索+綁定模式中使用： `ldapbasedn` 當做搜索+綁定認證時，為用戶開始搜索的根DN。 `ldapbinddn` 當做搜索+綁定認證時，綁定到目錄并執行搜索的用戶的DN。 `ldapbindpasswd` 當做搜索+綁定認證時，綁定到目錄并執行搜索的用戶的密碼。 `ldapsearchattribute` 當做搜索+綁定認證時，在搜索中匹配用戶名的屬性。如果沒有指定屬性，將使用`uid`屬性。 `ldapurl` 一個RFC 4516 LDAP URL。這是一個在更緊湊和標準的形式中寫入一些其他LDAP選項的可選擇的方式。格式是 ``` ldap://_host_[:_port_]/_basedn_[?[_attribute_][?[_scope_]]] ``` `_scope_`必須是`base`, `one`, `sub`之一，通常是最后一個。只使用一個屬性，一些其他的標準LDAP URL的組成部分比如filters和extensions是不支持的。對于非匿名的綁定， `ldapbinddn`和`ldapbindpasswd` 必須作為獨立的選項聲明。要使用加密的LDAP連接，除了`ldapurl`，必須使用`ldaptls`選項。不支持`ldaps` URL模式(直接SSL連接）。 LDAP URL當前只支持OpenLDAP，不是在Windows上。混合簡單綁定和搜索+綁定的配置選項是錯誤的。這里是簡單綁定LDAP配置的一個例子： ``` host ... ldap ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net" ``` 當要求一個到數據庫服務器的連接作為數據庫用戶`someuser`時， PostgreSQL將試圖使用DN `cn=someuser, dc=example, dc=net`綁定到LDAP服務器，并且密碼由客戶端提供。如果那個連接成功了，那么就同意數據庫訪問。這里是搜索+綁定配置的一個例子： ``` host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchattribute=uid ``` 當要求一個到數據庫服務器的連接作為數據庫用戶`someuser`時， PostgreSQL將試圖匿名（因為沒有指定`ldapbinddn`）綁定到LDAP服務器，為`(uid=someuser)`在指定的基礎DN下執行一個搜索。如果發現一條記錄，它將試圖使用發現的信息和客戶端提供的密碼綁定。如果第二個鏈接成功，那么就同意數據庫訪問。這是相同的搜索+綁定配置，寫作一個URL： ``` host ... ldap lapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub" ``` 一些其他支持LDAP認證的軟件使用相同的URL格式，所以它將更容易共享配置。 > **Tip:** 因為LDAP經常使用逗號和空格來分開DN的不同部分，所以當配置LDAP選項時，通常需要使用雙引號參數值，就像例子中所示的一樣。 ## 19.3.9\. RADIUS 認證這個認證方法操作起來類似`password`，只不過它使用RADIUS作為密碼驗證方法。 RADIUS只用于驗證用戶名/口令對。因此，在使用RADIUS進行認證之前，用戶必須已經存在于數據庫里。當使用RADIUS認證時，一個訪問請求信息將發送到已配置好的RADIUS服務器。這個請求將會是類型`Authenticate Only`，并且包含參數 `user name`, `password` (加密的) 和 `NAS Identifier`。這個請求將使用一個和服務器秘密共享的加密。RADIUS服務器將以`Access Accept` 或`Access Reject`響應這個服務器。不支持RADIUS賬戶。 RADIUS支持下列的配置選項： `radiusserver` 連接到的RADIUS服務器的名字或IP地址。這個參數是必需的。 `radiussecret` 當安全的和RADIUS服務器對話時使用的共享秘鑰。在PostgreSQL和RADIUS服務器上必須有完全相同的值。建議至少為16個字符的字符串。這個參數是必需的。 > **Note:** 如果PostgreSQL編譯支持OpenSSL，那么加密向量將只被強大的加密使用。在其他情況下，到RADIUS服務器的傳輸應該只被認為是混淆的，不是安全的，并且必要時應該采用外部安全措施。 `radiusport` 連接到的RADIUS服務器的端口號。如果沒有指定端口，將使用缺省的端口`1812`。 `radiusidentifier` 在RADIUS請求中作為`NAS Identifier`使用的字符串。這個參數可以用作第二個參數標識，比如用戶試圖作為哪個數據庫用戶驗證，哪個可以用來在RADIUS服務器上政策匹配。如果沒有指定標識符，將使用缺省的`postgresql`。 ## 19.3.10\. 證書認證這個認證方法使用SSL證書來執行認證。因此只適用于SSL連接。當使用這個認證方法時，服務器將請求客戶端提供一個有效的證書。沒有密碼提示發送給客戶端。證書的`cn` (Common Name) 屬性將與請求的數據庫用戶名比較，如果它們匹配，登陸將被允許。用戶名映射可以用來允許`cn`不同于數據庫用戶名。 SSL證書認證支持下列的配置選項： `map` 允許在系統和數據庫用戶名之間映射。參閱[Section 19.2](#calibre_link-1258)獲取詳細信息。 ## 19.3.11\. PAM 認證這個認證方法操作起來類似`password`，只不過它使用 PAM (Pluggable Authentication Modules)作為認證機制。缺省的 PAM 服務名是`postgresql`。 PAM 只用于驗證用戶名/口令對。因此，在使用 PAM 進行認證之前，用戶必須已經存在于數據庫里。有關 PAM 的更多信息，請閱讀 [Linux-PAM頁面](http://www.kernel.org/pub/linux/libs/pam/)。 PAM支持下列的配置選項： `pamservice` PAM服務名。 > **Note:** 如果PAM設置為讀取`/etc/shadow`，那么將驗證失敗，因為PostgreSQL服務器是通過非root用戶啟動的。然而，當PAM設置為使用LDAP或其他認證方法時將不是一個問題。