From: Jacob Champion <pchampion@vmware.com>
To: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: stark@mit.edu <stark@mit.edu>
Cc: magnus@hagander.net <magnus@hagander.net>
Cc: sfrost@snowman.net <sfrost@snowman.net>
Cc: tgl@sss.pgh.pa.us <tgl@sss.pgh.pa.us>
Subject: Re: Proposal: Save user's original authenticated identity for logging
Date: Tue, 2 Feb 2021 22:22:49 +0000
Message-ID: <a9ee5e4e8e844d06c2bcf70c6ed3306ccb4897f1.camel@vmware.com> (raw)
In-Reply-To: <c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com>
References: <c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com>
On Thu, 2021-01-28 at 18:22 +0000, Jacob Champion wrote:
> = Proposal =
>
> I propose that every auth method should store the string it uses to
> identify a user -- what I'll call an "authenticated identity" -- into
> one central location in Port, after authentication succeeds but before
> any pg_ident authorization occurs.
Thanks everyone for all of the feedback! Here's my summary of the
conversation so far:
- The idea of storing the user's original identity consistently across
all auth methods seemed to be positively received.
- Exposing this identity through log_line_prefix was not as well-
received, landing somewhere between "meh" and "no thanks". The main
concern was log bloat/expense.
- Exposing it through the CSV log got the same reception: if we expose
it through log_line_prefix, we should expose it through CSV, but no one
seemed particularly excited about either.
- The idea of logging this information once per session, as part of
log_connection, got a more positive response. That way the information
can still be obtained, but it doesn't clutter every log line.
- There was also some interest in exposing this through the statistics
collector, either as a superuser-only feature or via the
pg_read_all_stats role.
- There was some discussion around *which* string to choose as the
identifer for more complicated cases, such as TLS client certificates.
- Other improvements around third-party authorization and role
management were discussed, including the ability to auto-create
nonexistent roles, to sync role definitions as a first-party feature,
and to query an external system for role authorization.
(Let me know if there's something else I've missed.)
== My Plans ==
Given the feedback above, I'll continue to flesh out the PoC patch,
focusing on 1) storing the identity in a single place for all auth
methods and 2) exposing it consistently in the logs as part of
log_connections. I'll drop the log_line_prefix format specifier from
the patch and see what that does to the testing side of things. I also
plan to write a follow-up patch to add the authenticated identity to
the statistics collector, with pg_get_authenticated_identity() to
retrieve it.
I'm excited to see where the third-party authz and role management
conversations go, but I won't focus on those for my initial patchset. I
think this patch has use even if those ideas are implemented too.
--Jacob
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: pgsql-hackers@postgresql.org
Cc: pchampion@vmware.com, stark@mit.edu, magnus@hagander.net, sfrost@snowman.net, tgl@sss.pgh.pa.us
Subject: Re: Proposal: Save user's original authenticated identity for logging
In-Reply-To: <a9ee5e4e8e844d06c2bcf70c6ed3306ccb4897f1.camel@vmware.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox