Re: Proposal: Supporting URI SAN in Certificate Authentication

On Wed, Aug 26, 2026 at 03:12:07PM -0700, Jacob Champion wrote:
> On Wed, Aug 26, 2026 at 11:07 AM Florin Irion <irionr(at)gmail(dot)com> wrote:
> > > * How should multiple URI SAN entries be handled (first match,
> > > require uniqueness, mapping rules, etc.)?
> >
> > The key thing is that the client must tell PostgreSQL which user
> > they want to connect as. Then PostgreSQL looks through all the
> > mappings it found and checks if any of the SANs map to that
> > requested user. If exactly one SAN matches the user, we allow the
> > connection. If none match, we reject. If many SANs map to different
> > users but the client already said which one they want, that is fine,
> > we just use the right one.
>
> I interpreted the question about "first match" to mean: what if many
> SANs in the cert map to the *same* database user?

A deterministic rule in that case is good enough, and 'first match' is a
perfectly good rule that also minimizes the amount of work to do, so
it's the rule I would prefer.

> (IMO an implementation of this that ignored pg_ident mapping would be
> vetoable without a really, _really_ good reason, so I'm not sure that
> branch of the discussion needs to consume much energy.)

(Sure, but IMO pg_ident and pg_hba ought to be _replaced_ with DDL and
metadata stored in pg_catalog tables. This is a discussion that
deserves its own thread because once one starts down this path lots of
possibilities become available, such as radically changing the, uh,
metaschema for authorization.

But this is especially desirable given the SPIFFE motivation for this
work: the authorization database has to become significantly more
dynamic, both in that pg_ident entries need to be changed on the fly,
and in that one might want to be able to provide SQL functions to do the
work rather than table lookups.)

> > 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.

One could have a convention that some username (possibly the empty
string) is special and means 'derive the username from the
authentication credential'. SSHv2 has this, for example, at least in
the GSS-API userauth case.

> > 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.

+1.

Nico
--