Greetings,
* Andrew Dunstan (andrew.dunstan@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.dunstan@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