On Thu, Aug 27, 2026 at 3:25 AM Florin Irion <[email protected]> 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 one that 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 is still 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
