On Thu, Aug 27, 2026 at 3:25 AM Florin Irion <irionr@gmail.com> wrote:
> 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
onethat authenticates the user the client requests we're good).
Right. (I think that's what Olivier was trying to say in the OP.)
> Yes, a user can organize the rules in every way they like , but we can not use different `clientname` in pg_hba, that
isstill teh same as we have now with e.g. CN and DN, no?
It's the "same", I guess, but you can only ever have one Subject, and
CN is a subset of DN. So IMO, it doesn't really make sense to combine
them. But that's not the case for SANs.
> If we were to change this , it should not be part of this work IMO, no? Or is there something I'm missing?
I just want to make sure that expectations are set appropriately. If
the desired end goal is that you can authenticate using the standard
Subject match _or_ a number of Subject Alternative Names (which seems
like a very reasonable thing for people to want), v1 of this feature
is unlikely to deliver that without a lot more explicit planning and
design. That's okay with me as long as it's also okay with the people
asking for the feature.
Thanks,
--Jacob
