Re: Design Considerations for New Authentication Methods

* Martijn van Oosterhout (kleptog(at)svana(dot)org) wrote:
> 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.
That would be possible w/ SASL/EXTERNAL though, I believe.

> The encryption of a channel has nothing to do with verifying the
> client/server is who they say they are. They can be configured
> independantly. You can block Man-in-the-middle attacks without
> encrypting the channel, though it is unusual.

They don't have to be connected, that's true. In general I think it's
better when they can be though.

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

Thanks,

Stephen