Re: PATCH: Add GSSAPI ccache_name option to libpq

Greetings,

* Daniel Carter (danielchriscarter+postgres@gmail.com) wrote:
> On 21/04/2021 18:40, Stephen Frost wrote:
> >I surely hope that the intent here is to use Negotiate / SPNEGO to
> >authenticate the user who is connecting to the webserver and then have
> >credentials delegated (ideally through constrained credential
> >delegation..) to the web server by the user for the web application to
> >use to connect to the PG server.
> >
> >I certainly don't think we should be targetting a solution where the
> >application is acquiring credentials from the KDC directly using a
> >user's username/password, that's very strongly discouraged for the very
> >good reason that it means the user's password is being passed around.
>
> Indeed -- that's certainly not the intended aim of this patch!

Glad to hear that. :)

> >>There may well be a better way of going about this -- it's just that I can't
> >>currently see an obvious way to get this kind of setup working using only
> >>the environment variable.
> >
> >Perhaps you could provide a bit more information about what you're
> >specifically doing here?  Again, with something like apache's
> >mod_auth_gssapi, it's a matter of just installing that module and then
> >the user will be authenticated by the web server itself, including
> >managing of delegated credentials, setting of the environment variables,
> >and the web application shouldn't have to do anything but use libpq to
> >request a connection and if PG's configured with gssapi auth, it'll all
> >'just work'.  Only thing I can think of offhand is that you might have
> >to take AUTH_USER and pass that to libpq as the user's username to
> >connect with and maybe get from the user what database to request the
> >connection to..
>
> Hmm, yes -- something like that is definitely a neater way of doing things
> in the web app scenario (I'd been working on the principle that the username
> and credential cache were "provided" from the same place, i.e. the web app,
> but as you point out that's not actually necessary).

Yeah, that's really how web apps should be doing this.

> However, it seems like there might be some interest in this for other
> scenarios (e.g. with relation to multi-threaded applications where more
> precise control of which thread uses which credential cache is useful), so
> possibly this may still be worth continuing with even if it has a slightly
> different intended purpose to what was originally planned?

I'd want to hear the actual use-case rather than just hand-waving that
"oh, this might be useful for this threaded app that might exist some
day"...