| From: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
|---|---|
| To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Cc: | VASUKI M <vasukianand0119(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, david(dot)g(dot)johnston(at)gmail(dot)com, Robert Haas <robertmhaas(at)gmail(dot)com>, myon(at)debian(dot)org |
| Subject: | Re: Custom oauth validator options |
| Date: | 2025-12-17 23:52:57 |
| Message-ID: | CAN4CZFNyTPuHnUKJH-n5AaKoi+d6bGJjnWaNzqToLWjLBBJjpg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> I forgot to mention in my reply to Zsolt, but we've supported inline
> inclusions in HBA for a few releases now. (I just frequently forget
> they exist.)
Thanks, I didn't know about that feature, that solves half of my problem.
> 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...?
For configuring the authn matching yes, the use case is multitenancy.
But for some other variables that we didn't implement yet, this could
be useful even without multitenancy.
One thing I mentioned in the previous email is the client id
validation. A practical use case of that would be restricting which
oauth clients can login to which database. I can't use a SUSET
variable with a check restricting it to ALTER DATABASE, because
database level variables are not yet available during the oauth
validator callback. I could use a login event trigger, but that seems
like a bad hack to me.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2025-12-17 23:56:13 | Re: PRI?64 vs Visual Studio (2022) |
| Previous Message | Michael Paquier | 2025-12-17 22:42:00 | Re: [Proposal] Adding callback support for custom statistics kinds |