From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jacob Champion <pchampion(at)vmware(dot)com>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: Save user's original authenticated identity for logging |
Date: | 2021-01-31 15:17:33 |
Message-ID: | CAM-w4HPaWxXZd7ZZ=DmLUDa-R_Dp=m7CbqFnH393zuY2uirWsQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 29 Jan 2021 at 18:41, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-01-31 15:49:41 | Re: Proposal: Save user's original authenticated identity for logging |
Previous Message | Joel Jacobson | 2021-01-31 13:27:53 | [PATCH] Doc: improve documentation of oid columns that can be zero. (correct version) |