From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
---|---|
To: | aht(at)8kdata(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SCRAM auth and Pgpool-II |
Date: | 2017-07-08 10:51:32 |
Message-ID: | 20170708.195132.350141937975179444.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2017-07-08 11:11:27 | Re: hash index on unlogged tables doesn't behave as expected |
Previous Message | David Fetter | 2017-07-08 08:42:13 | COPY vs. transition tables |