public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jacob Champion <[email protected]>
To: Stephen Frost <[email protected]>
Cc: mahendrakar s <[email protected]>
Cc: Andrey Chudnovsky <[email protected]>
Cc: [email protected]
Cc: Michael Paquier <[email protected]>
Cc: Pg Hackers <[email protected]>
Cc: [email protected]
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Date: Tue, 21 Feb 2023 14:24:12 -0800
Message-ID: <CAAWbhmh+6q4t3P+wDmS=JuHBpcgF-VM2cXNft8XV02yk-cHCpQ@mail.gmail.com> (raw)
In-Reply-To: <Y/[email protected]>
References: <CACrwV57+4MT7Fru-YbqEOYWp9EiLgfasUtPhntPmsNd0uNS6oA@mail.gmail.com>
<CACrwV57DcigMiEvuy=RJu2HH+euhyzgpeUuVAMu_rigY6R1P4w@mail.gmail.com>
<[email protected]>
<CACrwV55OMyHw7wu_-NyyHe1ysMK5_b7kYKBfkwxXhk0YB8-VPQ@mail.gmail.com>
<CAAWbhmiPjeVmZuB47BDZEgJD5kNXkxibtzxDtX9wysJKxLNnOw@mail.gmail.com>
<CABkiuWrzxZLAcHexs9TS2rJ6A_snC4vnxyhY0BTr-ymD8gJDmw@mail.gmail.com>
<CACrwV56UZQv4Mtm7=DTvvKP74UMMZgattBNQz6R6szm_v6xcag@mail.gmail.com>
<[email protected]>
<CACrwV55-j43wfub9Qwau02kZ4rksZw0gqNdPasj1rTNr8UC8Dg@mail.gmail.com>
<CABkiuWo4fJQ7dhqgYLtJh41kpCkT6iXOO8Eym3Rdh5tx2RJCJw@mail.gmail.com>
<Y/[email protected]>
On Mon, Feb 20, 2023 at 2:35 PM Stephen Frost <[email protected]> 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
view thread (8+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
In-Reply-To: <CAAWbhmh+6q4t3P+wDmS=JuHBpcgF-VM2cXNft8XV02yk-cHCpQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox