On Thu, 2 Nov 2006, Magnus Hagander wrote: > > > > 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
Well, there's simply no need. While I can agree that more could be done, I'm not convinced there's a need because what we have now works fine. Let me support my view by stating first that I perceive that combining the conception of encrypting a communications channel with user authentication to be a very poor choice. I gather from the paragraph above that this is a forgone conclusion. Appologies if I'm mistaken. Just so my point - that another strategy is not needed - is understood, let's agree that SSL is just preventing sniffers from capturing whatever else goes on in "our conversation." Great. What's inside that communication? Why, there's a perfectly workable username/password authentication that happens! Sure, someone could steal that data somehow and break in, but that requires one of the two systems to be breached, and that's a security problem that's out of scope for Postgres. Would signed certificates be preferred? Well, sure, they're nice. I don't object, and in fact welcome some improvements here. For example, I'd love the choice of taking an individual user's certificate and authenticating completely based upon that. However, while this _seems_ to simplify things, it really just trades off with the added cost of managing those certs - username/password is slam-dunk simple and has the advantage that users can share one authentication. Unless I've really overlooked something basic, there's nothing lacking in the existing scheme... Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate