* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> We've already got a sufficiency of external authentication mechanisms. > >> If people wanted to use non-built-in authentication, we'd not be having > >> this discussion. > > > Just to be clear- lots of people *do* use the external authentication > > mechanisms we provide, particularly Kerberos/GSSAPI. SASL would bring > > us quite a few additional mechanisms (SQL-based, Berkley DB, one-time > > passwords, RSA SecurID, etc..) and would mean we might be able to > > eventually drop direct GSSAPI and LDAP support and have a better > > alternative for those who want to use password-based auth. > > My point is that we already have got a lot of external authentication > mechanisms, and it's completely unclear (to me anyway) that there is > any demand for another one.
To this point, I have had requests for various things which SASL would provide- ability to use the same password as the Unix host, SecurID support, and SQL-based (with another PG database) all come to mind. I agree that such isn't particularly relevant to this discussion though. > The unsatisfied demand is for a *built in* > mechanism, specifically one that people have more faith in than MD5. I agree that there is demand for a new mechanism which isn't MD5. I don't think *built in* is at all a requirement however- *easy to use* is. > Those who worry about that and don't mind having additional moving parts > have probably already migrated to one or another of the existing external > solutions. Certainly we'd want to make SASL-with-SCRAM easy for users to use. To the extent that the moving parts in that arrangement are hidden from view, hopefully users will use it and we get comfortable enough with it for distros to set it as the default. I am catagorically *not* worried about non-libpq client libraries and applications in this regard. For starters, those aren't end users, those are other developers who have a vested interest in supporting whatever we do. Further, Java certainly supports SASL, as do quite a few other languages (Python, PHP, Ruby, there's a few examples in Go it seems). > While I won't stand in the way of somebody adding support for an external > SASL library, I think such work has got basically zero to do with the > actual problem. I don't think that's accurate. If we provide a better mechanism for password-based authentication, even if it is through SASL, I feel pretty confident that at least the Debian based distros (which universally include SASL support for applications that support it) would support it and might even switch to it for the default (once they were comfortable with it and enough clients supported it), unless we told them not to. That doesn't address existing installations, of course, and we'd have to wait for non-libpq client to update, but things would certainly move faster if we actually had something for things to move *to*, even if that thing is SASL-based SCRAM, imv. Thanks! Stephen
signature.asc
Description: Digital signature