From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net>, samay sharma <smilingsamay(at)gmail(dot)com> |
Cc: | Jacob Champion <pchampion(at)vmware(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, andrew(at)dunslane(dot)net, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "peter(dot)eisentraut(at)enterprisedb(dot)com" <peter(dot)eisentraut(at)enterprisedb(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Proposal: Support custom authentication methods using hooks |
Date: | 2022-03-16 19:42:53 |
Message-ID: | b3a1e2792895db145eb6d7ddcaa75299609c1530.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2022-03-16 at 11:02 -0400, Stephen Frost wrote:
> That we're having to extend this quite a bit to work for the proposed
> OAUTH patches and that it still doesn't do anything for the client
> side
> (note that the OAUTHBEARER patches are still patching libpq to add
> support directly and surely will still be even with this latest patch
> set ...) makes me seriously doubt that this is the right direction to
> be
> going in.
I don't follow this concern. I assume you're referring to the last two
bullet points, which I repeat below:
* Add support for custom auth options to configure provider's
behavior:
Even without OAUTH I think this would have been requested.
Configuration of some kind is going to be necessary. Without custom
options, I guess the provider would need to define its own config file?
Not the end of the world, but not ideal.
* Allow custom auth methods to use usermaps:
This is really just appending the "custom" method to a list of other
methods that are allowed to specify a usermap in pg_hba.conf. Again, I
don't see anything specific to OAUTH, and this would likely have been
requested regardless.
> How about- if we just added OAUTH support directly into libpq and the
> backend, would that work with Azure's OIDC provider? If not, why
> not?
> If it does, then what's the justification for trying to allow custom
> backend-only authentication methods?
I understand the point, but it also has a flip side: if custom auth
works, why do we need to block waiting for a complete core OAUTH
feature?
Authentication seems like a good candidate for allowing custom methods.
New ones are always coming along, being used in new ways, updating to
newer crypto, or falling out of favor. We've accumulated quite a few.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Zhihong Yu | 2022-03-16 19:48:09 | Re: Concurrent deadlock scenario with DROP INDEX on partitioned index |
Previous Message | Joshua Brindle | 2022-03-16 19:36:21 | Re: Granting SET and ALTER SYSTE privileges for GUCs |