Greetings, * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: > On 11/1/19 12:58 PM, Robert Haas wrote: > > On Thu, Oct 31, 2019 at 4:58 PM Andrew Dunstan > > <andrew.duns...@2ndquadrant.com> wrote: > >> This patch allows the superuser to grant passwordless connection rights > >> in postgres_fdw user mappings. > > This is clearly something that we need, as the current code seems > > woefully ignorant of the fact that passwords are not the only > > authentication method supported by PostgreSQL, nor even the most > > secure. > > > > But, I do wonder a bit if we ought to think harder about the overall > > authentication model for FDW. Like, maybe we'd take a different view > > of how to solve this particular piece of the problem if we were > > thinking about how FDWs could do LDAP authentication, SSL > > authentication, credentials forwarding... > > I'm certainly open to alternatives.
I've long felt that the way to handle this kind of requirement is to have a "trusted remote server" kind of option- where the local server authenticates to the remote server as a *server* and then says "this is the user on this server, and this is the user that this user wishes to be" and the remote server is then able to decide if they accept that, or not. To be specific, there would be some kind of 'trust' established between the servers and only if there is some kind of server-level authentication, eg: dual TLS auth, or dual GSSAPI auth; and then, a mapping is defined for that server, which specifies what remote user is allowed to log in as what local user. This would be a server-to-server auth arrangement, and is quite different from credential forwarding, or similar. I am certainly also a huge fan of the idea that we support Kerberos/GSSAPI credential forwarding / delegation, where a client willingly forwards to the PG server a set of credentials which then allow the PG server to authenticate as that user to another system (eg: through an FDW to another PG server). Of course, as long as we're talking pie-in-the-sky ideas, I would certainly be entirely for supporting both. ;) Thanks, Stephen
signature.asc
Description: PGP signature
