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 по дате отправления: