Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1

Hi

On Sat, 2 Jan 2021 at 15:59, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> Greetings Dave!
>
> * Dave Page (dpage(at)pgadmin(dot)org) wrote:
> > On Sat, 2 Jan 2021 at 15:41, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > > * Khushboo Vashi (khushboo(dot)vashi(at)enterprisedb(dot)com) wrote:
> > > > Please find the attached patch to support Kerberos Authentication in
> > > > pgAdmin RM 5457.
> > > >
> > > > The patch introduces a new pluggable option for Kerberos
> authentication,
> > > > using SPNEGO to forward kerberos tickets through a browser which will
> > > > bypass the login page entirely if the Kerberos Authentication
> succeeds.
> > >
> > > I've taken a (very short) look at this as it's certainly something that
> > > I'm interested in and glad to see work is being done on it.
> > >
> > > I notice that 'delegated_creds' is being set but it's unclear to me how
> > > they're actually being used (if at all), which is a very important part
> > > of Kerberos.
> > >
> > > What's commonly done with mod_auth_kerb/mod_auth_gss is that the
> > > delegated credentials are stored on the filesystem in a temporary
> > > directory and then an environment variable is set to signal to libpq /
> > > the Kerberos libraries that the delegated credentials can be found in
> > > the temporary file. I don't see any of that happening in this patch-
> is
> > > that already handled in some way? If not, what's the plan for making
> > > that work? Also important is to make sure that this approach will work
> > > for constrainted delegation implementations.
> >
> > Phase 1 of this project (which this patch aims to implement) is to handle
> > Kerberos logins to pgAdmin when running in server mode (as we’ve already
> > done for LDAP, except KRB authenticated users don’t see a login page of
> > course). Phase 2 will add support for logging into the PostgreSQL
> servers -
> > I believe that is where we’ll need to handle delegated credentials,
> correct?
>
> Yes, though I sure hope there isn't a plan to release just 'phase 1'
> since that would imply that the user is still sending their password to
> pgAdmin in some form that pgAdmin then turns around and impersonates the
> user, basically completely against how Kerberos auth should be working
> in this kind of a intermediate service arrangement.
>
> In other words, if just 'phase 1' is released, it'd probably be CVE
> worthy right out of the gate...

It wouldn’t impersonate the user at all, it would just work as it does now,
requiring the user to supply a username/password for scram/md5/ldap etc, or
a cert for SSL auth. Connection to a PostgreSQL server which required gss
or sspi simply wouldn’t work (unless the service account under which the
pgAdmin server is running has a valid ticket through other means).

> --
--
Dave Page
https://pgsnake.blogspot.com

EDB Postgres
https://www.enterprisedb.com