On Mon, Feb 20, 2023 at 2:35 PM Stephen Frost <sfr...@snowman.net> wrote: > Having skimmed back through this thread again, I still feel that the > direction that was originally being taken (actually support something in > libpq and the backend, be it with libiddawc or something else or even > our own code, and not just throw hooks in various places) makes a lot > more sense and is a lot closer to how Kerberos and client-side certs and > even LDAP auth work today.
Cool, that helps focus the effort. Thanks! > That also seems like a much better answer > for our users when it comes to new authentication methods than having > extensions and making libpq developers have to write their own custom > code, not to mention that we'd still need to implement something in psql > to provide such a hook if we are to have psql actually usefully exercise > this, no? I don't mind letting clients implement their own flows... as long as it's optional. So even if we did use a hook in the end, I agree that we've got to exercise it ourselves. > In the Kerberos test suite we have today, we actually bring up a proper > Kerberos server, set things up, and then test end-to-end installing a > keytab for the server, getting a TGT, getting a service ticket, testing > authentication and encryption, etc. Looking around, it seems like the > equivilant would perhaps be to use Glewlwyd and libiddawc or libcurl and > our own code to really be able to test this and show that it works and > that we're doing it correctly, and to let us know if we break something. The original patchset includes a test server in Python -- a major advantage being that you can test the client and server independently of each other, since the implementation is so asymmetric. Additionally testing against something like Glewlwyd would be a great way to stack coverage. (If we *only* test against a packaged server, though, it'll be harder to test our stuff in the presence of malfunctions and other corner cases.) Thanks, --Jacob