MIME-Version: 1.0
References: <d1b467a78e0e36ed85a09adf979d04cf124a9d4b.camel@vmware.com>
 <2f06a4aef1d5defe4b7aaec01478572e5557d32a.camel@vmware.com>
 <8a5a35b31c3f25f6b047e77def0445a60399981d.camel@vmware.com>
 <0e86fe7e3534fb05db02379fed404a2010eb1d62.camel@vmware.com>
 <4db7d3ea061f47a15fc6d865f53dd327ea2975fb.camel@vmware.com>
 <CAAWbhmiWudPQk2euOQQPPa=o14zCN9U_qLwU1pShKO4A-F9yeA@mail.gmail.com>
 <CACrwV540h9+qgz85aND7jpCcuxD_TOo+fJEg7xs1JKGLMf1N+A@mail.gmail.com>
 <CAAWbhmjiQ-X9w5CqLv__Wcfvg3oJ+hXd9807Lzi=zN9DMTpfFg@mail.gmail.com>
 <CACrwV54_euYe+v7bcLrxnje-JuM=KRX5azOcmmrXJ5qrffVZfg@mail.gmail.com>
 <CAAWbhmiR9D=OG=r9-bkiNw_Sp84qc7ti0PaWA_GWUM_t1PeS=g@mail.gmail.com>
 <CACrwV56g7ZZ9wfbQxcoX5YRdx6kx_HgJjxAM5PQoBV41jpCERw@mail.gmail.com>
 <CABkiuWqp1mog7GiUq+thfn0bqKye=QShe5aVBEVSUDPYyBWKvw@mail.gmail.com>
 <f40261a5-2efb-7851-fc63-7a5b6e00c146@timescale.com>
 <CACrwV54pf-VcL_XmDSWOHtLhiprm9nxORW5LJXocD=yCVq=knQ@mail.gmail.com>
 <CABkiuWo-7KPMZ92Jii0FLz=VmQ=2UbnsgWUCqtfuLXGzubB=tg@mail.gmail.com>
 <a19dc65a-ccea-fd1b-5e0c-71b7aa8502f1@timescale.com>
 <CACrwV56MTdboeBKVU-b-M2oHLttRxoVm4tJmwVOK2cydL+Spdg@mail.gmail.com>
In-Reply-To: 
 <CACrwV56MTdboeBKVU-b-M2oHLttRxoVm4tJmwVOK2cydL+Spdg@mail.gmail.com>
From: Jacob Champion <jchampion@timescale.com>
Date: Wed, 7 Dec 2022 11:06:07 -0800
Message-ID: 
 <CAAWbhmgsFanAWst7xMW7hgzAcGEqsSjgP0vcFt=cUYGxJBWndQ@mail.gmail.com>
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
To: Andrey Chudnovsky <achudnovskij@gmail.com>
Cc: mahendrakar s <mahendrakarforpg@gmail.com>,
 "hlinnaka@iki.fi" <hlinnaka@iki.fi>,
	"michael@paquier.xyz" <michael@paquier.xyz>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
	"smilingsamay@gmail.com" <smilingsamay@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAAWbhmgsFanAWst7xMW7hgzAcGEqsSjgP0vcFt%3DcUYGxJBWndQ%40mail.gmail.com>
Precedence: bulk

On Mon, Dec 5, 2022 at 4:15 PM Andrey Chudnovsky <achudnovskij@gmail.com> wrote:
> I think we can focus on the roles and responsibilities of the components first.
> Details of the patch can be elaborated. Like "flow type code" is a
> mistake on our side, and we will use the term "grant_type" which is
> defined by OIDC spec. As well as details of usage of refresh_token.

(For the record, whether we call it "flow type" or "grant type"
doesn't address my concern.)

> Basically Yes. We propose an increase of the server side hook responsibility.
> From just validating the token, to also return the provider root URL
> and required audience. And possibly provide more metadata in the
> future.

I think it's okay to have the extension and HBA collaborate to provide
discovery information. Your proposal goes further than that, though,
and makes the server aware of the chosen client flow. That appears to
be an architectural violation: why does an OAuth resource server need
to know the client flow at all?

> Which is in our opinion aligned with SASL protocol, where the server
> side is responsible for telling the client auth requirements based on
> the requested role in the startup packet.

You've proposed an alternative SASL mechanism. There's nothing wrong
with that, per se, but I think it should be clear why we've chosen
something nonstandard.

> Our understanding is that in the original patch that information came
> purely from hba, and we propose extension being able to control that
> metadata.
> As we see extension as being owned by the identity provider, compared
> to HBA which is owned by the server administrator or cloud provider.

That seems reasonable, considering how tightly coupled the Issuer and
the token validation process are.

> 2. Server Owners / PAAS providers (On premise admins, Cloud providers,
> multi-cloud PAAS providers).
>    - Install extensions and configure HBA to allow clients to
> authenticate with the identity providers of their choice.

(For a future conversation: they need to set up authorization, too,
with custom scopes or some other magic. It's not enough to check who
the token belongs to; even if Postgres is just using the verified
email from OpenID as an authenticator, you have to also know that the
user authorized the token -- and therefore the client -- to access
Postgres on their behalf.)

> 3. Client Application Developers (Data Wis, integration tools,
> PgAdmin, monitoring tools, e.t.c.)
>    - Independent from specific Identity providers or server providers.
> Write one code for all identity providers.

Ideally, yes, but that only works if all identity providers implement
the same flows in compatible ways. We're already seeing instances
where that's not the case and we'll necessarily have to deal with that
up front.

>    - Rely on application deployment owners to configure which OIDC
> provider to use across client and server setups.
> 4. Application Deployment Owners (End customers setting up applications)
>    - The only actor actually aware of which identity provider to use.
> Configures the stack based on the Identity and PostgreSQL deployments
> they have.

(I have doubts that the roles will be as decoupled in practice as you
have described them, but I'd rather defer that for now.)

> The critical piece of the vision is (3.) above is applications
> agnostic of the identity providers. Those applications rely on
> properly configured servers and rich driver logic (libpq,
> com.postgresql, npgsql) to allow their application to popup auth
> windows or do service-to-service authentication with any provider. In
> our view that would significantly democratize the deployment of OAUTH
> authentication in the community.

That seems to be restating the goal of OAuth and OIDC. Can you explain
how the incompatible change allows you to accomplish this better than
standard implementations?

> In order to allow this separation, we propose:
> 1. HBA + Extension is the single source of truth of Provider root URL
> + Required Audience for each role. If some backfill for missing OIDC
> discovery is needed, the provider-specific extension would be
> providing it.
> 2. Client Application knows which grant_type to use in which scenario.
> But can be coded without knowledge of a specific provider. So can't
> provide discovery details.
> 3. Driver (libpq, others) - coordinate the authentication flow based
> on client grant_type and identity provider metadata to allow client
> applications to use any flow with any provider in a unified way.
>
> Yes, this would require a little more complicated flow between
> components than in your original patch.

Why? I claim that standard OAUTHBEARER can handle all of that. What
does your proposed architecture (the third diagram) enable that my
proposed hook (the second diagram) doesn't?

> And yes, more complexity comes
> with more opportunity to make bugs.
> However, I see PG Server and Libpq as the places which can have more
> complexity. For the purpose of making work for the community
> participants easier and simplify adoption.
>
> Does this make sense to you?

Some of it, but it hasn't really addressed the questions from my last mail.

Thanks,
--Jacob