* Martijn van Oosterhout (firstname.lastname@example.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
Description: Digital signature