MIME-Version: 1.0
References: 
 <CAN4CZFM3b8u5uNNNsY6XCya257u+Dofms3su9f11iMCxvCacag@mail.gmail.com>
 <CAOYmi+kvDACPXX_p2fF7+3CXza=VjjPTn2UDjd2dMAsgP6S53w@mail.gmail.com>
In-Reply-To: 
 <CAOYmi+kvDACPXX_p2fF7+3CXza=VjjPTn2UDjd2dMAsgP6S53w@mail.gmail.com>
From: Zsolt Parragi <zsolt.parragi@percona.com>
Date: Wed, 17 Dec 2025 09:33:51 +0000
Message-ID: 
 <CAN4CZFN6evP+gjdaEd9EJghY4GmGQ8BrxP7T9twY=ao0gPCn4Q@mail.gmail.com>
Subject: Re: Custom oauth validator options
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAN4CZFN6evP%2BgjdaEd9EJghY4GmGQ8BrxP7T9twY%3Dao0gPCn4Q%40mail.gmail.com>
Precedence: bulk

> What kinds of parameters? Having a motivating use case would be
> helpful; HBA isn't always as flexible as people assume and I want to
> make sure that we can end with a usable feature.

One issue we have is that some providers don't allow users to select
what goes into the subject claim, but do allow users to define custom
claims. Additionally, the subject claim is sometimes a random
generated id, which gets generated on the first login to the client,
and that makes it practically unusable for pg. It would require:

* user trying to login to pg
* getting rejected
* figuring out what's the subject
* adding it to pg ident / some other config
* user can finally login

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.

The postgres-keycloak-oauth-validator is in an even worse situation,
they decided to use a long list of GUC parameters[1]. The main reason
is that they use an introspection endpoint for validation instead of
the JWT, so they need multiple parameters for that. Some of these GUCs
seem redundant to me, but some of them are definitely required.

They also have parameters for the client id and debugging - those are
things we are also considering adding to our validator.

> (I'm only halfway serious with (e) -- I don't really intend to drive
> your thread straight into a wall. But when I read proposals a-c, I get
> the sinking feeling that this *should* be solved in a more radical
> way, if we could only agree on a direction...)

I tried to propose simple things that are relatively easy to
implement, and wouldn't change too much at once, so there's a
realistic change for this making into PG19. I'm not against having a
bigger goal, and continuing making it even better after that.

> A hypothetical PGC_HBA context would seem to fit nicely between
> PGC_SIGHUP and PGC_SU_BACKEND.

How would you configure that since the hba lines don't have IDs?
Should we add a "guc_name" parameter to HBA for this or something like
that? I like this idea, it would be fun to implement and see how it
works, I'm just wondering how users could use it.

[1]: https://github.com/cloudnative-pg/postgres-keycloak-oauth-validator/blob/5fceacf53c3d86fbbe18dab0341311855a89fe6a/src/kc_validator.c#L741