From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | samay sharma <smilingsamay(at)gmail(dot)com> |
Cc: | Jacob Champion <pchampion(at)vmware(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "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 11:10:51 |
Message-ID: | 7960458a-7fa0-7c62-45bc-23dcb5bb63bb@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 16.03.22 21:27, samay sharma wrote:
> The only goal of this patch wasn't to enable support for Azure AD.
> That's just one client. Users might have a need to add or change auth
> methods in the future and providing that extensibility so we don't need
> to have core changes for each one of them would be useful. I know there
> isn't alignment on this yet, but if we'd like to move certain auth
> methods out of core into extensions, then this might provide a good
> framework for that.
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. So I am fundamentally confused how this patch set can make such
an ambitious claim. Maybe the scope needs to be clarified first. What
kinds of authentication methods do you want to plug in? What kinds of
methods are out of scope? What are examples of each one?
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2022-03-17 11:12:20 | Re: Teach pg_receivewal to use lz4 compression |
Previous Message | Masahiko Sawada | 2022-03-17 10:55:40 | Re: Skipping logical replication transactions on subscriber side |