I wrote:
> Magnus Hagander <[email protected]> writes:
>> This was changed by Peter in
>> commit 56811e57323faa453947eb82f007e323a952e1a1 along with the
>> restructuring. It used to say "the following subsections". So techically I
>> think that change is correct, but that doesn't necessarily make it helpful.
>> But based on how it actually renders, since that section doesn't contain
>> any actual useful info, we should perhaps just remove section 20.3
>> completely. Peter, thoughts?
> Then, URLs pointing to that page (such as Dave evidently has bookmarked)
> would break entirely, which doesn't seem like an improvement.
Also, our docs' own internal links to that section would break --- there
are built-in assumptions that there's one pointable-to place that explains
all the auth methods.
> I suggest changing the sect1's contents to be a list of available auth
> methods, linked to their subsections. That would provide approximately
> the same quality-of-use as the subsection TOC that used to be there.
Concretely, I propose the attached. Anybody want to editorialize on
my short descriptions of the auth methods?
regards, tom lane
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index 36e5a5d..6af1cf5 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -911,8 +911,103 @@ omicron bryanh guest1
<sect1 id="auth-methods">
<title>Authentication Methods</title>
+
+ <para>
+ <productname>PostgreSQL</productname> provides various methods for
+ authenticating users:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <link linkend="auth-trust">Trust authentication</link>, which
+ simply trusts that users are who they say they are.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <link linkend="auth-password">Password authentication</link>, which
+ requires that the user send a password.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <link linkend="gssapi-auth">GSSAPI authentication</link>, which
+ relies on a GSSAPI-compatible security library; typically this is
+ used to access an authentication server such as a Kerberos or
+ Microsoft Active Directory server.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <link linkend="sspi-auth">SSPI authentication</link>, which
+ uses a Windows-specific protocol similar to GSSAPI.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <link linkend="auth-ident">Ident authentication</link>, which
+ relies on an <quote>Identification Protocol</quote> (RFC 1413)
+ service on the client's machine. (On local Unix-socket connections,
+ this is treated as peer authentication.)
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <link linkend="auth-peer">Peer authentication</link>, which
+ relies on operating system facilities to identify the process at the
+ other end of a local connection. This is not supported for remote
+ connections.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <link linkend="auth-ldap">LDAP authentication</link>, which
+ relies on an LDAP authentication server.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <link linkend="auth-radius">RADIUS authentication</link>, which
+ relies on a RADIUS authentication server.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <link linkend="auth-cert">Certificate authentication</link>, which
+ requires an SSL connection and authenticates users by checking the
+ SSL certificate they send.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <link linkend="auth-pam">PAM authentication</link>, which
+ relies on a PAM (Pluggable Authentication Modules) library.
+ In most configurations this ends up being a variant of password
+ authentication.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <link linkend="auth-bsd">BSD authentication</link>, which
+ relies on the BSD Authentication framework (currently available
+ only on OpenBSD).
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ Peer authentication is usually recommendable for local connections,
+ though trust authentication might be sufficient in some circumstances.
+ Password authentication is the easiest choice for remote connections;
+ all the other options require some sort of external security
+ infrastructure, usually an authentication server or a certificate
+ authority for issuing SSL certificates.
+ </para>
+
<para>
- The following sections describe the authentication methods in more detail.
+ The following sections describe each of these authentication methods
+ in more detail.
</para>
</sect1>
