On Thu, 2022-03-03 at 11:12 +0100, Peter Eisentraut wrote: > At the moment, it is not possible to judge whether the hook interface > you have chosen is appropriate. > > I suggest you actually implement the Azure provider, then make the hook > interface, and then show us both and we can see what to do with it.
To add a data point here, I've rebased my OAUTHBEARER experiment [1] on top of this patchset. (That should work with Azure's OIDC provider, and if it doesn't, I'd like to know why.) After the port, here are the changes I still needed to carry in the backend to get the tests passing: - I needed to add custom HBA options to configure the provider. - I needed to declare usermap support so that my provider could actually use check_usermap(). - I had to modify the SASL mechanism registration to allow a custom maximum message length, but I think that's not the job of Samay's proposal to fix; it's just a needed improvement to CheckSASLAuth(). Obviously, the libpq frontend still needs to understand how to speak the new SASL mechanism. There are third-party SASL implementations that are plugin-based, which could potentially ease the pain here, at the expense of a major dependency and a very new distribution model. --Jacob [1] https://www.postgresql.org/message-id/flat/d1b467a78e0e36ed85a09adf979d04cf124a9d4b.camel%40vmware.com
