Greetings Tatsuo,
* Tatsuo Ishii (ishii@sraoss.co.jp) wrote:
> > What I am suggesting here is that in order to handle properly SCRAM
> > with channel binding, pgpool has to provide a different handling for
> > client <-> pgpool and pgpool <-> Postgres. In short, I don't have a
> > better answer than having pgpool impersonate the server and request
> > for a password in cleartext through an encrypted connection between
> > pgpool and the client if pgpool does not know about it, and then let
> > pgpool do by itself the SCRAM authentication on a per-connection basis
> > with each Postgres instances. When using channel binding, what would
> > matter is the TLS finish (for tls-unique) or the hash server
> > certificate between Postgres and pgpool, not between the client and
> > pgpool. But that's actually the point you are raising here:
>
> Using a clear text password would not be acceptable for users even
> through an encrypted connection, I think.
Really, I don't think users who are concerned with security should be
using the md5 method either.
What would be really nice for such cases is support for Kerberos and
delegated Kerberos credentials. Having pgpool support that would remove
the need to deal with passwords at all.
Ditto for having postgres_fdw support same. More often than not,
Kerberos deployments (via AD, generally) is what I find in the
enterprises that I work with and they're happy to see we have Kerberos
but it's disappointing when they can't use Kerberos with either
connection poolers or with FDWs.
Thanks!
Stephen