public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Magnus Hagander <[email protected]>
Cc: Stephen Frost <[email protected]>
Cc: Dave Cramer <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: [email protected]
Subject: Re: client auth docs seem to have devolved
Date: Wed, 18 Dec 2019 13:07:18 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CADK3HH+xQLhcPgg=kWqfogtXGGZr-JdSo=x=WQC0PkAVyxUWyQ@mail.gmail.com>
<CABUevEzWhRtMVSOyM=YkpMR9FZV3E3w2OjcFScKAjHbu3=io7g@mail.gmail.com>
<CADK3HH++WrDDfE2q9+qpuaaq-SJfbvC5csP-qFtf_JuTpffeEw@mail.gmail.com>
<CABUevEzOcEBRLug3gTpAEhvSRjqyNLsk7QY70JbM-OStj=5cYA@mail.gmail.com>
<[email protected]>
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
Attachments:
[text/x-diff] provide-summary-of-auth-methods-1.patch (3.6K, 2-provide-summary-of-auth-methods-1.patch)
download | inline diff:
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>
view thread (11+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: client auth docs seem to have devolved
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox