Greetings, * Daniel Carter (danielchriscarter+postg...@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"... Thanks, Stephen
signature.asc
Description: PGP signature