以下の小節では、認証方式について詳細に説明します。
trust認証が指定されるとPostgreSQLは、サーバに接続できる全ての人に対して （データベーススーパーユーザも含め）その人が指定する任意のデータベースユーザ名としてのアクセス権限が付与されていると想定します。 当然ながらdatabaseとuser列にある制限は適用されます。 この方式はサーバに接続する際に適切なオペレーティングシステムレベルの保護が掛けられている場合にのみ使用すべきです。
trust認証はユーザが1人のみのワークステーション上でローカル接続を行う場合は適切であると同時に非常に便利です。 複数ユーザが存在するマシン上では一般的に適切ではありません。 とは言っても、ファイルシステムの許可属性を使ってサーバのUnixドメインソケットファイルへのアクセスを制限すればtrust認証を複数ユーザのマシン上で使用することも可能です。 その方法は、項18.3に記載されているようにunix_socket_permissions（およびunix_socket_groupパラメータの可能性もあります）パラメータを設定します。 もしくは、unix_socket_directory設定パラメータでソケットファイルをそれに相応しく制限されているディレクトリにします。
Unixソケット接続を行うただ1つの方法は、ファイルシステムの許可を設定することです。 ローカルのTCP/IP接続は、ファイルシステムにより制限はされていません。よってローカルでファイルシステムの許可を使用するにはpg_hba.confから host ... 127.0.0.1 ...の行を削除するか、trust認証とは異なる方法に変更する必要があります。
TCP/IP接続におけるtrust認証は、trustを指定するpg_hba.confの行によってサーバに接続を許可される全てのマシン上の全てのユーザを信用（trust）できる場合にのみ相応しいものです。 ローカルホスト（127.0.0.1）以外からのTCP/IP接続にtrust認証を用いる理由はほとんど見当たりません。
パスワードをベースにした認証方式には md5、crypt、およびpasswordがあります。 これらの方式はパスワードが接続間でどのように送信されるか（それぞれMD5-hashed、crypt-encrypted、平文）を別にすれば似たような振舞いをします。 cryptによる方法は、pg_authidで暗号化されたパスワードと一緒に使用することは出来ません
もしパスワード"盗聴"攻撃に最大の関心があればmd5を使うのがよいでしょう。 バージョン7.2より前のクライアントのサポートが必要な場合のみcryptを使わなくてはいけません。 単純な passwordは（SSL、あるいは接続前後を含めた他の通信セキュリティ用のラッパを使わない限り）特にオープンなインターネット環境での接続に使用することを避けなければなりません。
PostgreSQLデータベースパスワードはオペレーティングシステムのユーザパスワードとも別のものです。 各データベースユーザのパスワードはpg_authidシステムカタログテーブルの中に格納されます。 CREATE USER foo WITH PASSWORD 'secret';のように、パスワードはSQLコマンドCREATE USERとALTER USERを使って管理できます。 デフォルトでは、パスワードが設定されない場合、格納されるパスワードはNULLとなり、そのユーザのパスワード認証は常に失敗します。
GSSAPIは、RFC 2743で定義されている安全な認証のための業界標準のプロトコルです。 PostgreSQLは、RFC 1964によりKerberos認証と共にGSSAPIをサポートします。 GSSAPIは、GSSAPIをサポートしているシステムに対して自動認証（シングルサインオン）を提供します。 認証自体は安全ですが、接続を通じて送信されるデータは、SSLが使用されていない場合は平文となります。
GSSAPIがKerberosを使用しているとき、GSSAPIは、 servicename/hostname@realmの書式において標準の原則を使用します。 原則についての情報や、どのようにして要求された鍵を設定するのかについては項21.2.5を参照してください。 GSSAPIサポートは、PostgreSQLが構築されたときに使用可能となります。詳細は、第15章を参照してください。
SSPIは、シングルサインオンで安全な認証を行うためのWindowsの技術です。 PostgreSQLは、negotiateモードにおいてSSPIを使用します。 これは、可能な場合はKerberosを使用し、他の場合については自動的にNTLMを使用することを意味しています。 SSPI認証は、サーバ、クライアントが共にWindows上で稼動しているときにのみ動作します。
Kerberos認証を使用しているとき、 SSPIは、GSSAPIと同じように動作します。 詳細は項21.2.3を参照してください。
注意: ネイティブのKerberos認証は、推奨されず互換性のためのみに使用されるべきです。新規に更新されたインストールは業界標準のGSSAPI認証を使用することを推奨しています。(詳細は項21.2.3を参照してください)
Kerberosは業界標準の安全な認証システムで、公開ネットワークにまたがった分散処理に適しています。 Kerberosシステムの説明はこの文書の範囲外で、概ねとても（強力ですが）複雑なものと言えます。 KerberosFAQあるいはMIT Kerberosページが探索を開始するにはお勧めです。 Kerberosのソースコード配布物はいくつか存在します。 Kerberosは安全な認証を提供しますが、ネットワーク越しに渡される問い合わせやデータの暗号化を行いません。 このためにはSSLを使用してください。
PostgreSQLはKerberosのバージョン5をサポートしています。Kerberos認証のサポートはPostgreSQLがビルドされた時点で開始されます。 詳細は第15章を参照してください。
PostgreSQLは通常の Kerberos サービスのように動作します。 サービスのプリンシパル名はservicename/hostname@realmです。
servicenameはkrb_srvname設定パラメータを使用したサーバ側によって設定されます。 さらに、クライアント側ではkrbsrvname接続パラメータを使用します。（項30.1も参照してください。） インストール時のデフォルトpostgres（ビルド時には./configure 7 7with-krb-srvnam=whateverを使用しています）は、変更が可能です。 多くの環境では、このパラメータは変更する必要はないでしょう。しかしながら、同一ホスト内で複数のPostgreSQLをサポートするような場合には、必要となります。 いくつかのKerberosの実装では、異なるサービス名が必要になります。Microsoftアクティブディレクトリではサービス名は（POSTGRES）のように大文字にする必要があります。
hostnameはサーバマシンの完全修飾されたホスト名です。 サービスプリンシパルのrealmはサーバマシンが提起したrealmです[訳注：プリンシパルとは大雑把に2つのものを指します。1つはサービスを受けるクライアントで、もう1つはサービスを提供するサーバアプリケーションです。どちらも、認証に関してはKerberosのKDCから見るとクライアントになります]。
クライアントのプリンシパルは第一の構成要素としてPostgreSQLのデータベースユーザ名を所有しなければなりません。 例えば、pgusername/otherstuff@realmです。 デフォルトではクライアントのrealmはPostgreSQLでチェックされません。 相互のrealm認証が使用可能になっていてrealmを確認する必要がある場合は、krb_realmパラメータを使用してください。
サーバ鍵ファイルがPostgreSQLサーバアカウントによって読み込み可能（そしてできれば読み込み専用）であることを確認してください （項17.1を参照してください）。 鍵ファイルの保存場所はkrb_server_keyfile設定パラメータで指定されます デフォルトは、/usr/local/pgsql/etc/krb5.keytab（もしくはビルド時にsysconfdirで指定されたディレクトリ）です。
keytabファイルはKerberosのソフトウェアによって作成されます。詳細はKerberosのドキュメントを参照してください。 MIT互換のKerberos5実装の例を以下に示します。
kadmin% ank -randkey postgres/server.my.domain.org kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org
データベースに接続しようとしている時要求されるデータベースユーザ名に一致するプリンシパルのチケットを所有しているか確認してください。 例えば、データベースユーザ名fredに対し、fred@EXAMPLE.COMとfred/users.example.com@EXAMPLE.COM両方のプリンシパルがデータベースサーバの認証に使用されます。
Apache Web サーバ上でmod_auth_krbとmod_perlを使うのであればmod_perlスクリプトでAuthType KerberosV5SaveCredentialsが使用可能です。 この方法により余分のパスワードを必要とせず、 Webを通して安全なデータベースアクセスができます。
ident認証方式は、クライアントのオペレーティングシステムのユーザ名を入手し、それから許可された対応するユーザ名の組み合わせを列挙したマップファイルを使用して、許可されているデータベースのユーザ名を判断します。 クライアントのユーザ名の決定はセキュリティの重大なポイントであり、接続の形式によって異なる働きをします。
"身元特定（Identification）プロトコル"についてはRFC 1413で説明されています。 事実上全てのUnix系のオペレーティングシステムの配布には、デフォルトでTCPポート113を監視するidentサーバが付属しています。 identサーバの基本的な機能は"どのユーザがポートXからの接続を開始し、自分のポートYへの接続を初期化したのか？"というような質問に答えることです。 PostgreSQLは物理的な接続が確立された時にXとYの両方を認識するので、接続するクライアントのホスト上のidentサーバに応答指令信号を送ることができ、理論的には、この方法で与えられたどの接続にもオペレーティングシステムユーザを決定できます。
この手続きの欠点は、クライアントの正直さに頼るところが大きいということです。 もしクライアントマシンが信用されない、もしくは危険に晒されている場合、攻撃者はポート113上でほぼどんなプログラムでも実行することができ、どのユーザ名でも好きに選んで返すことができます。 したがってこの認証方式は、各々のクライアントマシンが厳格な管理下にあり、データベースとシステム管理者が密接に連絡を取り合って動作している、外界から閉ざされたネットワークにのみ適していると言えます。 言い換えると、identサーバが稼働しているマシンを信用しなければなりません。 次の警告に注意してください。
身元特定プロトコルは、認証、あるいはアクセス管理プロトコルには意図されていません。 | ||
| --RFC 1413 | ||
いくつかの身元特定サーバは、ユーザ名を（マシンの管理者のみが知っているキーで）暗号化して返すような非標準のオプションを持っています。 このオプションは、身元特定サーバとPostgreSQLとを一緒に使用する場合には、使用してはいけません。 理由はPostgreSQLは、返された文字列を復号化して本当のユーザを決定するための手段を持っていないためです。
UnixドメインソケットについてSO_PEERCRED要求をサポートしているシステム（現時点ではLinux、FreeBSD、NetBSD、OpenBSD、およびBSD/OS）上では、ローカル接続に対してもident認証を適用できます。 この場合、ident認証使用による危険はありません。 実際、このようなシステム上のローカル接続では推奨される方法です。
SO_PEERCRED要求のないシステム上ではTCP/IP接続に対してのみident認証が使えます。 使ってみるにはlocalhostアドレス127.0.0.1を指定してこのアドレスに接続してください。 この方法の信頼性は、ローカルなidentサーバが信頼できる範囲までです。
identベースの認証を使う場合、接続を開始したオペレーティングシステムユーザ名を決定すると、PostgreSQLはあるデータベースシステムユーザとして接続要求をしてきているユーザが接続を許可されているかを調べます。 これはpg_hba.confファイルの中のidentキーワードの後のidentマップ引数によって制御されます。 既に定義済みのidentマップsameuserがあります。これは、どのオペレーティングシステムユーザであっても、同じ名前を持つデータベースユーザ（もし存在すれば）として接続できるように許可します。 その他のマップは手作業で作らなければいけません。
sameuser以外のidentマップは、デフォルトでクラスタのデータディレクトリにあるpg_ident.confという名前のidentマップファイルで定義されます （しかし、他の場所にマップファイルを設置することもできます。 ident_file設定パラメータを参照してください）。 通常、identマップファイルは以下の書式を持ちます。
map-name ident-username database-username
コメントと空白はpg_hba.confと同様に扱われます。 map-nameはpg_hba.confの中でこのマッピングを参照するために使われる任意の名前です。 他の2つのフィールドはどのオペレーティングシステムユーザがどのデータベースユーザで接続することが許可されるかを指定します。 同じmap-nameを、1つのマップの中で、別のユーザマッピングを指定するために繰り返し使うことができます。 何人のデータベースユーザが与えられたオペレーティングシステムユーザに対応するのか、またはその逆に関しての制限はありません。
pg_ident.confファイルは起動時と、主サーバプロセスがSIGHUP信号を受け取った時に読み込まれます。 稼働中のシステムでファイルを編集した場合は、（pg_ctl reloadあるいはkill -HUPを使用して）サーバにファイルを再読み込むように信号を送らなければなりません。
例21-1にあるpg_hba.confと一緒に使用可能なpg_ident.confファイルは例21-2で示されています。 この設定例では、 bryanh、ann、またはrobertというUnixユーザ名以外で、192.168ネットワーク上のマシンにログインしたユーザはアクセスを許可されません。 UnixユーザrobertはPostgreSQLユーザbobとして接続する時だけ許可されます。 robertやそれ以外の名前としてではありません。 annはannとしてでしか接続許可されません。 ユーザbryanhは彼自身であるbryanhでもguest1でも接続を許可されます。
この認証方式はpasswordと似ていますが、認証にLDAPを使用する点が異なります。 LDAPはユーザの名前とパスワードの組み合わせの検証のみに使用されます。 そのため、LDAPを使用して認証を行うようにする前に、ユーザはデータベースに存在しなければなりません。 使用されるサーバとそのパラメータは、pg_hba.confファイル内のldapキーワードの後に指定されます。 このパラメータの書式を以下に示します。
ldap[s]://servername[:port]/base dn[;prefix[;suffix]]
カンマはldap要素の中において複数のアイテムを指定する際に使用されます。しかし引用符が付いていないカンマはpg_hba.conf中ではアイテムのセパレータとして扱われるため、 カンマが存在することを保存するために2重引用符でldapのURLを囲むとよいでしょう。以下に例を示します。
"ldap://ldap.example.net/dc=example,dc=net;EXAMPLE\"
ldapではなくldapsを指定すると、その接続においてTLS暗号化が有効になります。 この暗号化がPostgreSQLサーバとLDAPサーバの間の接続でのみ行われることに注意してください。 クライアントとPostgreSQLサーバとの間の通信とこの設定は関係ありません。 TLS暗号化を使用するためには、PostgreSQLを構築する前にLDAPライブラリを構築しなければならないかもしれません。 プラットフォームのLDAPライブラリがサポートしている場合のみ、暗号化されたLDAPを使用することができる点に注意してください。
ポートの指定がない場合は、LDAPライブラリの構築時のデフォルトのポートが使用されます。
サーバは、クライアントから渡されるユーザ名を使用してbase dnで指定された分類名にバインドします。 prefix とsuffixが指定された場合、バインド前にユーザ名の前後に付与されます。 典型的に、prefixパラメータは、cn=やActive Directory環境のDOMAIN\の指定に使用されます。
この認証方式は認証機構としてPAM（Pluggable Authentication Modules）を使用することを除いてpasswordのように働きます。 デフォルトのPAMサービス名はpostgresqlです。 pg_hba.confファイルのpamキーワードに続けて、オプションで独自のサービス名を指定することができます。 PAMはユーザ名/パスワードの組を承認するためだけに使用されます。 PAMについての詳細はLinux-PAMページとSolaris PAMページを読んでください。
注意: PAMが/etc/shadowを読み取るように設定されている場合は、PostgreSQLがルートユーザで起動されていないため、認証は失敗するでしょう。しかしLDAPや他の認証方法と同様に、これは問題ではありません。