Re: Custom oauth validator options
| От | VASUKI M |
|---|---|
| Тема | Re: Custom oauth validator options |
| Дата | |
| Msg-id | CAE2r8H439jg+e5gXJpNNMoroe4CfWauDRfUBZC_9NUNTOhqzBQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Custom oauth validator options (Jacob Champion <jacob.champion@enterprisedb.com>) |
| Ответы |
Re: Custom oauth validator options
|
| Список | pgsql-hackers |
On Thu, Dec 18, 2025 at 12:31 AM Jacob Champion <jacob.champion@enterprisedb.com> wrote:
On Wed, Dec 17, 2025 at 1:28 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> Instead we decided to let everyone configure which claim they want to
> use for user mapping. But because of that, this is a GUC, and they can
> only configure it once pre server.
We're getting closer; I agree that this needs to be more flexible than
it is, and I'm on board with a change, but I'm still missing the
"killer app". What's the case where a user has multiple HBA lines that
all want to use unrelated claims for authentication to one Postgres
cluster? Is this multi-tenancy, or...?
Beyond multitenancy,per -HBA OAuth cases where options are needed for safe provider migration[blue/green],per-database security policies,mixed Human/machine authentication[JWT/Introspection] and incident-response scenarios -all global GUCs are too coarse.
See also the old conversation regarding LDAP hba/ident
[1]
[1] https://postgr.es/m/CAOuzzgpFpuroNRabEvB9kST_TSyS2jFicBNoXvW7G2pZFixyBw%40mail.gmail.com
Thanks, Will go through it.
Regards,
Vasuki M
CDAC,Chennai.
В списке pgsql-hackers по дате отправления: