Re: Proposal: Support custom authentication methods using hooks - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Proposal: Support custom authentication methods using hooks
Date
Msg-id 7960458a-7fa0-7c62-45bc-23dcb5bb63bb@enterprisedb.com
Whole thread Raw
In response to Re: Proposal: Support custom authentication methods using hooks  (samay sharma <smilingsamay@gmail.com>)
Responses Re: Proposal: Support custom authentication methods using hooks  (Andres Freund <andres@anarazel.de>)
List 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?




pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side
Next
From: Justin Pryzby
Date:
Subject: Re: Teach pg_receivewal to use lz4 compression