| From: | Jacob Champion <pchampion(at)vmware(dot)com> |
|---|---|
| To: | "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net> |
| Cc: | "magnus(at)hagander(dot)net" <magnus(at)hagander(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-02-01 22:40:18 |
| Message-ID: | c4233543f0941a916ad60f555cfe9d88f9fc0c8c.camel@vmware.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2021-02-01 at 17:01 -0500, Stephen Frost wrote:
> * Jacob Champion (pchampion(at)vmware(dot)com) wrote:
> > And I'm not holding
> > my breath for LDAP servers to start implementing federated identity,
> > though that would be nice.
>
> Not sure exactly what you're referring to here but AD already provides
> Kerberos with cross-domain trusts (aka forests). The future is here..?
> :)
If the end user is actually using LDAP-on-top-of-AD, and comfortable
administering the Kerberos-related pieces of AD so that their *nix
servers and users can speak it instead, then sure. But I continue to
hear about customers who don't fit into that mold. :D Enough that I
have to keep an eye on the "pure" LDAP side of things, at least.
> > To double-check -- since giving this ability to the pg_read_all_stats
> > role would expand its scope -- could that be dangerous for anyone?
>
> I don't agree that this really expands its scope- in fact, you'll see
> that the GSSAPI and SSL user authentication information is already
> allowed under HAS_PGSTAT_PERMISSIONS().
Ah, so they are. :) I think that's the way to go, then.
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2021-02-01 22:43:00 | Re: Key management with tests |
| Previous Message | Jacob Champion | 2021-02-01 22:22:05 | Re: Proposal: Save user's original authenticated identity for logging |