Re: [HACKERS] SCRAM auth and Pgpool-II

Greetings,

* Vladimir Borodin (root@simply.name) wrote:
> > 14 июля 2017 г., в 1:33, Stephen Frost <sfrost@snowman.net> написал(а):
> > What would be really nice for such cases is support for Kerberos and
> > delegated Kerberos credentials.  Having pgpool support that would remove
> > the need to deal with passwords at all.
>
> Since nearly all systems with some kind of load nowadays use connection poolers (pgpool-II or pgbouncer) between
applicationsand postgres, it is a pretty big pain to re-implement all authentication methods supported by postgres in
suchpoolers. Kerberos is cool but not the only thing that should be supported by FDWs or connection poolers. I.e. many
userswould want to have support for LDAP and SCRAM. And every time when there would be some changes in postgres auth
methods,exactly the same work (or even worse) should be done in many (at least two) other products widely used by
people.

Honestly, I disagree about the notion that LDAP support should be added
to anything or encouraged.  There's a reason that AD uses Kerberos and
not LDAP and Microsoft continues to (quite reasonably) make it more
difficult for individuals to perform LDAP auth in AD.

The auth methods in PG do not see a huge amount of churn over the years
and so I don't agree with the argument that it would be a problem for
other systems to support Kerberos or similar strong auth methods.

> It seems that postgres either should provide connection pooling feature in core or give external poolers a kind of
genericmechanism to transparently proxy auth requests/responses, so that authentication would be fully managed by
postgresand that would be the only place where changes in auth methods should be done. Yes, in this case connection
pooleractually behaves like man in the middle so it should be done very carefully but it seems that there is no other
way.

While this might be possible by having some kind of special trusted
connection between the pooler and PG, I actually don't particularly like
the notion of inventing a bunch of complicated logic and pain so that a
connection pooler can avoid implementing a proper authentication system.

Having PG support connection pooling itself, of course, would be nice
but I'm not aware of anyone currently working on it.

Thanks!

Stephen