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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
