On Mon, Feb 27, 2023 at 12:43 PM Stephen Frost <sfr...@snowman.net> wrote: > * Jacob Champion (jchamp...@timescale.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. > > 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. 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. 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. --Jacob [1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e7d814a5-4cb5-4b0d-b408-09d79988b550
