| PostgreSQL 9.4.4 文档 | |||
|---|---|---|---|
| 上一页 | 上一级 | 章 19. 客户端认证 | 下一页 |
下面的小节更详细地描述认证方法。
如果声明了trust认证模式，PostgreSQL 就假设任何可以连接到服务器的人都可以以任何他声明的数据库用户名(甚至超级用户名)连接。 当然，在database和user字段里面的限制仍然适用。 这个方法应该用于那些在连接到服务器已经有足够操作系统层次保护的环境里。
trust认证对于单用户工作站的本地连接是非常合适和方便的。 通常它本身并不适用于多用户环境的机器。不过，即使在多用户的机器上， 你也可以使用trust，只要你利用文件系统权限限制了对服务器的 Unix 域套接字文件的访问。 要做这些限制，你可以设置unix_socket_permissions参数(以及可能还有 unix_socket_group)，就像第 18.3 节里描述的那样。 或者你可以设置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 连接的认证方式。
以口令为基础的认证方法包括md5,password。这些方法操作上非常类似， 只不过口令通过连接传送的方法不同：分别是MD5 散列、明文。
如果你担心口令被"窃听"，那么md5比较合适。 应该尽可能避免使用password。然而，md5不能和 db_user_namespace功能一起使用。如果连接通过SSL加密保护， 那么password可以安全的使用（尽管如果一个用户依赖于使用SSL， SSL证书认证可能是一个更好的选择。）
PostgreSQL数据库口令与任何操作系统用户口令无关。 各个数据库用户的口令是存储在pg_authid系统表里面。 口令可以用 SQL 语言命令CREATE USER和ALTER ROLE 等管理(比如CREATE USER foo WITH PASSWORD 'secret'。 如果没有明确设置口令，那么存储的口令是空并且该用户的口令认证总会失败。
GSSAPI是为了在RFC 2743中定义的安全认证的一个工业标准协议。 PostgreSQL根据RFC 1964支持GSSAPI 和Kerberos认证一起使用。GSSAPI 为支持它的系统提供自动身份验证（单点登录）。身份验证本身是安全的， 但是数据在数据连接时的传送将会是未加密的，除非使用了SSL。
GSSAPI支持在PostgreSQL编译时必须打开；参阅第 15 章获取更多信息。
当GSSAPI使用Kerberos时， 它使用一个标准主体格式servicename/hostname@realm。 PostgreSQL服务器将接受任何包含在服务器使用的keytab中的主体， 但是需要注意的是，在使用krbsrvname连接参数从客户端标记连接时， 要指定正确的主要细节。(又见第 31.1.2 节)。 编译的时候，可以把安装时的缺省postgres修改掉，方法是使用 ./configure --with-krb-srvnam=whatever。在大多数情况下， 我们不需要修改这个参数。有些 Kerberos 实现还可能要求其它的服务名， 比如 Microsoft Active Directory 就要求服务名必须是大写的(POSTGRES)。
hostname 是服务器的全限定主机名。服务主的领域就是主机的首选领域。
客户主自己必须用它们自己的PostgreSQL用户名作为第一个部件， 比如pgusername@realm。或者，你可以使用一个用户名映射来从主名的第一个部件到数据库用户名映射。 缺省的，PostgreSQL没有检查客户的域；因此如果你打开了跨域的认证，并且需要验证这个域， 那么使用krb_realm参数或者打开include_realm并使用用户名映射来检查这个域。
确认服务器的密钥表文件是可以被PostgreSQL服务器帐户读取 (最好就是只读的)。(又见第 17.1 节。)密钥文件(keytab)的位置是用配置参数 krb_server_keyfile声明的。缺省是/usr/local/pgsql/etc/krb5.keytab (或者任何在编译的时候声明为sysconfdir的目录)。 出于安全原因，建议为PostgreSQL 服务器使用一个单独的keytab，而不是在系统keytab文件中开放权限。
密钥表文件(keytab)是在 Kerberos 软件里生成的，参阅 Kerberos 文档获取细节。 下面的例子是可以用于 MIT 兼容的 Kerberos 5 实现：
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，使用一个用户名映射， 在第 19.2 节中描述。
GSSAPI支持下列的配置选项：
如果设置为1，通过身份验证的用户主的域名包含在通过用户名映射的系统用户名中(第 19.2 节)。 这是推荐的配置，否则，它不可能区分开来自不同领域的同名用户。 这个参数的缺省值是0（意味着在系统用户名中不包括该域）， 但是在将来的PostgreSQL版本中可以改变为1。 用户可以明确的设置它以避免升级时遇到问题。
允许在系统和数据库用户名之间映射。参阅第 19.2 节获取细节。 对于一个GSSAPI/Kerberos，比如username@EXAMPLE.COM （或者用的较少的username/hostbased@EXAMPLE.COM）， 用于映射的缺省用户名是username （或者username/hostbased），除非 include_realm已经设置成了1（就像推荐的那样，见上文）， 这种情况下在映射时将username@EXAMPLE.COM （或者username/hostbased@EXAMPLE.COM）看做系统用户名。
设置域以匹配用户主名称。如果设置了这个参数，那么只接受那个域中的用户。如果没有设置， 那么任何域中的用户都可以连接，使无论什么用户名映射都完成。
SSPI是单点登录安全身份验证的一个Windows技术。 PostgreSQL将在negotiate模式下使用SSPI， 当可能时将使用Kerberos并且在其他情况下会自动回滚至NTLM。 SSPI认证只当服务器和客户端都运行Windows时工作， 否则，在非Windows平台上，GSSAPI是可用的。
当使用Kerberos认证时，SSPI以和GSSAPI 一样的方式工作；参阅第 19.3.3 节获取详细信息。
SSPI支持下列的配置选项：
如果设置为1，通过身份验证的用户主的域名包含在通过用户名映射的系统用户名中(第 19.2 节)。 这是推荐的配置，否则，它不可能区分开来自不同领域的同名用户。 这个参数的缺省值是0（意味着在系统用户名中不包括该域）， 但是在将来的PostgreSQL版本中可以改变为1。 用户可以明确的设置它以避免升级时遇到问题。
允许在系统和数据库用户名之间映射。参阅第 19.2 节获取细节。 对于一个GSSAPI/Kerberos，比如username@EXAMPLE.COM （或者用的较少的username/hostbased@EXAMPLE.COM）， 用于映射的缺省用户名是username （或者username/hostbased），除非 include_realm已经设置成了1（就像推荐的那样，见上文）， 这种情况下在映射时将username@EXAMPLE.COM （或者username/hostbased@EXAMPLE.COM）看做系统用户名。
设置域以匹配用户主名称。如果设置了这个参数，那么只接受那个域中的用户。如果没有设置， 那么任何域中的用户都可以连接，使无论什么用户名映射都完成。
ident 认证方法是通过从一个ident服务器获取客户端的操作系统用户名， 并使用它作为允许的数据库用户名（带有一个可选的用户名映射）。 只在TCP/IP连接上支持。
注意: 当ident指定为本地连接（非TCP/IP）时，将使用peer的认证（参阅第 19.3.6 节）。
ident支持下列的配置选项：
允许在系统和数据库用户名之间映射。参阅第 19.2 节获取详细信息。
"Identification Protocol"(标识协议)在 RFC 1413 里面描述。 实际上每个类 Unix 的操作系统都带着一个缺省时侦听 113 端口的身份服务器。 身份服务器的基本功能是回答类似这样的问题："是什么用户从你的端口 X初始化出来连接到我的端口Y上来了?"。 因为在建立起物理连接后，PostgreSQL既知道X也知道Y， 因此它可以询问运行尝试连接的客户端的主机，并且理论上可以判断发起连接的操作系统用户。
这样做的缺点是它取决于客户端的完整性：如果客户端不可信或者被盗用， 那么攻击者可以在 113 端口上运行任何程序并且返回他们选择的任何用户。 这个认证方法只适用于封闭的网络， 这样的网络里的每台客户机都处于严密的控制下并且数据库和操作系统管理员可以比较方便地联系上。 换句话说，你必须信任运行身份(ident)服务的机器。下面是警告：
身份标识协议并不适用于认证或者访问控制协议。 | ||
| --RFC 1413 | ||
有些身份服务器有一个非标准的选项，导致返回的用户名是加密的， 使用的是只有原机器的管理员知道的一个密钥。在与PostgreSQL配合使用身份认证的时候， 你一定不能使用这个选项，因为PostgreSQL 没有任何方法对返回的字符串进行解密以获取实际的用户名。
peer认证方法通过从内核获得客户端的操作系统用户名和使用它作为允许的数据库用户名 （使用可选的用户名映射）工作。这个方法只支持本地连接。
peer支持下列的配置选项：
允许在系统和数据库用户名之间映射。参阅第 19.2 节获取详细信息。
Peer认证只能在提供getpeereid()函数、SO_PEERCRED
套接字参数或类似的机制的操作系统上适用，目前包括Linux、
大多数包含OS X的BSD
和Solaris。
这个认证方法操作起来类似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服务器。
下列的配置选项在两种模式下都使用：
连接到的LDAP服务器的名字或IP地址。可能指定多个服务器，用空格分开。
连接到的LDAP服务器的端口号。如果没有指定端口，将使用LDAP库缺省端口。
设置为1以使PostgreSQL和LDAP服务器之间的连接使用TLS加密。注意这只加密去往LDAP服务器的流量， 也就是连接到客户端将仍然是未加密的，除非使用了SSL。
下列的选项只在简单绑定模式中使用：
当做简单的绑定认证，绑定到DN时，前缀到用户名的字符串。
当做简单的绑定认证，绑定到DN时，附加到用户名的字符串。
下列的选项只在搜索+绑定模式中使用：
当做搜索+绑定认证时，为用户开始搜索的根DN。
当做搜索+绑定认证时，绑定到目录并执行搜索的用户的DN。
当做搜索+绑定认证时，绑定到目录并执行搜索的用户的密码。
当做搜索+绑定认证时，在搜索中匹配用户名的属性。如果没有指定属性，将使用uid属性。
一个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格式，所以它将更容易共享配置。
提示: 因为LDAP经常使用逗号和空格来分开DN的不同部分，所以当配置LDAP选项时， 通常需要使用双引号参数值，就像例子中所示的一样。
这个认证方法操作起来类似password，只不过它使用RADIUS作为密码验证方法。 RADIUS只用于验证用户名/口令对。因此，在使用RADIUS进行认证之前，用户必须已经存在于数据库里。
当使用RADIUS认证时，一个访问请求信息将发送到已配置好的RADIUS服务器。 这个请求将会是类型Authenticate Only，并且包含参数 user name, password (加密的) 和 NAS Identifier。 这个请求将使用一个和服务器秘密共享的加密。RADIUS服务器将以Access Accept 或Access Reject响应这个服务器。不支持RADIUS账户。
RADIUS支持下列的配置选项：
连接到的RADIUS服务器的名字或IP地址。这个参数是必需的。
当安全的和RADIUS服务器对话时使用的共享秘钥。在PostgreSQL和RADIUS服务器上必须有完全相同的值。 建议至少为16个字符的字符串。这个参数是必需的。
注意: 如果PostgreSQL编译支持OpenSSL，那么加密向量将只被强大的加密使用。 在其他情况下，到RADIUS服务器的传输应该只被认为是混淆的，不是安全的，并且必要时应该采用外部安全措施。
连接到的RADIUS服务器的端口号。如果没有指定端口，将使用缺省的端口1812。
在RADIUS请求中作为NAS Identifier使用的字符串。这个参数可以用作第二个参数标识， 比如用户试图作为哪个数据库用户验证，哪个可以用来在RADIUS服务器上政策匹配。 如果没有指定标识符，将使用缺省的postgresql。
这个认证方法使用SSL证书来执行认证。因此只适用于SSL连接。当使用这个认证方法时， 服务器将请求客户端提供一个有效的证书。没有密码提示发送给客户端。 证书的cn (Common Name) 属性将与请求的数据库用户名比较， 如果它们匹配，登陆将被允许。用户名映射可以用来允许cn不同于数据库用户名。
SSL证书认证支持下列的配置选项：
允许在系统和数据库用户名之间映射。参阅第 19.2 节获取详细信息。
这个认证方法操作起来类似password，只不过它使用 PAM (Pluggable Authentication Modules)作为认证机制。缺省的 PAM 服务名是postgresql。 PAM 只用于验证用户名/口令对。因此，在使用 PAM 进行认证之前，用户必须已经存在于数据库里。 有关 PAM 的更多信息，请阅读 Linux-PAM页面。
PAM支持下列的配置选项：
PAM服务名。
注意: 如果PAM设置为读取/etc/shadow，那么将验证失败，因为PostgreSQL服务器是通过非root用户启动的。 然而，当PAM设置为使用LDAP或其他认证方法时将不是一个问题。