?
This document uses PHP Chinese website manual Release
19.3. 認證方法
下面的小節(jié)更詳細地描述認證方法。
19.3.1. 認證方法
如果聲明了trust認證模式， PostgreSQL 就假設任何可以連接到服務器的人都可以以任何他聲明的數(shù)據(jù)庫用戶名 (即便是超級用戶)連接。當然，在database 和 user字段里面的限制仍然適用。 這個方法應該用于那些在連接到服務器已經有足夠操作系統(tǒng)層次保護的環(huán)境里。
trust認證對于單用戶工作站的本地連接是非常合適和方便的。 通常它本身并不適用于多用戶環(huán)境的機器。 不過，即使在多用戶的機器上，你也可以使用trust ， 只要你利用文件系統(tǒng)權限限制了對服務器的Unix域套接字文件的訪問。 要做這些限制，你可以設置unix_socket_permissions參數(shù) (以及可能還有unix_socket_group)，就像Section 18.3里描述的那樣。 或者你可以設置unix_socket_directory， 把Unix域套接字文件放在一個經過恰當限制的目錄里。
設置文件系統(tǒng)權限只能幫助Unix套接字連接， 它不會通過文件系統(tǒng)權限限制本地TCP/IP連接。 因此，如果你想利用文件系統(tǒng)權限來控制本地安全， 那么刪除pg_hba.conf文件中的host ... 127.0.0.1 ... 行， 或者把它改為一個非trust的認證方法。
trust認證模式只適合TCP/IP連接， 只有在你信任那些pg_hba.conf行上所有機器中的所有用戶的時候才是合適的。 很少有理由使用trust作為任何除來自localhost(127.0.0.1) 以外的TCP/IP連接的認證方式。
19.3.2. 口令認證
以口令為基礎的認證方法包括md5和password 。 這些方法操作上非常類似，只不過口令通過連接傳送的方法不同：MD5散列、crypt加密、明文。 一個限制是crypt不能使用存儲在pg_authid中已加密的口令。
如果你擔心口令"sniffing"被竊聽，那么md5比較合適，簡單的password應始終盡量避免。然而，md5不能和db_user_namespace特性一起使用。如果連接受SSL加密保護，那么password使用安全（盡管SSL證書認證可能是一個更好的選擇，如果一個是取決于使用SSL）。
PostgreSQL 數(shù)據(jù)庫口令與任何操作系統(tǒng)用戶口令無關。各個數(shù)據(jù)庫用戶的口令是存儲在pg_authid系統(tǒng)表里面?？诹羁梢杂肧QL語言命令CREATE USER和ALTER USER等管理(比如CREATE USER foo WITH PASSWORD 'secret'; 。缺省時，如果沒有明確設置口令，那么存儲的口令是空并且該用戶的口令認證總會失敗。
19.3.3. GSSAPI認證
GSSAPI是在RFC 2743中定義的安全認證的一個行業(yè)標準協(xié)議。 PostgreSQL按照RFC 1964支持GSSAPI和Kerberos認證。 GSSAPI為支持系統(tǒng)提供自動驗證（單點登錄）。認證本身是安全的，但通過數(shù)據(jù)庫連接發(fā)送的數(shù)據(jù)將不加密發(fā)送，除非使用SSL。
當GSSAPI使用Kerberos， 在形式servicename/hostname@realm 中使用標準格式。對于信息的主要部分，如何建立所需的密鑰，參閱Section 19.3.5。
當建立PostgreSQL時，GSSAPI支持必須啟用，參閱Chapter 15獲取詳細信息。
GSSAPI下列配置選項：
- include_realm
如果設置為1，認證用戶的名字范圍 主要包括通過用戶名映射(Section 19.2)的系統(tǒng)用戶名。這對處理來自多個領域的用戶非常有用。
- map
允許在系統(tǒng)和數(shù)據(jù)庫用戶名之間映射。參閱Section 19.2 獲得詳情。 一個Kerberos原則username/hostbased@EXAMPLE.COM， 如果include_realm和 username/hostbased@EXAMPLE.COM被禁用，include_realm被啟用，用于映射的用戶名是username/hostbased。
- krb_realm
設置匹配用戶主要名稱的范圍。如果這個參數(shù) 設置了，該領域唯一的用戶將被接受。如果沒有設置， 任何領域的用戶可以連接，服從任何用戶名映射。
19.3.4. SSPI認證
SSPI是單點登錄的安全認證Windows技術。 PostgreSQL在negotiate模式中使用SSPI， 在可能的情況，并自動回落到任何情況下的NTLM時。這將使用Kerberos。 當服務器和客戶機正在運行Windows時，僅運行SSPI認證。
當正在使用Kerberos認證時，SSPI和GSSAPI 的工作方式相同；參閱Section 19.3.3獲得詳情。
SSPI支持下列配置選項：
- include_realm
如果設置為1，認證用戶的名字范圍 主要包括通過用戶名映射(Section 19.2)的系統(tǒng)用戶名。這對處理來自多個領域的用戶非常有用。
- map
允許系統(tǒng)和數(shù)據(jù)庫的用戶名之間映射。參閱Section 19.2獲得詳情。
- krb_realm
設置匹配用戶主要名稱的范圍。如果這個參數(shù) 設置了，該領域唯一的用戶將被接受。如果沒有設置， 任何領域的用戶可以連接，服從任何用戶名映射。
19.3.5. Kerberos認證
Note: 本地Kerberos認證已過時，只是為了向后兼容。新的和升級安裝 鼓勵使用行業(yè)標準GSSAPI認證方法（參閱Section 19.3.3）。
Kerberos是一種適用于在公共網絡上進行分布計算的工業(yè)標準的安全認證系統(tǒng)。 對Kerberos系統(tǒng)的敘述遠遠超出了本文檔的范圍； 總的說來它是相當復雜(同樣也相當強大)的系統(tǒng)。 KerberosFAQ 或MIT Kerberos page是個開始學習的好地方。 現(xiàn)存在好幾種Kerberos發(fā)布的源代碼。Kerberos只提供安全認證， 但并不加密在網絡上傳輸?shù)牟樵兒蛿?shù)據(jù)，SSL可以用于這個目的。
PostgreSQL支持Kerberos 5，Kerberos支持必須在PostgreSQL編譯的時候打開。參閱Chapter 15獲取更多信息。
PostgreSQL運行時像一個普通的Kerberos服務。 服務主的名字是servicename/hostname@realm 。
servicename 可以用 krb_srvname 配置參數(shù)在服務器端設置， 或者在客戶端使用krbsrvname連接參數(shù)設置(又見Section 31.1)。編譯的時候， 可以把安裝時的缺省postgres 修改掉， 方法是使用./configure --with-krb-srvnam=whatever。 在大多數(shù)情況下，我們不需要修改這個參數(shù)。 但是，如果需要在同一臺主機上同時安裝多套PostgreSQL ， 那么這個就是必須的了。有些Kerberos實現(xiàn)還可能要求其它的服務名， 比如Microsoft Active Directory就要求服務名必須是大寫的(POSTGRES)。
hostname是服務器的全限定主機名。服務主的領域就是主機的首選領域。
客戶主自己必須用它們自己的PostgreSQL用戶名作為第一個部件， 比如pgusername/otherstuff@realm 。另外，你可以使用一個用戶名 映射對主體名的第一個組件到數(shù)據(jù)庫用戶名。 默認情況下，PostgreSQL沒有檢查客戶的域；如果你有跨域 啟用認證和需要驗證域，使用krb_realm參數(shù)，或啟用include_realm 和使用用戶名映射到檢查域。 因此如果你打開了跨域的認證， 那么在任意域里任何可以和你通訊的主都會被接受。
確認服務器的密鑰表文件是可以被 PostgreSQL服務器帳戶讀取(最好就是只讀的) (又見Section 17.1)密鑰文件(keytab)的位置是用 配置參數(shù) krb_server_keyfile 聲明的。 缺省是/usr/local/pgsql/etc/krb5.keytab (或者任何在編譯的時候聲明為sysconfdir的目錄)。
密鑰表文件(keytab)是在Kerberos軟件里生成的，參閱Kerberos文檔獲取細節(jié)。 下面的例子是可以用于MIT兼容的Kerberos 5實現(xiàn)：
kadmin% ank -randkey postgres/server.my.domain.org kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org
當連接到數(shù)據(jù)庫，確保你有一個主要匹配請求數(shù)據(jù)庫用戶名的標簽 。例如，對于數(shù)據(jù)庫用戶的名稱 fred，主要 fred@EXAMPLE.COM將能夠連接。也允許 主要fred/users.example.com@EXAMPLE.COM，使用一個用戶名地圖，正如在Section 19.2 描述的。
如果你在Apache服務器上使用了 mod_auth_kerb 和mod_perl 模塊， 你可以用一個mod_perl 腳本進行 AuthType KerberosV5SaveCredentials 。 這樣就有了一個通過web的安全數(shù)據(jù)庫訪問，不需要額外的口令。
下面配置選項支持Kerberos:
- map
允許系統(tǒng)和數(shù)據(jù)庫的用戶名之間映射。參閱Section 19.2獲得詳情。
- include_realm
如果設置為1，認證用戶的名字范圍 主要包括通過用戶名映射(Section 19.2)的系統(tǒng)用戶名。這對處理來自多個領域的用戶非常有用。
- krb_realm
設置匹配用戶主要名稱的范圍。如果這個參數(shù) 設置了，該領域唯一的用戶將被接受。如果沒有設置， 任何領域的用戶可以連接，服從任何用戶名映射。
- krb_server_hostname
設置主服務器主體名稱的一部分。 即，連接krb_srvname，用于生成 完整的服務主體，也就是 krb_srvname/krb_server_hostname@REALM。 如果沒有設置，默認是服務器主機名。
19.3.6. 給予Ident的認證
ident認證方法是通過獲取客戶端的操作系統(tǒng)用戶名，使用它作為允許數(shù)據(jù)庫用戶 名稱（可選的用戶名映射），判斷客戶端的用戶名是非常關鍵的安全點，根據(jù)連接類型的不同，它的實現(xiàn)方法也略有不同，正如下面描述的。
下面配置選項支持ident:
- map
允許在系統(tǒng)和數(shù)據(jù)庫用戶名之間匹配。參閱Section 19.2獲取詳情。
19.3.6.1. 透過TCP/IP的認證
"Identification Protocol"(標識協(xié)議) 在RFC 1413里面描述。 實際上每個類Unix的操作系統(tǒng)都帶著一個缺省時偵聽113端口的身份服務器。 身份服務器的基本功能是回答類似這樣的問題： "是什么用戶從你的端口X初始化出來連接到我的端口Y上來了?" 。 因為在建立起物理連接后，PostgreSQL既知道X也知道Y， 因此它可以詢問運行嘗試連接的客戶端的主機，并且理論上可以用這個方法判斷發(fā)起連接的操作系統(tǒng)用戶。
這樣做的缺點是它取決于客戶端的完整性： 如果客戶端不可信或者被攻擊者攻破， 而且它們可以在113端口上運行任何程序并且返回他們選擇的任何用戶的話， 就無法認證了。因此這個認證方法只適用于封閉的網絡， 這樣的網絡里的每臺客戶機都處于嚴密的控制下并且數(shù)據(jù)庫和操作系統(tǒng)管理員可以比較方便地聯(lián)系上。 換句話說，你必須信任運行身份(ident)服務的機器。下面是警告：
| ? | 身份標識協(xié)議并不適用于認證或者訪問控制協(xié)議。 |
? |
| --RFC 1413 | ? | |
有些身份服務器有一個非標準的選項， 導致返回的用戶名是加密的， 使用的是只有原機器的管理員知道的一個密鑰。 在與PostgreSQL配合使用身份認證的時候， 你一定不能使用這個選項，因為PostgreSQL 沒有任何方法對返回的字符串進行解密以獲取實際的用戶名。
19.3.6.2. 透過本地套接字的身份認證
在支持用于Unix域套接字的SO_PEERCRED請求的系統(tǒng)上 (當前Linux, FreeBSD, NetBSD, OpenBSD, BSD/OS,和Solaris), 身份認證也可以適用于本地連接。 PostgreSQL用SO_PEERCRED以找出連接客戶端進程的操作系統(tǒng)的名稱。 這個時候，使用身份認證不會增加安全風險； 實際上這也是在這種系統(tǒng)上使用本地連接時的首選方法。
在沒有SO_PEERCRED請求的系統(tǒng)上， 身份認證只能通過TCP/IP連接獲取。 如果需要繞開這個限制， 我們可以聲明localhost 地址 127.0.0.1 ， 然后讓連接指向這個地址。 這個方法適用于你信任本機身份認證服務器的場合。
19.3.7. LDAP認證
這個認證方法操作起來類似password ， 只不過它使用LDAP作為密碼驗證方法。 LDAP只用于驗證用戶名/口令對。 因此，在使用LDAP進行認證之前，用戶必須已經存在于數(shù)據(jù)庫里。
LDAP身份驗證可以在兩種模式下運行。在第一種模式中， 服務器將綁定構造的prefix username suffix可分辨名稱。 通常情況下，prefix參數(shù)用于指定主目錄環(huán)境下的 cn=, 或者DOMAIN\。suffix用來指定非主目錄環(huán)境中的DN留下的一部分。
在第二種模式中，服務器首先用一個固定的用戶名和密碼綁定到LDAP目錄 ，指定ldapbinduser 和ldapbinddn，并執(zhí)行一個用戶試圖登錄到數(shù)據(jù)庫的搜索。 如果沒有用戶名和密碼配置， 將嘗試匿名綁定到目錄。 在ldapbasedn子樹搜索，將嘗試 做一個在ldapsearchattribute中指定屬性的精確匹配。 如果沒有指定屬性， uid屬性將被使用。一旦用戶已發(fā)現(xiàn) 這個搜索，服務器斷開，用戶重新結合目錄，使用由客戶指定的密碼，以驗證 登錄是正確的。 這種方法可以在用戶對象所在的目錄顯示更大的靈活性，但會造成兩個單獨的LDAP服務器連接。
LDAP支持下列配置選項：
- ldapserver
LDAP服務器連接的名稱或IP。
- ldapport
連接到LDAP服務器的端口號。如果沒有指定端口， LDAP庫的默認端口設置將被使用。
- ldaptls
設置1以使PostgreSQL和 LDAP服務器之間的連接使用TLS加密。請注意，這里僅加密 LDAP服務器的流量—客戶端連接 將不被加密，除非使用SSL。
- ldapprefix
當做簡單綁定認證，追加到形成DN綁定為用戶名的字符串。
- ldapsuffix
當做簡單綁定認證，追加到形成DN綁定為用戶名的字符串。
- ldapbasedn
當做搜索+綁定認證時，根DN開始在用戶搜索。
- ldapbinddn
當做搜索+綁定認證時，用戶的DN綁定到目錄執(zhí)行搜索。
- ldapbindpasswd
當做搜索+綁定認證時，用戶密碼綁定到該目錄執(zhí)行搜索。
- ldapsearchattribute
當做搜索+綁定認證時，歸因為在搜索中匹配用戶名。
Note: 由于LDAP通常使用逗號和空格分隔不同 DN的部分，當配置LDAP選項,它常常需要使用雙引號參數(shù) 值，例如：
ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
19.3.8. RADIUS認證
這種認證方法類似于 password，除非它使用RADIUS 作為密碼驗證方式。 RADIUS是只用于驗證 用戶名/密碼對。因此，RADIUS用于認證之前，用戶必須已經存在數(shù)據(jù)庫中。
當使用RADIUS認證時，訪問請求消息將被發(fā)送到 配置的RADIUS服務器。這一請求類型于Authenticate Only, 包含參數(shù)為 user name, password (加密)和 NAS Identifier。請求將使用 與服務器共享一個密鑰加密。RADIUS服務器將響應Access Accept或者 Access Reject的服務器。不支持RADIUS記錄。
RADIUS支持下列配置選項：
- radiusserver
連接到RADIUS服務器的名稱或IP地址。此參數(shù)是必需的。
- radiussecret
-
當談到RADIUS服務器，使用共享的秘密。在PostgreSQL和RADIUS服務器必須有相同的值。建議，這是一個至少16個字符的字符串 。此參數(shù)是必需的。
Note: 如果PostgreSQL建立支持OpenSSL，使用加密載體將增強加密。 在其他情況下，傳輸?shù)絉ADIUS服務器應該被視為混淆，沒有保障， 如有必要，應采用外部安全措施。
- radiusport
連接到RADIUS服務器上的端口號。如果沒有指定端口，則默認端口1812將使用。
- radiusidentifier
在RADIUS請求中字符串作為NAS Identifier。 這個參數(shù)作為第二個參數(shù)標識例子，用戶正試圖認證為數(shù)據(jù)庫用戶。 它可用于策略匹配在RADIUS服務器。如果沒有指定標識符，默認使用 postgresql。
19.3.9. 證書認證
這種認證方法使用SSL客戶端證書執(zhí)行 認證。因此，只適用于SSL連接。 使用這種認證方法時，服務器會要求 客戶端提供一個有效的證書。沒有密碼的提示將被發(fā)送 到客戶端。證書的cn（通用名）屬性 將比較被請求的數(shù)據(jù)庫用戶名，如果匹配 將允許登錄。使用用戶名映射，允許 cn不同于數(shù)據(jù)庫的用戶名。
SSL證書認證支持下列配置選項：
- map
允許在系統(tǒng)和數(shù)據(jù)庫用戶名間映射。參閱Section 19.2獲取詳情。
19.3.10. PAM認證
這個認證方法操作起來類似password ， 只不過它使用PAM作為認證機制。 缺省的PAM服務名是postgresql 。 你可以在pg_hba.conf文件的pam關鍵字后面提供自己的可選服務名。 PAM只用于驗證用戶名/口令對。 因此，在使用PAM進行認證之前，用戶必須已經存在于數(shù)據(jù)庫里。 有關PAM的更多信息，請閱讀 Linux-PAM Page頁面和 Solaris PAM Page頁面。
PAM支持下列配置選項：
- pamservice
PAM服務名稱。
Note: 如果PAM設置讀取/etc/shadow，認證 將會失敗，因為PostgreSQL服務器是由一個非root用戶啟動 。然而，當PAM配置使用LDAP或其他身份驗證方法，這不是一個問題。