Hi Jacob,
Wanted to follow up on one of the topics discussed here in the past:
Do you plan to support adding an extension hook to validate the token?
It would allow a more efficient integration, then spinning a separate
process.
Thanks!
Andrey.
On Wed, Nov 8, 2023 at 11:00 AM Jacob Champion wr
> > - Parameters are strings, so callback is not provided yet.
> > 2. Client gets PgConn from PQconnectStart return value and updates
> > conn->async_auth to its own callback.
>
> This is where some sort of official authn callback registration (see
> above reply to Daniele) would probably come in
Thanks Jacob for making progress on this.
> 3) Is the current conn->async_auth() entry point sufficient for an
> application to implement the Microsoft flows discussed upthread?
Please confirm my understanding of the flow is correct:
1. Client calls PQconnectStart.
- The client doesn't know yet
> This really doesn't feel like a great area to try and do hooks or
> similar in, not the least because that approach has been tried and tried
> again (PAM, GSSAPI, SASL would all be examples..) and frankly none of
> them has turned out great (which is why we can't just tell people "well,
> install
Thanks for the feedback,
> 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 pla
Greetings,
Want to resurface the OAUTH support topic in the context of the
concerns raised here.
> How about- if we just added OAUTH support directly into libpq and the
> backend, would that work with Azure's OIDC provider? If not, why not?
> If it does, then what's the justification for trying t
e had this discussion as well, and
added that as a convenience for the client to identify the provider.
I don't see a reason why an issuer would be absolutely necessary, so
we will get your point that sticking to RFCs is a safer choice.
> The patches seem to be out of order now (and the doc
h
> provider=oauth_provider issuer="https://example.com"; scope="openid email"
>
> We also added hook to libpq to pass on the metadata about the issuer.
>
> Thanks,
> Mahendrakar.
>
>
> On Sat, 17 Dec 2022 at 04:48, Jacob Champion wrote:
> >
> &
On Thu, Dec 8, 2022 at 4:41 PM Jacob Champion wrote:
>
> On Wed, Dec 7, 2022 at 3:22 PM Andrey Chudnovsky
> wrote:
> >
> >> I think it's okay to have the extension and HBA collaborate to
> >> provide discovery information. Your proposal goes further than
> >&
t least that flow in PG16 it will be a strong
foundation to provide more support for specific grants in libpq going
forward.
Does the diagram above look good to you? We can then start cleaning up
the patch to get that in first.
Thanks!
Andrey.
On Wed, Dec 7, 2022 at 3:22 PM Andrey Chudnovsky
takes care of privileges.
This is the same for both User- and System-to-system authorization.
Though I assume different providers may treat user- and system-
identities differently. So their extension would handle that.
Thanks!
Andrey.
On Wed, Dec 7, 2022 at 11:06 AM Jacob Champion wrote:
>
Jacob,
Thanks for your feedback.
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 o
> How does this differ from the previous proposal? The OAUTHBEARER SASL
> mechanism already relies on OIDC for discovery. (I think that decision
> is confusing from an architectural and naming standpoint, but I don't
> think they really had an alternative...)
Mostly terminology questions here. OAUT
> On Fri, Sep 30, 2022 at 7:47 AM Andrey Chudnovsky
> wrote:
> > > How should we communicate those pieces to a custom client when it's
> > > passing a token directly? The easiest way I can see is for the custom
> > > client to speak the OAUTHBEARER protocol d
> The most concrete example I can see is with the OAUTHBEARER error
> response. If you want to eventually handle differing scopes per role,
> or different error statuses (which the proof-of-concept currently
> hardcodes as `invalid_token`), then the client can't assume it knows
> what the server is
>>> Libpq passing toked directly from an upstream client is useful in other
>>> scenarios:
>>> 1. Enterprise clients, built with .Net / Java and using provider-specific
>>> authentication libraries, like MSAL for AAD. Those can also support more
>>> advanced provider-specific token acquisition f
First, My message from corp email wasn't displayed in the thread,
That is what Jacob replied to, let me post it here for context:
> We can support both passing the token from an upstream client and libpq
> implementing OAUTH2 protocol to obtain one.
>
> Libpq implementing OAUTHBEARER is needed fo
17 matches
Mail list logo
