Re: PATCH: Add GSSAPI ccache_name option to libpq

On Thu, Apr 22, 2021 at 1:55 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> Greetings,
>
> * Daniel Carter (danielchriscarter+postgres(at)gmail(dot)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"...
>

I thought I gave that precise use case upthread. As you know, we've been
adding Kerberos support to pgAdmin. When running in server mode, we have
multiple users logging into a single instance of the application, and we
need to cache credentials for them to be used to login to the PostgreSQL
servers, using libpq that is on the pgAdmin server. For obvious reasons, we
want to use separate credential caches for each pgAdmin user, and currently
that means having a mutex around every use of the caches, so we can be sure
we're safely manipulating the environment, using the correct cache, and
then continuing as normal once we're done.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com