Re: Design Considerations for New Authentication Methods
От | Richard Troy |
---|---|
Тема | Re: Design Considerations for New Authentication Methods |
Дата | |
Msg-id | Pine.LNX.4.33.0611021214170.1126-100000@denzel.in обсуждение исходный текст |
Ответ на | Re: Design Considerations for New Authentication Methods ("Magnus Hagander" <mha@sollentuna.net>) |
Ответы |
Re: Design Considerations for New Authentication Methods
(Stephen Frost <sfrost@snowman.net>)
Re: Design Considerations for New Authentication Methods ("Henry B. Hotz" <hotz@jpl.nasa.gov>) Re: Design Considerations for New Authentication Methods ("Magnus Hagander" <mha@sollentuna.net>) |
Список | pgsql-hackers |
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@ScienceTools.com, http://ScienceTools.com/
В списке pgsql-hackers по дате отправления:
Следующее
От: Stephen FrostДата:
Сообщение: Re: Design Considerations for New Authentication Methods