Hi Alvaro,
> 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.
That's ambitious. Thank you for the info!
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp