Re: Design Considerations for New Authentication Methods

> > In postgresql the client and server can specify what certificates
> > thay'll accept, there are no default trusted CAs. You can
> require the
> > client to have a certain certificate, for example. The
> client can also
> > verify the server has the expected certificate. How much
> it's used I
> > don't know, but SSL does support it.
>
> I don't think you can tie the SSL certificate to a specific
> user though...  I certainly can't recall any way to do that
> today in PG.

You can't. It's been talked about, but never done.


> > > I guess this discussion makes it sound like I've
> convinced myself to
> > > use SASL.  I still need to resolve how to do name translation.
> > > PostgreSQL wants a single unix-like name, and I haven't looked at
> > > how to properly do that translation from SASL (or GSSAPI) names.
> >
> > Usually a field in the certificate is the username
> postgresql wants,
> > which can be mapped via a table. For SASL I don't know.
>
> I expect we'll need a mapping of some sort, or perhaps a
> sasl_regexp or similar to what is done in OpenLDAP.  I don't
> recall PG supporting using the DN from a client cert in an
> SSL connection as a PG username but perhaps I missed it somewhere...

You can't today.
If we want to add username mapping in SASL or whatever, it might be a
good idea to look at generalizing the authuser-to-dbuser mapping stuff
(like we have for identmap now) into something that can be used for all
external auth methods. Instead of inventing one for every method.

//Magnus