Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ihdjM-0000Ld-Hd for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Dec 2019 18:07:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ihdjL-0001g9-AI for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Dec 2019 18:07:27 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ihdjK-0001fy-Ti; Wed, 18 Dec 2019 18:07:27 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ihdjI-0002Wr-6g; Wed, 18 Dec 2019 18:07:25 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id xBII7IPw010980; Wed, 18 Dec 2019 13:07:18 -0500 From: Tom Lane To: Magnus Hagander cc: Stephen Frost , Dave Cramer , Peter Eisentraut , PostgreSQL-development , pgsql-docs@lists.postgresql.org Subject: Re: client auth docs seem to have devolved In-reply-to: <13336.1576598463@sss.pgh.pa.us> References: <13336.1576598463@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Tue, 17 Dec 2019 11:01:03 -0500" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <10918.1576692360.0@sss.pgh.pa.us> Date: Wed, 18 Dec 2019 13:07:18 -0500 Message-ID: <10979.1576692438@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10918.1576692360.1@sss.pgh.pa.us> I wrote: > Magnus Hagander 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 ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="provide-summary-of-auth-methods-1.patch"; charset="us-ascii" Content-ID: <10918.1576692360.2@sss.pgh.pa.us> Content-Description: provide-summary-of-auth-methods-1.patch 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 Authentication Methods + + + PostgreSQL provides various methods for + authenticating users: + + + + + Trust authentication, which + simply trusts that users are who they say they are. + + + + + Password authentication, which + requires that the user send a password. + + + + + GSSAPI authentication, 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. + + + + + SSPI authentication, which + uses a Windows-specific protocol similar to GSSAPI. + + + + + Ident authentication, which + relies on an Identification Protocol (RFC 1413) + service on the client's machine. (On local Unix-socket connections, + this is treated as peer authentication.) + + + + + Peer authentication, 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. + + + + + LDAP authentication, which + relies on an LDAP authentication server. + + + + + RADIUS authentication, which + relies on a RADIUS authentication server. + + + + + Certificate authentication, which + requires an SSL connection and authenticates users by checking the + SSL certificate they send. + + + + + PAM authentication, which + relies on a PAM (Pluggable Authentication Modules) library. + In most configurations this ends up being a variant of password + authentication. + + + + + BSD authentication, which + relies on the BSD Authentication framework (currently available + only on OpenBSD). + + + + + + + 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. + + - The following sections describe the authentication methods in more detail. + The following sections describe each of these authentication methods + in more detail. ------- =_aaaaaaaaaa0--