On 06/07/17 04:03, Tatsuo Ishii wrote:
Hi PostgreSQL hackers,
I would like to hear ideas how Pgpool-II can deal with SCRAM auth
which will be in PostgreSQL 10.
For those who are not familiar with Pgpool-II[1], it is an external
OSS project to provide some additional features to PostgreSQL,
including load balancing and automatic failover. Pgpool-II works as a
proxy between PostgreSQL client and PostgreSQL server(s).
When a client wants to connects to PostgreSQL and SCRAM auth is
enabled, it sends user name to server. Then the server sends
information including a salt to the client. The client computes a
"ClientProof" using the salt and other information, and sends it to
the server[2].
For Pgpool-II, things would go as follows:
1) clients sends user name to Pgpool-II.
2) Pgpool-II forwards it to PostgreSQL servers.
3) Each PostgreSQL server sends their own salt to Pgpool-II.
4) Pgpool-II is confused because there are multiple salts and each has
different values. The client only accepts single salt obviously.
So my question is, is there any solution or workaround for the problem
#4. Someone at PGCon 2017 suggested that the problem could be avoided
if the auth method between the client and Pgpool-II is "trust" (which
means no auth). But this does not seem to be a best solution for me
because it would weaken the security.
I suspect this problem may not be specific to Pgpool-II. Any middle
ware which handles multiple PostgreSQL servers could have the similar
problem.
Any suggestion would be appreciated. Thanks in advance.
[1] https://pgpool.net
[2] https://tools.ietf.org/html/rfc5802#section-3
Hi Tatsuo.
There's definitely an important concern here that should be
addressed: how poolers/proxies/middleware/etc can deal with SCRAM,
specifically in the context of channel binding.
If there is to be a single connection from client to PostgreSQL
server, intercepted by pgpool to perform the magic foo, then channel
binding is, indeed, designed to defeat this. If, however, pgpool or the
middleware manages two separate connections (client<->pool and
pool<->PG) then there is some light here.
One SCRAM feature not implemented as of today is the authzid
(authorization identity: see
https://tools.ietf.org/html/rfc5802#page-10, SCRAM attribute "a" and
https://tools.ietf.org/html/rfc5801). Authzid is basically "I want to
authenticate as user X and once authenticated, consider I'm user Y".
With authzid, a pool/proxy may have a common user name with its own
SCRAM credentials to authenticate with the backend PostgreSQL, and pass
the authzid with the real username (the one provided on the
client<->pool connection).
This would require:
a) That authzid is implemented in PostgreSQL.
b) A mechanism in PG to name which user(s) Y are allowed to be
authenticated by user X. This is similar, but not identical, to the
current SET ROLE.
From a SCRAM protocol perspective, this is very simple, just an
extra attribute. Part b) may need more discussion.
I believe this could be of help to your case and other middleware.
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
