Greetings, * 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. Not really seeing that as being something we get to be picky about or decide to change our mind on. It's unfortunate that the standard seems to be short-sighted in this way but that's the reality of it. > 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. Thanks, Stephen
signature.asc
Description: PGP signature