Thanks Jacob,
Il giorno gio 27 ago 2026 alle ore 00:12 Jacob Champion <
[email protected]> ha scritto:
> I interpreted the question about "first match" to mean: what if many
> SANs in the cert map to the *same* database user?
>
Well that is mainly how the user configures the pg_ident and their SANs, We
can't do much about it, no?
And initially I was looking for 1 to 1 dbuser and SAN, but it should jsut
be dbuser<->ANY SAN (once we find the first one that authenticates the user
the client requests we're good).
> I think this is better than trying to pick the first match automatically,
> because that can be confusing.
>
> I don't understand what you mean here, in the context of our startup
> handshake. We don't allow you to omit the database username from the
> startup packet, so there couldn't be any guesswork around which DB
> role a client meant to connect under.
>
Correct, I probably just expressed it badly, I was trying to make a point
that the dbuser is requested, so we just need to find a good SAN for it in
order to authenticate it. And based on the previous point, not necessarily
a unique dbuser<->SAN pair.
> > The pg_ident.conf rules let you organize this however makes sense for
> your setup.
>
> Sort of. We're currently pretty bad at allowing you to say "or" in the
> HBA. So without more design work, I don't think there's going to be a
> way to dynamically switch the `clientname` setting from CN to DN to
> URI (to email, to other SAN...); you'd have to choose one and stick to
> it for a given HBA line.
>
Yes, a user can organize the rules in every way they like , but we can not
use different `clientname` in pg_hba, that is still teh same as we have now
with e.g. CN and DN, no?
If we were to change this , it should not be part of this work IMO, no? Or
is there something I'm missing?
Cheers,
Florin
--
* Florin Irion *
* https://www.enterprisedb.com <https://www.enterprisedb.com/>*
