Re: dblink: Add SCRAM pass-through authentication

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: dblink: Add SCRAM pass-through authentication
Дата
Msg-id f8398bb5-0c7a-4c25-ab1a-1a1e3539f84a@eisentraut.org
обсуждение исходный текст
Ответ на Re: dblink: Add SCRAM pass-through authentication  (Jacob Champion <jacob.champion@enterprisedb.com>)
Ответы Re: dblink: Add SCRAM pass-through authentication
Список pgsql-hackers
On 17.03.25 17:49, Jacob Champion wrote:
>>> If we implement this, it needs to check that the keys were actually
>>> sent during scram_exchange(). Having them set on the PGconn doesn't
>>> mean that we used them for authentication.
>>>
>> We use the client key and server key on calculate_client_proof and
>> verify_server_signature respective during memcpy, it would be too hack
>> to add new fields on pg_conn like scram_client_key_in_use and
>> scram_server_key_in_use, set them to true on these functions and then
>> validate that both are true on PQconnectionUsedScramKeys?
> I think that's probably a question for Peter: whether or not that
> additional API is something we want to support.

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.  But it would preempt certain setups that might 
otherwise work.  (Which ones?  Are they important?)

Why can't we use PQconnectionUsedPassword()?  What problems would that 
leave?  The example test case that Jacob showed earlier involved the 
remote server using "trust".  We don't want that, of course.  But what 
we want to make sure is that some kind of authentication happened 
between postgres_fdw and the remote server.  PQconnectionUsedPassword() 
does indicate that.

(Or could we just stick in require_auth=!none to solve this problem once 
and for all?)




В списке pgsql-hackers по дате отправления: