On Sat, Jul 8, 2017 at 1:54 PM, Álvaro Hernández Tortosa <a...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers