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.)
Firstly, thanks for doing this. It helps to have another data point and the feedback you provided is very valuable. I've looked to address it with the patchset attached to this email.
This patch-set adds the following:
* Allow multiple custom auth providers to be registered (Addressing feedback from Aleksander and Andrew)
* Modify the test extension to use SCRAM to exchange secrets (Based on Andres's suggestion)
* Add support for custom auth options to configure provider's behavior (by exposing a new hook) (Required by OAUTHBEARER)
* Allow custom auth methods to use usermaps. (Required by OAUTHBEARER)
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.
Could you try to rebase your patch to use the options hook and let me know if it satisfies your requirements?
Please let me know if there's any other feedback.
Regards,
Samay
- 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.
