Re: Proposal: Save user's original authenticated identity for logging
Greg Stark <stark@mit.edu>
From: Greg Stark <stark@mit.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jacob Champion <pchampion@vmware.com>,
"sfrost@snowman.net" <sfrost@snowman.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-01-31T15:17:33Z
Lists: pgsql-hackers
On Fri, 29 Jan 2021 at 18:41, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Ah. So basically, this comes into play when you consider that some > outside-the-database entity is your "real" authenticated identity. > That seems reasonable when using Kerberos or the like, though it's > not real meaningful for traditional password-type authentication. > I'd misunderstood your point before. I wonder if there isn't room to handle this the other way around. To configure Postgres to not need a CREATE ROLE for every role but delegate the user management to the external authentication service. So Postgres would consider the actual role to be the one kerberos said it was even if that role didn't exist in pg_role. Presumably you would want to delegate to a corresponding authorization system as well so if the role was absent from pg_role (or more likely fit some pattern) Postgres would ignore pg_role and consult the authorization system configured like AD or whatever people use with Kerberos these days. -- greg
Commits
-
Add missing $Test::Builder::Level settings
- 73aa5e0cafd0 15.0 landed
- e536a2683439 14.0 landed
-
Add some information about authenticated identity via log_connections
- 9afffcb833d3 14.0 landed
-
Fix some issues with SSL and Kerberos tests
- 5a71964a832f 14.0 landed
-
Refactor all TAP test suites doing connection checks
- c50624cdd248 14.0 landed