Hi Stephen,

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!

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

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?

Many thanks,
Daniel


Reply via email to