Re: Auth extensions, with an LDAP/SCRAM example [was: Proposal: Support custom authentication methods using hooks]

Greetings,

* Jacob Champion (jchampion(at)timescale(dot)com) wrote:
> On Mon, Feb 27, 2023 at 12:43 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > * Jacob Champion (jchampion(at)timescale(dot)com) wrote:
> > > This patchset should ideally have required zero client side changes, but
> > > because our SCRAM implementation is slightly nonstandard too -- it
> > > doesn't embed the username into the SCRAM data -- libpq can't talk to
> > > the OpenLDAP/Cyrus SASL implementation. I included a quick-and-bad patch
> > > to fix it in libpq; that needs its own conversation.
> >
> > Indeed it does... as there were specific reasons that what we
> > implemented for PG's SCRAM doesn't embed the username into the SCRAM
> > data and my recollection is that we don't because SCRAM (or maybe SASL?
> > either way though...) requires it to be utf-8 encoded and we support a
> > lot of other encoding that aren't that, so it wouldn't work for a lot
> > of our users.
>
> Yes. Interoperable authentication is going to have to solve those
> sorts of problems somehow, though. And there are a bunch of levers to
> pull: clients aren't required to run their sent usernames through
> SASLprep; our existing servers don't mind having it sent, so we could
> potentially backport a client change; and then after that it's a game
> of balancing compatibility and compliance. A deeper conversation for
> sure.

We did solve those problems with SCRAM, by not exactly following the
unfortunately short-sighted standard. What we have gets us the benefits
of SCRAM and generally follows the standard without giving up non-utf8
encodings of roles. If there's a compelling reason to support another
authentication method then I'd hope we would look for similar ways to
support it without giving up too much.

I certainly don't see it making sense to backport some change in this
area.

> > > I think this is exactly the sort of thing that's too niche to be in core
> > > but might be extremely useful for the few people it applies to, so I'm
> > > proposing it as an argument in favor of general authn/z extensibility.
> >
> > If it was able to actually work for our users (and maybe it is if we
> > make it optional somehow) and we have users who want it (which certainly
> > seems plausible) then I'd say that it's something we would benefit from
> > having in core. While it wouldn't solve all the issues with 'ldap'
> > auth, if it works with AD's LDAP servers and doesn't require the
> > password to be passed from the client to the server (in any of this, be
> > the client psql, pgadmin, or the PG server when it goes to talk to the
> > LDAP server..) then that would be a fantastic thing and we could
> > replace the existing 'ldap' auth with that and be *much* better off for
> > it, and so would our users.
>
> I think the argument you're making here boils down to "if it's not
> niche, it should be in core", and I agree with that general sentiment.

Good. That certainly seems like a start.

> But not all of the prerequisites you stated are met. I see no evidence
> that Active Directory supports SCRAM [1], for instance, unless the MS
> documentation is just omitting it.

That's certainly unfortunate if that's the case. The question then
becomes- are a lot of people using SCRAM to connect to OpenLDAP, to the
extent that it's a sensible thing for us to support and gives us a more
secure option for 'ldap' auth than what exists today where we're passing
around cleartext passwords? That seems like it's at least plausible.

> Even if it were applicable to every single LDAP deployment, I'd still
> like users to be able to choose the best authentication available in
> their setups without first having to convince the community. They can
> maintain the things that make sense for them, like they do with
> extensions. And the authors can iterate on better authentication out
> of cycle, like extension authors do.

Considering how few outside-of-core well maintained extensions for PG
exist, I have an extremely hard time buying off on the argument that the
authentication system is a smart area for us to encourage approach in.

Broadly speaking, I feel confident saying that authentication systems,
rather like encryption libraries, should be standardized, well
documented, heavily reviewed, and carefully maintained. If the argument
is that there are these teams out there who are itching to write amazing
new authentication methods for PG who are going to spend time
documenting them, reviewing them, and maintaining them, then we should
try to get those folks to work with the community to add support for
these new methods so that everyone can benefit from them- not
encouraging them to be independent projects which have to work through
hooks that limit how those authentication methods are able to be
integrated. Consider things like pg_stat_ssl and pg_stat_gssapi. What
about pg_ident maps? Will each of these end up with their own version
of that? And those are questions beyond just the issue around making
sure that these external extensions are well maintained and that we
don't end up breaking them through changes to core. I just don't see,
at least today, authentication methods in the same light as, say, data
types.

Thanks,

Stephen