Thread: pgAdmin 4 + python wheel + kerberos

Greetings,

* Khushboo Vashi (khushboo.vashi@enterprisedb.com) wrote:
> On Wed, Dec 13, 2017 at 3:05 AM, Duffey, Blake <Blake.Duffey@noblis.org>
> wrote:
>
> > Will pgAdmin 4 as a python wheel application support Kerberos
> > authentication?
> >
> > We are evaluating running pgAdmin 4 as a web service (vs a Windows
> > application) in a shared Citrix environment.   Kerberos auth would make
> > this use case viable.
>
> Ref #1952 <https://redmine.postgresql.org/issues/1952> :
> Kerberos authentication is supported by the underlying libpq, and pgAdmin 4
> exposes both the host and hostaddr connection options that are typically
> used in Kerberos environments.

This does not appear to contemplate Kerberos credential proxying, which
is what is really needed here when talking about running pgAdmin4 as a
web service.

Specifically, pgAdmin4 would need to be able to handline *incoming*
Kerberos authentication requests using SPNEGO and then be able to have
credentials delegated to it which would then allow it to authenticate to
PostgreSQL using Kerberos.

The fact that pgAdmin4 uses libpq to connect to PG does not make
pgAdmin4 support Kerberos as a web service, though it should work for
pgAdmin4 running as a Windows client (assuming it's being run in the
user's application space; if it's being run as a Windows service or
similar then it may not work).

I'd certainly love to see pgAdmin4 as a web service support Kerberos
authentication, with multi-user support and proper ticket delegation and
credential proxying to allow users a seamless experience hitting a
pgAdmin4 web server.

Thanks!

Stephen

Greetings,

* Stephen Frost (sfrost@snowman.net) wrote:
> * Khushboo Vashi (khushboo.vashi@enterprisedb.com) wrote:
> > On Wed, Dec 13, 2017 at 3:05 AM, Duffey, Blake <Blake.Duffey@noblis.org>
> > wrote:
> >
> > > Will pgAdmin 4 as a python wheel application support Kerberos
> > > authentication?
> > >
> > > We are evaluating running pgAdmin 4 as a web service (vs a Windows
> > > application) in a shared Citrix environment.   Kerberos auth would make
> > > this use case viable.
> >
> > Ref #1952 <https://redmine.postgresql.org/issues/1952> :
> > Kerberos authentication is supported by the underlying libpq, and pgAdmin 4
> > exposes both the host and hostaddr connection options that are typically
> > used in Kerberos environments.
>
> This does not appear to contemplate Kerberos credential proxying, which
> is what is really needed here when talking about running pgAdmin4 as a
> web service.

That said, reminding myself that pgAdmin4 can be run under Apache, it
should be possible to have an Apache system set up with mod_auth_kerb
(to handle the incoming Kerberos authentication and the credential
delegation) and have pgAdmin4 pick up on the user as having been
authenticated via Kerberos thanks to environment variables provided by
Apache and, further, be able to connect to a downstream PostgreSQL
database using the delegated credentials thanks to mod_auth_kerb setting
up the KRB5CCACHE environment variable.

I'm not completely sure about the mod_wsgi bit of things or if there's
anything further that would need to be done to make this all work, but
it might not require that much effort if Apache and libpq are able to
handle all of the complexity of Kerberos authentication.  The big
question when it comes to mod_wsgi and the way that works is if the
environment variables are passed through somehow because that's required
to make this work- and, more importantly, the environment variables need
to be per-connection.  It might require some kind of proxying from the
environment variables passed in by Apache to the various processes doing
the work in pgAdmin4 (this clearly must be done already to some extent-
each part of pgAdmin4 knows which *user* is logged in, after all).

In short, Blake, if it were me, I'd probably build out a system which
uses Apache, mod_auth_kerb, and mod_wsgi, and then make sure that
Kerberos is being used to authenticate to Apache, and then set up a
downstream PG server to use gssapi for the auth type from the pgAdmin4
server and see if things don't 'just work'.

I don't think pgAdmin4 currently is able to work with Apache's auth
system and, instead, has its own, so until that's fixed you'd have to
have user accounts for everyone in the pgAdmin4 user management system
that they'd have to use to 'log into' pgAdmin4 after the Kerberos
authentication has been done and they can hit the app itself.  The
question after that is if pgAdmin4 will pick up on the KRB5CCACHE
location for the current session and be able to use it to do GSSAPI
authentication via libpq to PG.

Thanks!

Stephen

Stephen Frost (sfrost@snowman.net) wrote:

! That said, reminding myself that pgAdmin4 can be run under Apache, it
! should be possible to have an Apache system set up with mod_auth_kerb
! (to handle the incoming Kerberos authentication and the credential
! delegation) and have pgAdmin4 pick up on the user as having been
! authenticated via Kerberos thanks to environment variables provided by
! Apache and, further, be able to connect to a downstream PostgreSQL
! database using the delegated credentials thanks to mod_auth_kerb setting
! up the KRB5CCACHE environment variable.

! I'm not completely sure about the mod_wsgi bit of things or if there's
! anything further that would need to be done to make this all work, but
! it might not require that much effort if Apache and libpq are able to
! handle all of the complexity of Kerberos authentication.  The big
! question when it comes to mod_wsgi and the way that works is if the
! environment variables are passed through somehow because that's required
! to make this work- and, more importantly, the environment variables need
! to be per-connection.  It might require some kind of proxying from the
! environment variables passed in by Apache to the various processes doing
! the work in pgAdmin4 (this clearly must be done already to some extent-
! each part of pgAdmin4 knows which *user* is logged in, after all).

! In short, Blake, if it were me, I'd probably build out a system which
! uses Apache, mod_auth_kerb, and mod_wsgi, and then make sure that
! Kerberos is being used to authenticate to Apache, and then set up a
! downstream PG server to use gssapi for the auth type from the pgAdmin4
! server and see if things don't 'just work'.

! I don't think pgAdmin4 currently is able to work with Apache's auth
! system and, instead, has its own, so until that's fixed you'd have to
! have user accounts for everyone in the pgAdmin4 user management system
! that they'd have to use to 'log into' pgAdmin4 after the Kerberos
! authentication has been done and they can hit the app itself.  The
! question after that is if pgAdmin4 will pick up on the KRB5CCACHE
! location for the current session and be able to use it to do GSSAPI
! authentication via libpq to PG.

Hello,

  being in the process of upgrading from pgadmin3 (and taking the
opportunity to move the new pgadmin4 onto a proper app-server), I
found this article, written some 2 years ago, being the only resource
I could find all over the Internet, which, in a sensible way,
describes the task of logging into the postgres server, in the case
when this happens to be purely Kerberos5-driven.

I couldn't find any mentioning of this task in the pgadmin4
documentation. :(

So, since this quoted article is from quite a time back, may I kindly
ask for an update on the status of this matter, how it may have
proceeded in the meantime and what is currently considered best
practices in such a case of pure Krb5 operations? 

thanks and best regards,
PMc

On Sun, Jan 12, 2020 at 05:58:56PM +0100, Peter wrote:
! Stephen Frost (sfrost@snowman.net) wrote:
! 
! ! That said, reminding myself that pgAdmin4 can be run under Apache, it
! ! should be possible to have an Apache system set up with mod_auth_kerb
! ! (to handle the incoming Kerberos authentication and the credential
! ! delegation) and have pgAdmin4 pick up on the user as having been
! ! authenticated via Kerberos thanks to environment variables provided by
! ! Apache and, further, be able to connect to a downstream PostgreSQL
! ! database using the delegated credentials thanks to mod_auth_kerb setting
! ! up the KRB5CCACHE environment variable.
! ! [...]

! So, since this quoted article is from quite a time back, may I kindly
! ask for an update on the status of this matter, how it may have
! proceeded in the meantime and what is currently considered best
! practices in such a case of pure Krb5 operations? 

No answer, well then, it seems nobody interested whatsoever in this
matter. :(

Anyway, I made it working, so it works now. Multiuser, multithreading,
freestanding process behind a rig.

Difficult part was to get it safe. As there can be many users using the
pgadmin4 simultaneously with different credentials and connecting as
different roles to different postgres servers at the same time, care
must be taken that they will only use their own creds for that.

rgds,
PMc

Greetings Peter,

* Peter (pmc@citylink.dinoex.sub.org) wrote:
> On Sun, Jan 12, 2020 at 05:58:56PM +0100, Peter wrote:
> ! Stephen Frost (sfrost@snowman.net) wrote:
> !
> ! ! That said, reminding myself that pgAdmin4 can be run under Apache, it
> ! ! should be possible to have an Apache system set up with mod_auth_kerb
> ! ! (to handle the incoming Kerberos authentication and the credential
> ! ! delegation) and have pgAdmin4 pick up on the user as having been
> ! ! authenticated via Kerberos thanks to environment variables provided by
> ! ! Apache and, further, be able to connect to a downstream PostgreSQL
> ! ! database using the delegated credentials thanks to mod_auth_kerb setting
> ! ! up the KRB5CCACHE environment variable.
> ! ! [...]
>
> ! So, since this quoted article is from quite a time back, may I kindly
> ! ask for an update on the status of this matter, how it may have
> ! proceeded in the meantime and what is currently considered best
> ! practices in such a case of pure Krb5 operations?
>
> No answer, well then, it seems nobody interested whatsoever in this
> matter. :(

Interested, sure, but..

> Anyway, I made it working, so it works now. Multiuser, multithreading,
> freestanding process behind a rig.

Following the hints above, sounds like you were able to sort it out.
Glad to hear it!  Would love to have the specific details of what you
did to make it work posted to this list or otherwise publicized, for
others who are interested.

> Difficult part was to get it safe. As there can be many users using the
> pgadmin4 simultaneously with different credentials and connecting as
> different roles to different postgres servers at the same time, care
> must be taken that they will only use their own creds for that.

So..  what did you do to ensure that?  Generally speaking, mod_auth_kerb
has the issue that it needs to make sure that credentials and http
connections are properly associated with each other, so I'm curious as
to what you had to do extra (if anything).

Thanks,

Stephen

Getting back to this one - sorry, took me a while...

On Wed, Jan 15, 2020 at 10:02:26AM -0500, Stephen Frost wrote:
! Greetings Peter,

Greetings back!

! 
! * Peter (pmc@citylink.dinoex.sub.org) wrote:
! > On Sun, Jan 12, 2020 at 05:58:56PM +0100, Peter wrote:
! > ! Stephen Frost (sfrost@snowman.net) wrote:
! > ! 
! > ! ! That said, reminding myself that pgAdmin4 can be run under Apache, it
! > ! ! should be possible to have an Apache system set up with mod_auth_kerb
! > ! ! (to handle the incoming Kerberos authentication and the credential
! > ! ! delegation) and have pgAdmin4 pick up on the user as having been
! > ! ! authenticated via Kerberos thanks to environment variables provided by
! > ! ! Apache and, further, be able to connect to a downstream PostgreSQL
! > ! ! database using the delegated credentials thanks to mod_auth_kerb setting
! > ! ! up the KRB5CCACHE environment variable.
! > ! ! [...]
! > 
! > ! So, since this quoted article is from quite a time back, may I kindly
! > ! ask for an update on the status of this matter, how it may have
! > ! proceeded in the meantime and what is currently considered best
! > ! practices in such a case of pure Krb5 operations? 
! > 
! > No answer, well then, it seems nobody interested whatsoever in this
! > matter. :(
! 
! Interested, sure, but..
! 
! > Anyway, I made it working, so it works now. Multiuser, multithreading,
! > freestanding process behind a rig.
! 
! Following the hints above, sounds like you were able to sort it out.

Yeah. While not being straightaway viable, your thoughts were the
necessary affirmation to push me forward to investigate deeper.

! Glad to hear it!  Would love to have the specific details of what you
! did to make it work posted to this list or otherwise publicized, for
! others who are interested.

Alright.

 1. The KRB5CCACHE variable.
 
    pgadmin doc says this: "Some components of pgAdmin require the
    ability to maintain affinity between client sessions and a
    specific database connection [...] it requires that only a single
    Python process is used [etc.etc.]"

    This translates to: you cannot run it in a multi-process worker
    configuration. To get any parallelization, one must use threads.

    But: KRB5CCACHE is in the system env, and the system env is shared
    among threads. So even if we get this variable from the webserver
    to the pgadmin (which is also delicate, and might work only with
    "embedded" mode, but that one is discouraged on unix for the
    same reasons: apache uses some mixture of threads and processes),
    it will not simply work to have threads for different users
    running in parallel and use the proper credentials.

 2. The kerberos module.

    For the apache I have two such modules: mod_auth_kerb2, which
    is said to be deprecated and replaced by mod_auth_gssapi.

    But, mod_auth_gssapi requires MIT kerberos, and my FreeBSD
    happens to have Heimdal integrated. Furthermore, the apache
    source/ABI/whatever is (imo) not a welcoming space for code
    modifications (had to do this once, don't want it again.)

    So, I had a look at the uwsgi rig, and there is something:
    https://uwsgi-docs.readthedocs.io/en/latest/SPNEGO.html
    https://uwsgi-docs.readthedocs.io/en/latest/Changelog-1.9.9.html#the-spnego-plugin

    As we can see, documentation is nonexistant, implementation
    is also somewhere between sparse and lacking - but that's good,
    because there is free space to do whatever we like - and I have
    an openssh that can do credential delegation, so I just took
    that code and pasted it in there (and made that working).

    So far is that part.

 Now back to the KRB5CCNAME problem:

    There seems to be no way to tell postgreSQL which credentials
    to use for connecting (when invoking the client - lib or
    executable), except this environment variable. (At least I found
    no other.)

    What can be done: let the web rig drop the creds into a
    file named by the principal that we got credentials for.(*)

    Then, within pgadmin4, we see the "REMOTE_USER" in the request
    variables set to the same name - so we know the filename.

    There seem to be only two places where pgadmin4 calls to
    postgres - one is for invocations of externals programs (i.e.
    forking), and that is simple because we can give a dedicated
    environment to these, and that should be safe.

    The other is a call to psycopg2.connect() - and I don't know
    what exactly that does. Anyway, I put the proper KRB5CCNAME
    into the environment before this call.

    Then I do a lock around that fork, and around that connect(),
    so that no two threads can run thru these regions at the same
    time.
    I assume this should be safe, and during invocations of postgres
    the KRB5CCNAME should always point to the credentials of the
    acting REMOTE_USER.

  Things I am not completely certain about:

  * I assume that the credentials are only used during the connect
    (as afterwards the connection is authenticated and they shouldn't
    have any use anymore for that connection).

  * There may be occasions when the database is connected independent
    of a user action from the web. I doubt that this is the case,
    because pgadmin would need to ask for the database password at
    that point, but I didn't analyze the code.
    In that case there would be no REMOTE_USER information (or a wrong
    one, which is worse).

  * There is a feature called "async", or PQconnectStart(). This seems
    to return *before* the connection is made, i.e. before the
    KRB5CCNAME from the environment is consumed. But at least for now
    it also seems that pgadmin does explicitely wait after this call
    until the connection is established, so that this wait can be
    included in the locked region.

  * There is a feature called pgAgent, which does some scheduled
    tasks, by whatever means. I didn't look into that, I have no idea
    how that would authenticate to the database, but it certainly does
    not work with my scheme.


  (*) I didn't like the idea of creating a file everytime; since this
    staye in the same process, it would be more appropriate to
    handover the cred in memory. But it would be difficult to pull
    them out of the kerberos library, and there seems no way to pass
    them on to postgres library.
    So I considered modifying this thing for the purpose:
    https://www.freebsd.org/cgi/man.cgi?query=kcm
    But I could not get that running even in its normal operation.
    So for now I do compare the received credential with the one in
    the file, and write only if they are different.
    
So far, thats the storyline. Enjoy.


cheerio,
PMc

Greetings Peter,

* Peter (pmc@citylink.dinoex.sub.org) wrote:
> Getting back to this one - sorry, took me a while...

Yeah, same. :)

> On Wed, Jan 15, 2020 at 10:02:26AM -0500, Stephen Frost wrote:
> ! Glad to hear it!  Would love to have the specific details of what you
> ! did to make it work posted to this list or otherwise publicized, for
> ! others who are interested.
>
> Alright.

Thanks for this!

>  Now back to the KRB5CCNAME problem:
>
>     There seems to be no way to tell postgreSQL which credentials
>     to use for connecting (when invoking the client - lib or
>     executable), except this environment variable. (At least I found
>     no other.)

So..  libpq is just calling into the Kerberos libraries and that's what
is actually reading KRB5CCNAME, and I think you're right, you can't pass
that info from libpq to the Kerb libraries today- but we could change
that in libpq, possibly.

For now tho...

>     What can be done: let the web rig drop the creds into a
>     file named by the principal that we got credentials for.(*)

Right.

>     Then, within pgadmin4, we see the "REMOTE_USER" in the request
>     variables set to the same name - so we know the filename.

Sure.

>     There seem to be only two places where pgadmin4 calls to
>     postgres - one is for invocations of externals programs (i.e.
>     forking), and that is simple because we can give a dedicated
>     environment to these, and that should be safe.
>
>     The other is a call to psycopg2.connect() - and I don't know
>     what exactly that does. Anyway, I put the proper KRB5CCNAME
>     into the environment before this call.

Makes sense to me.

>     Then I do a lock around that fork, and around that connect(),
>     so that no two threads can run thru these regions at the same
>     time.
>     I assume this should be safe, and during invocations of postgres
>     the KRB5CCNAME should always point to the credentials of the
>     acting REMOTE_USER.

Any chance you could share that patch..?  Considering that pgAdmin4 has,
sadly, decided to go the (broken) route of adding LDAP basic-user auth,
it'd really be good to, out of the box, make it support Kerberos-based
auth, even with the limitations you've described here.

>   Things I am not completely certain about:
>
>   * I assume that the credentials are only used during the connect
>     (as afterwards the connection is authenticated and they shouldn't
>     have any use anymore for that connection).

Not sure on this- hopefully a pgAdmin4 dev can answer, but it seems
likely to me.

>   * There may be occasions when the database is connected independent
>     of a user action from the web. I doubt that this is the case,
>     because pgadmin would need to ask for the database password at
>     that point, but I didn't analyze the code.
>     In that case there would be no REMOTE_USER information (or a wrong
>     one, which is worse).

Ditto on this one.

>   * There is a feature called "async", or PQconnectStart(). This seems
>     to return *before* the connection is made, i.e. before the
>     KRB5CCNAME from the environment is consumed. But at least for now
>     it also seems that pgadmin does explicitely wait after this call
>     until the connection is established, so that this wait can be
>     included in the locked region.

Maybe not ideal, but doesn't seem that bad.

>   * There is a feature called pgAgent, which does some scheduled
>     tasks, by whatever means. I didn't look into that, I have no idea
>     how that would authenticate to the database, but it certainly does
>     not work with my scheme.

This would need its own Kerberos princ and then to have k5start running
to pull out tickets for it in an ongoing manner and then whatever
process is handling the pgAgent stuff would set its KRB5CCNAME to that
credential cache.

>   (*) I didn't like the idea of creating a file everytime; since this
>     staye in the same process, it would be more appropriate to
>     handover the cred in memory. But it would be difficult to pull
>     them out of the kerberos library, and there seems no way to pass
>     them on to postgres library.

I'd certainly be interested in improving on this situation...

>     So I considered modifying this thing for the purpose:
>     https://www.freebsd.org/cgi/man.cgi?query=kcm
>     But I could not get that running even in its normal operation.

That's too bad as it does look pretty interesting.

>     So for now I do compare the received credential with the one in
>     the file, and write only if they are different.

Not sure about this part..?

> So far, thats the storyline. Enjoy.

Any chance you could share the patch..?

Thanks!

Stephen

Greetings,

* Dave Page (dpage@pgadmin.org) wrote:
> On Wed, May 6, 2020 at 5:20 PM Stephen Frost <sfrost@snowman.net> wrote:
> > Any chance you could share that patch..?  Considering that pgAdmin4 has,
> > sadly, decided to go the (broken) route of adding LDAP basic-user auth,
>
> Less secure != broken, unless you know something I don't (and bear in mind
> I've seen your talk on the subject :-p )

You could make the same distinction and argument when talking about
NTLM, LANMAN, or even hash algorithms like MD5.  There's good reasons
for why Microsoft moved away from NTLM and why all of their applications
use Kerberos and explicitly not LDAP-simple-bind for authentication.

> LDAP was added as the first option whilst adding support for pluggable
> authentication mechanisms, partly because it's the one we're most
> familiar with, and partly because it's by far the most common option
> requested by users (and yes, whilst like you I would love to be able to
> tell them all to just use Kerberos, we both know that's not realistic).

The most requested, in my experience at least, isn't LDAP- it's Active
Directory integration, with an expectation that it'll work in the same,
secure, way that SQL Server integrates into AD.  That's not what any of
this is though- and we see people being confused and making incorrect
assumptions about what the LDAP support in PG is already, and I'm sure
they'll also be confused with pgAdmin4.

This is something that comes up too, and not even that long ago-

https://www.postgresql.org/message-id/flat/16079-29e9c038e1463751%40postgresql.org

The poster even claims that with ldap auth: "But the user credentials
will not be sent to Postgresql server to authenticate", which is clearly
wrong.

> > it'd really be good to, out of the box, make it support Kerberos-based
> > auth, even with the limitations you've described here.
>
> We already have a Kerberos module on our plan to follow on from the LDAP
> one. Following that we plan to also add support for Kerberos authentication
> to the database servers themselves.

Glad to hear it, I'd be happy to help with Kerberos auth support.
Sounds like it's actually rather easy to implement it, based on Peter's
comments (which isn't surprising, really, it's actually *not* very hard
to enable for a web app thanks to modules like mod_auth_kerb- probably a
great deal less code than the LDAP auth needed, in fact).

Thanks,

Stephen

Greetings,

* Dave Page (dpage@pgadmin.org) wrote:
> On Thu, May 7, 2020 at 3:52 PM Stephen Frost <sfrost@snowman.net> wrote:
> > * Dave Page (dpage@pgadmin.org) wrote:
> > > On Wed, May 6, 2020 at 5:20 PM Stephen Frost <sfrost@snowman.net> wrote:
> > > > Any chance you could share that patch..?  Considering that pgAdmin4
> > has,
> > > > sadly, decided to go the (broken) route of adding LDAP basic-user auth,
> > >
> > > Less secure != broken, unless you know something I don't (and bear in
> > mind
> > > I've seen your talk on the subject :-p )
> >
> > You could make the same distinction and argument when talking about
> > NTLM, LANMAN, or even hash algorithms like MD5.  There's good reasons
> > for why Microsoft moved away from NTLM and why all of their applications
> > use Kerberos and explicitly not LDAP-simple-bind for authentication.
>
> I'm not saying it's the best option or anything close, simply that it's not
> broken in the dictionary sense of the word.

No hash algorithm's ever been broken in the dictionary sense of the
word. :)

> Maybe that person is confused (and certainly some others are), but I don't
> see anything in that particular message to indicate they're using AD. For
> all I can see they're using OpenLDAP or 389-ds.
>
> Regardless; it's clearly not feasible for us to persuade every user of
> non-AD LDAP to stop doing so.

I hear this argument time and time again and it just strikes me as a
complete cop-out and justification to continue supporting a horrible
auth method.  Not only that, but both the LDAP protocol and OpenLDAP
have supported SASL-based auth for a very long time, which can be (and
often is) Kerberos underneath.  There's really no good reason to use
simple binds with OpenLDAP any more than there's good reason to do so
with AD.

> > The poster even claims that with ldap auth: "But the user credentials
> > will not be sent to Postgresql server to authenticate", which is clearly
> > wrong.
>
> Yeah, definitely.

Sadly though, they're not alone, not in the least.  If we actually threw
a warning or a complaint of some kind in the PG client, as was
contemplated on that thread, about sending the user's credentials to the
server, I bet we'd see a sudden up-tick in questions about how to get
proper authentication implemented as people start to realize what's
actually happening.

> > > > it'd really be good to, out of the box, make it support Kerberos-based
> > > > auth, even with the limitations you've described here.
> > >
> > > We already have a Kerberos module on our plan to follow on from the LDAP
> > > one. Following that we plan to also add support for Kerberos
> > authentication
> > > to the database servers themselves.
> >
> > Glad to hear it, I'd be happy to help with Kerberos auth support.
> > Sounds like it's actually rather easy to implement it, based on Peter's
> > comments (which isn't surprising, really, it's actually *not* very hard
> > to enable for a web app thanks to modules like mod_auth_kerb- probably a
> > great deal less code than the LDAP auth needed, in fact).
>
> Our problem here is likely to be that we can't rely on mod_auth_krb. In a
> container we're running under Gunicorn for example (perhaps with a reverse
> proxy or Traefik in a different container), and users will often host under
> Nginx rather than Apache.

Ok, so I went and looked up a few things- first is that there's actually
a new module 'mod_auth_gss' for Apache, and there's an Nginx module for
SPNEGO which does GSSAPI:

https://github.com/stnoonan/spnego-http-auth-nginx-module

Unfortunately, for reasons that aren't very clear, it doesn't appear to
be set up to accept delegated credentials, so while you could use it to
authenticate a user connecting with GSS, you wouldn't be able to use
that to turn around and then connect to PG with it.

Now, that Apache mod_auth_gss module, on the other hand, looks like it
supports both delegated credentials and constrained credential
delegation, which is even better.  For pgAdmin4's roadmap, I'd argue
that it'd make the most sense to get things working with mod_auth_gss,
while also putting pressure on the nginx author to add support for
delegated credentials and, ideally, constrainted credential delegation.
I'm hoping to work on both of the latter items for PG in the near
future, to support connecting to other services via FDWs, and so I could
probably help with the nginx module if needed.

Thanks,

Stephen