Re: dblink: Add SCRAM pass-through authentication

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: dblink: Add SCRAM pass-through authentication
Date: 2025-03-18 19:32:35
Message-ID: bce9a483-2128-41af-9f73-e6b9df31c1ba@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 18.03.25 17:53, Jacob Champion wrote:
> On Tue, Mar 18, 2025 at 9:35 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>> So the way I understand this is that the options are:
>>
>> (1) We add a libpq function like PQconnectionUsedScramKeys() in the
>> style of PQconnectionUsedPassword() and call that function during the
>> checks.
>>
>> (2) We make use_scram_passthrough=true imply require_auth=scram-sha-256.
>> This is essentially a way to get the info from (1) out of libpq using
>> existing facilities.
>
> Right.
>
>> But it would preempt certain setups that might
>> otherwise work. (Which ones? Are they important?)
>
> If the backend HBA later changes, to require delegated GSS or a
> different type of password authentication, the user will have to unset
> use_scram_passthrough (or ask the owner of the foreign server to unset
> it). Whereas before they could just add a password to their user
> mapping or enable delegation to move forward immediately.
>
> I think this is probably not a serious limitation, in practice.

Yeah, I think option (2) is enough for now. If someone wants to enable
the kinds of things you describe, they can always come back and
implement option (1) later.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2025-03-18 19:45:20 Re: Simplify the logic a bit (src/bin/scripts/reindexdb.c)
Previous Message Peter Geoghegan 2025-03-18 19:31:41 Re: Adding skip scan (including MDAM style range skip scan) to nbtree