| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
| Cc: | samay sharma <smilingsamay(at)gmail(dot)com>, Jacob Champion <pchampion(at)vmware(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net> |
| Subject: | Re: Proposal: Support custom authentication methods using hooks |
| Date: | 2022-03-17 17:30:32 |
| Message-ID: | 20220317173032.gg74qmqtzab6qkz5@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2022-03-17 12:10:51 +0100, Peter Eisentraut wrote:
> Looking at the existing authentication methods
>
> # METHOD can be "trust", "reject", "md5", "password", "scram-sha-256",
> # "gss", "sspi", "ident", "peer", "pam", "ldap", "radius" or "cert".
>
> how many of these could have been implemented using a plugin mechanism that
> was designed before the new method was considered? Probably not many.
trust, reject, md5, password, ident, peer, pam, ldap, radius look trivially
possible. I think sspi is doable as well, but I don't know it well enough to
be confident. gss without transport encryption could have as well, I
think. Even scram-sha-256 looks possible, although that'd have been a good bit
harder. Where do you see the problems?
Only stuff tying into transport encryption is clearly not doable via the
proposed API, but that's hardly the fault of an authentication API?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christophe Courtois | 2022-03-17 17:31:37 | Detaching a partition with a FK on itself is not possible |
| Previous Message | Bharath Rupireddy | 2022-03-17 17:05:50 | Re: Allow async standbys wait for sync replication |