Hi Samay,
> I wanted to submit a patch to expose 2 new hooks (one for the authentication check and another one for error reporting) in auth.c. These will allow users to implement their own authentication methods for Postgres or add custom logic around authentication.
I like the idea - PostgreSQL is all about extendability. Also, well
done with TAP tests and an example extension. This being said, I
didn't look at the code yet, but cfbot seems to be happy with it:
http://cfbot.cputube.org/
Thank you!
> One constraint in the current implementation is that we allow only one authentication provider to be loaded at a time. In the future, we can add more functionality to maintain an array of hooks and call the appropriate one based on the provider name in the pg_hba line.
This sounds like a pretty severe and unnecessary limitation to me. Do
you think it would be difficult to bypass it in the first
implementation?
Just to clarify, the limitation is around usage of multiple custom providers but does allow users to use the existing methods with one custom authentication method. The reasons I thought this is ok to start with are:
* It allows users to plugin a custom authentication method which they can't do today.
* Users generally have an authentication method for their database (eg. we use ldap for authentication, or we use md5 passwords for authentication). While it is possible, I'm not sure how many users use completely different authentication methods (other than standard ones like password and trust) for different IPs/databases for their same instance.
So, I thought this should be good enough for a number of use cases.
I thought about adding support for multiple custom providers and the approach I came up with is: Maintaining a list of all providers (their names, check functions and error functions), making sure they are all valid while parsing pg_hba.conf and calling the right one when we see the custom keyword in pg_hba.conf based on name. I'm not sure (I haven't yet checked) if we have other such hooks in Postgres where multiple extensions use them and Postgres calls the right hook based on input (instead of just calling whoever has the hook).
Therefore, I wanted to start with something simple so users can begin using auth methods of their choice, and add multiple providers as an enhancement after doing more research and coming up with the right way to implement it.
That being said, any thoughts on the approach I mentioned above? I'll look into it and see if it's not too difficult to implement this.
Regards,
Samay
--
Best regards,
Aleksander Alekseev
