Re: Custom oauth validator options
| От | Zsolt Parragi |
|---|---|
| Тема | Re: Custom oauth validator options |
| Дата | |
| Msg-id | CAN4CZFNyTPuHnUKJH-n5AaKoi+d6bGJjnWaNzqToLWjLBBJjpg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Custom oauth validator options (Jacob Champion <jacob.champion@enterprisedb.com>) |
| Список | 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.
В списке pgsql-hackers по дате отправления: