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


Reply via email to