On Sat, Jul 8, 2017 at 1:54 PM, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
> 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.
Thanks. You are putting is more simple words the concepts I am coming
at. One issue is how to send the password to pgpool, which needs to
have it in cleartext for the SASL exchange with each Postgres backend.
> 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 RFC paragraph is relevant as well:
https://tools.ietf.org/html/rfc4422#section-2. Nothing will happen in
PG10 regarding that part.
> 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.
A more granular SET SESSION AUTHORIZATION then?
--
Michael
