MIME-Version: 1.0
References: <CACrwV57+4MT7Fru-YbqEOYWp9EiLgfasUtPhntPmsNd0uNS6oA@mail.gmail.com>
 <CACrwV57DcigMiEvuy=RJu2HH+euhyzgpeUuVAMu_rigY6R1P4w@mail.gmail.com>
 <705e7eb8-29ee-a707-5a67-d2acfb2f3fad@timescale.com> <CACrwV55OMyHw7wu_-NyyHe1ysMK5_b7kYKBfkwxXhk0YB8-VPQ@mail.gmail.com>
 <CAAWbhmiPjeVmZuB47BDZEgJD5kNXkxibtzxDtX9wysJKxLNnOw@mail.gmail.com>
 <CABkiuWrzxZLAcHexs9TS2rJ6A_snC4vnxyhY0BTr-ymD8gJDmw@mail.gmail.com>
 <CACrwV56UZQv4Mtm7=DTvvKP74UMMZgattBNQz6R6szm_v6xcag@mail.gmail.com>
 <a798eaae-4687-3687-d464-6d482816328e@timescale.com> <CACrwV55-j43wfub9Qwau02kZ4rksZw0gqNdPasj1rTNr8UC8Dg@mail.gmail.com>
 <CABkiuWo4fJQ7dhqgYLtJh41kpCkT6iXOO8Eym3Rdh5tx2RJCJw@mail.gmail.com> <Y/P1uITaEcLGGB0Z@tamriel.snowman.net>
In-Reply-To: <Y/P1uITaEcLGGB0Z@tamriel.snowman.net>
From: Jacob Champion <jchampion@timescale.com>
Date: Tue, 21 Feb 2023 14:24:12 -0800
Message-ID: <CAAWbhmh+6q4t3P+wDmS=JuHBpcgF-VM2cXNft8XV02yk-cHCpQ@mail.gmail.com>
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
To: Stephen Frost <sfrost@snowman.net>
Cc: mahendrakar s <mahendrakarforpg@gmail.com>, Andrey Chudnovsky <achudnovskij@gmail.com>, hlinnaka@iki.fi, 
	Michael Paquier <michael@paquier.xyz>, Pg Hackers <pgsql-hackers@postgresql.org>, 
	smilingsamay@gmail.com
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAAWbhmh%2B6q4t3P%2BwDmS%3DJuHBpcgF-VM2cXNft8XV02yk-cHCpQ%40mail.gmail.com>
Precedence: bulk

On Mon, Feb 20, 2023 at 2:35 PM Stephen Frost <sfrost@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