From: | Jacob Champion <pchampion(at)vmware(dot)com> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Cc: | "stark(at)mit(dot)edu" <stark(at)mit(dot)edu>, "magnus(at)hagander(dot)net" <magnus(at)hagander(dot)net>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Proposal: Save user's original authenticated identity for logging |
Date: | 2021-02-02 22:22:49 |
Message-ID: | a9ee5e4e8e844d06c2bcf70c6ed3306ccb4897f1.camel@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2021-02-02 23:10:34 | Re: new heapcheck contrib module |
Previous Message | Tom Lane | 2021-02-02 22:12:55 | Re: Recording foreign key relationships for the system catalogs |