database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-31 22:04:40 +03:00
Code Activity

Improve SSL-related documentation. Explain how to deal with certificate

Browse Source 
chains, do assorted wordsmithing.
This commit is contained in:
Tom Lane
2010-05-26 23:49:19 +00:00
parent 092c38a2a8
commit 1e6b654edc
4 changed files with 173 additions and 105 deletions
Download Patch File Download Diff File Expand all files Collapse all files

51
doc/src/sgml/client-auth.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.137 2010/04/21 03:32:53 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.138 2010/05/26 23:49:18 tgl Exp $ -->
<chapter id="client-authentication">
<title>Client Authentication</title>
@ -314,9 +314,9 @@ hostnossl <replaceable>database</replaceable> <replaceable>user</replaceable>
<listitem>
<para>
Reject the connection unconditionally. This is useful for
<quote>filtering out</> certain hosts from a group, e.g. a
<literal>reject</> line blocks a specific host from connecting,
but a later line allows the remaining hosts in a specific
<quote>filtering out</> certain hosts from a group, for example a
<literal>reject</> line could block a specific host from connecting,
while a later line allows the remaining hosts in a specific
network to connect.
</para>
</listitem>
@ -446,7 +446,7 @@ hostnossl <replaceable>database</replaceable> <replaceable>user</replaceable>
After the <replaceable>auth-method</> field, there can be field(s) of
the form <replaceable>name</><literal>=</><replaceable>value</> that
specify options for the authentication method. Details about which
options are available for which authentication method appear below.
options are available for which authentication methods appear below.
</para>
</listitem>
</varlistentry>
@ -624,17 +624,15 @@ local db1,db2,@demodbs all md5
in a map should be thought of as meaning <quote>this operating system
user is allowed to connect as this database user</quote>, rather than
implying that they are equivalent. The connection will be allowed if
there is any map entry that matches the user name obtained from the
external authentication system to the database user name that the
there is any map entry that pairs the user name obtained from the
external authentication system with the database user name that the
user has requested to connect as.
</para>
<para>
If the <replaceable>system-username</> field starts with a slash (<literal>/</>),
the remainder of the field is treated as a regular expression.
(See <xref linkend="posix-syntax-details"> for details of
<productname>PostgreSQL</>'s regular expression syntax.
Regular expressions in username maps are always treated as being
<quote>advanced</> flavor.) The regular
<productname>PostgreSQL</>'s regular expression syntax.) The regular
expression can include a single capture, or parenthesized subexpression,
which can then be referenced in the <replaceable>database-username</>
field as <literal>\1</> (backslash-one). This allows the mapping of
@ -768,7 +766,7 @@ omicron bryanh guest1
The password-based authentication methods are <literal>md5</>
and <literal>password</>. These methods operate
similarly except for the way that the password is sent across the
connection, i.e. respectively, MD5-hashed and clear-text.
connection, namely MD5-hashed and clear-text respectively.
</para>
<para>
@ -811,7 +809,7 @@ omicron bryanh guest1
authentication according to RFC 1964. <productname>GSSAPI</productname>
provides automatic authentication (single sign-on) for systems
that support it. The authentication itself is secure, but the
data sent over the database connection will be send unencrypted unless
data sent over the database connection will be sent unencrypted unless
<acronym>SSL</acronym> is used.
</para>
@ -821,6 +819,9 @@ omicron bryanh guest1
in the format
<literal><replaceable>servicename</>/<replaceable>hostname</>@<replaceable>realm</></literal>. For information about the parts of the principal, and
how to set up the required keys, see <xref linkend="kerberos-auth">.
</para>
<para>
GSSAPI support has to be enabled when <productname>PostgreSQL</> is built;
see <xref linkend="installation"> for more information.
</para>
@ -845,7 +846,7 @@ omicron bryanh guest1
<listitem>
<para>
Allows for mapping between system and database usernames. See
<xref linkend="auth-username-maps"> for details. For a Kerboros
<xref linkend="auth-username-maps"> for details. For a Kerberos
principal <literal>username/hostbased@EXAMPLE.COM</literal>, the
username used for mapping is <literal>username/hostbased</literal>
if <literal>include_realm</literal> is disabled, and
@ -948,7 +949,7 @@ omicron bryanh guest1
Native Kerberos authentication has been deprecated and should be used
only for backward compatibility. New and upgraded installations are
encouraged to use the industry-standard <productname>GSSAPI</productname>
authentication (see <xref linkend="gssapi-auth">) instead.
authentication method (see <xref linkend="gssapi-auth">) instead.
</para>
</note>
@ -1040,7 +1041,7 @@ omicron bryanh guest1
principal matching the requested database user name. For example, for
database user name <literal>fred</>, principal
<literal>fred@EXAMPLE.COM</> would be able to connect. To also allow
principle <literal>fred/users.example.com@EXAMPLE.COM</>, use a username
principal <literal>fred/users.example.com@EXAMPLE.COM</>, use a username
map, as described in <xref linkend="auth-username-maps">.
</para>
@ -1121,7 +1122,7 @@ omicron bryanh guest1
name (with an optional username mapping).
The determination of the client's
user name is the security-critical point, and it works differently
depending on the connection type.
depending on the connection type, as described below.
</para>
<para>
@ -1195,7 +1196,10 @@ omicron bryanh guest1
class="osname">Linux</>, <systemitem class="osname">FreeBSD</>,
<systemitem class="osname">NetBSD</>, <systemitem class="osname">OpenBSD</>,
<systemitem class="osname">BSD/OS</>, and <systemitem class="osname">Solaris</systemitem>), ident authentication can also
be applied to local connections. In this case, no security risk is added by
be applied to local connections.
<productname>PostgreSQL</> uses <symbol>SO_PEERCRED</symbol> to find out
the operating system name of the connected client process.
In this case, no security risk is added by
using ident authentication; indeed it is a preferable choice for
local connections on such systems.
</para>
@ -1272,7 +1276,7 @@ omicron bryanh guest1
<listitem>
<para>
Port number on LDAP server to connect to. If no port is specified,
the default port in the LDAP library will be used.
the LDAP library's default port setting will be used.
</para>
</listitem>
</varlistentry>
@ -1309,7 +1313,7 @@ omicron bryanh guest1
<term><literal>ldapbasedn</literal></term>
<listitem>
<para>
DN to root the search for the user in, when doing search+bind
Root DN to begin the search for the user in, when doing search+bind
authentication.
</para>
</listitem>
@ -1403,7 +1407,7 @@ ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
<para>
The shared secret used when talking securely to the RADIUS
server. This must have exactly the same value on the PostgreSQL
and RADIUS servers. It is recommended that this is a string of
and RADIUS servers. It is recommended that this be a string of
at least 16 characters. This parameter is required.
<note>
<para>
@ -1434,7 +1438,7 @@ ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
<para>
The string used as <literal>NAS Identifier</> in the RADIUS
requests. This parameter can be used as a second parameter
identifying for example which database the user is attempting
identifying for example which database user the user is attempting
to authenticate as, which can be used for policy matching on
the RADIUS server. If no identifier is specified, the default
<literal>postgresql</> will be used.
@ -1458,7 +1462,8 @@ ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
authentication. It is therefore only available for SSL connections.
When using this authentication method, the server will require that
the client provide a valid certificate. No password prompt will be sent
to the client. The <literal>cn</literal> attribute of the certificate
to the client. The <literal>cn</literal> (Common Name) attribute of the
certificate
will be compared to the requested database username, and if they match
the login will be allowed. Username mapping can be used to allow
<literal>cn</literal> to be different from the database username.
@ -1548,7 +1553,7 @@ FATAL: no pg_hba.conf entry for host "123.123.123.123", user "andym", database
<para>
<programlisting>
FATAL: Password authentication failed for user "andym"
FATAL: password authentication failed for user "andym"
</programlisting>
Messages like this indicate that you contacted the server, and it is
willing to talk to you, but not until you pass the authorization