Date: Mon, 20 Feb 2023 17:35:36 -0500
From: Stephen Frost <sfrost@snowman.net>
To: mahendrakar s <mahendrakarforpg@gmail.com>
Cc: Andrey Chudnovsky <achudnovskij@gmail.com>,
	Jacob Champion <jchampion@timescale.com>, hlinnaka@iki.fi,
	Michael Paquier <michael@paquier.xyz>,
	Pg Hackers <pgsql-hackers@postgresql.org>, smilingsamay@gmail.com
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Message-ID: <Y/P1uITaEcLGGB0Z@tamriel.snowman.net>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="Dtj8Nh7Rq4w1QyVd"
Content-Disposition: inline
In-Reply-To: <CABkiuWo4fJQ7dhqgYLtJh41kpCkT6iXOO8Eym3Rdh5tx2RJCJw@mail.gmail.com>
User-Agent: Mutt/2.1.4 (2021-12-11)
Archived-At: <https://www.postgresql.org/message-id/Y/P1uITaEcLGGB0Z%40tamriel.snowman.net>
Precedence: bulk


--Dtj8Nh7Rq4w1QyVd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


Greetings,

* mahendrakar s (mahendrakarforpg@gmail.com) wrote:
> The "issuer" field has been removed to align  with the RFC
> implementation - https://www.rfc-editor.org/rfc/rfc7628.
> This patch "v6" is a single patch to support the OAUTH BEARER token
> through psql connection string.
> Below flow is supported. Added the documentation in the commit messages.
>=20
>  +----------------------+                                 +----------+
>   |             +-------+                                  | Postgres |
>   | PQconnect ->|       |                                  |          |
>   |             |       |                                  |   +---------=
--+
>   |             |       | ---------- Empty Token---------> | > |         =
  |
>   |             | libpq | <-- Error(Discovery + Scope ) -- | < | Pre-Auth=
  |
>   |          +------+   |                                  |   |  Hook   =
  |
>   |     +- < | Hook |   |                                  |   +---------=
--+
>   |     |    +------+   |                                  |          |
>   |     v       |       |                                  |          |
>   |  [get token]|       |                                  |          |
>   |     |       |       |                                  |          |
>   |     +       |       |                                  |   +---------=
--+
>   | PQconnect > |       | --------- Access Token --------> | > | Validato=
r |
>   |             |       | <---------- Auth Result -------- | < |   Hook  =
  |
>   |             |       |                                  |   +---------=
--+
>   |             +-------+                                  |          |
>   +----------------------+                                 +----------+
>=20
> Please note that we are working on modifying/adding new tests (from
> Jacob's Patch) with the latest changes. Will add a patch with tests
> soon.

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.  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?

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.

Thanks,

Stephen

--Dtj8Nh7Rq4w1QyVd
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEwf6gbxKhD863zrx/7WyKOINHZFUFAmPz9bQACgkQ7WyKOINH
ZFXYtBAAvEGkv/kNFq7GlUhOZx4HrL6TnqWTbMOeIUuumskQ7TbdqUWhjd03b+EM
NTCLJhJJH5xbo3NObQcTajc+jRgqzimk7V5kRQ51tJhWHw3AfJalwk0Qc+vEzSjK
R5kv+7a6bYebcRjmVl84OTD9VYEkKlPObmeYzfiqyiMG7ZtqdXbjqJMrqjK7c7M5
z/8hNv9ha1JPf48xtyCwkre1d3j6r6qIl3/CFqU6plmUhbpUNevSO1iXg6CyL5jz
y1j/oVWM8hv4TAY6XykSPi4ucyeL2dXpfjpQyOWgC9aiJ7tiUrL56IBL3hGo0lhd
BKbPY5sYXa7zQTZaqe+JymrJZhlNvZoNwzWw/xyHD4UsSloA1kxziFPf7ty7CPvw
GnduyhPL1m5KnC6VcMRPyKEFjfLF/JJHn+Z6cBQO19jjEhDvglkvT4FkEB7ED+6c
CEsl7N2mVSkvXSTSXGZ3ajGGK2dgIj7VWwWzXUWRWnKaXkJ9FTETkKJz77ZVLn/u
O87r8Rp3TAeccOG6J40npvqSkoamKx9T54RozHaGrnfw7rU/nhTlQIOCCtJGfGeI
Kv6IgCy59t5Ou/UzkkTCfTnf8GOKqZvc99pk6FIXTgyBezQ6awEk0mlH6dpkaPO5
7yvwzDttgyZvVdm1C0H9mMRAuvhNL7bUH0XmuoLU3UWxT8ugwc8=
=Koyn
-----END PGP SIGNATURE-----

--Dtj8Nh7Rq4w1QyVd--