Re: Custom oauth validator options
| От | VASUKI M |
|---|---|
| Тема | Re: Custom oauth validator options |
| Дата | |
| Msg-id | CAE2r8H55geNFtECuFunpgn0LJK2+rntGuTeqNr6mP7gGhWFRbA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Custom oauth validator options (Zsolt Parragi <zsolt.parragi@percona.com>) |
| Ответы |
Re: Custom oauth validator options
|
| Список | pgsql-hackers |
Hi All,
The core issue,as you said,is that OAuth validators can add custom validation logic,but they can't define their own authentication-related parameters in pg_hba.conf,where they naturally belong.Because of that,validator-specific config ends up pushed into postgresql.conf via GUCs,which feels a bit awkward and scattered.
That leads to the same points you mentioned:
1]OAuth configuration gets split between pg_hba.conf and postgres.conf,which is confusing to reason about.
2]using multiple OIDC/OAuth providers with different parameter sets on a single Postgresql instance is hard(or effectively impossible),even though it's a pretty reasonable use case.
Given the constraints of the current HBA model(and similar issues that recently came up with SNI),I agree that anything involving generic extensibility or nested configuration would be a big hammer and likely too complex.
I also have two related questions, which might be addressed as part of
the above or independently:
1. HBA options are parsed sequentially. If validator-specific options
are tied to a particular validator, this implies that validator=...
must appear before its parameters when multiple validators are loaded,
since we cannot otherwise determine which validator is used. Is this
acceptable behavior, or should options be allowed in any order?
2. If a validator introduces many options, an HBA line could become
very long and hard to read. Would it make sense to allow loading the
parameters for a given line from a separate file? This might already
be useful today: for example, if a long issuer URL is repeated across
several HBA lines, it could instead be defined once in an external
file and referenced multiple times.
So the direction I'm most aligned with is option (b): letting OAuth validator advertise a limited list of additional valid option names for pg_hba.conf,while keeping parsing,ordering rules,and validation firmly in core.That seems like the least spicy option-incremental,OAuth-scoped,and not a redesign of HBA parsing.
Reg. ordering:requiring validator= to appear before validator-specific options feels acceptable to me if this is pursued,since it keeps parsing simple and avoids ambiguity.
Reg very long HBA lines: totally agree this is a real readability issue,but allowing per-line includes or external file feels like a seperate(and much bigger)topic,probably best tackled independently.
Overall, +1 that this limitation is real and worth discussing.I’ll plan to send a patch shortly exploring option (b).
Regards,
Vasuki M
CDAC,Chennai.
В списке pgsql-hackers по дате отправления: