Re: Design Considerations for New Authentication Methods

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
rtroy(at)ScienceTools(dot)com, http://ScienceTools.com/