Doc: add a short summary of available authentication methods.

The "auth-methods" <sect1> used to include descriptions of all our
authentication methods.  Commit 56811e573 promoted its child <sect2>'s
to <sect1>'s, which has advantages but also created some issues:
* The auth-methods page itself is essentially empty/useless.
* Links that pointed to "auth-methods" as a placeholder for all
auth methods were rendered a bit nonsensical.
* DocBook no longer provides a subsection table-of-contents here,
which formerly was a useful if terse summary of available auth methods.

To improve matters, add a handwritten list of all the auth methods.

Per gripe from Dave Cramer.  Back-patch to v11 where the previous
commit came in.

Discussion: https://postgr.es/m/CADK3HH+xQLhcPgg=kWqfogtXGGZr-JdSo=x=WQC0PkAVyxUWyQ@mail.gmail.com
This commit is contained in:
Tom Lane 2019-12-19 09:42:46 -05:00
parent a9f304f536
commit e5a37d958d
1 changed files with 94 additions and 1 deletions

View File

@ -911,8 +911,101 @@ omicron bryanh guest1
<sect1 id="auth-methods">
<title>Authentication Methods</title>
<para>
The following sections describe the authentication methods in more detail.
<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 users 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.
</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 kind of external security
infrastructure (usually an authentication server or a certificate
authority for issuing SSL certificates), or are platform-specific.
</para>
<para>
The following sections describe each of these authentication methods
in more detail.
</para>
</sect1>