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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to