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

On Mon, Jan 11, 2021 at 1:15 PM Magnus Hagander <magnus(at)hagander(dot)net> wrote:

> On Sun, Jan 3, 2021 at 6:31 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> >
> > Greetings,
> >
> > * Dave Page (dpage(at)pgadmin(dot)org) wrote:
> > > On Sat, 2 Jan 2021 at 15:59, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > > > * 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).
> >
> > That *is* impersonating the user..
> >
> > Kerberized services really should *not* be accepting a cleartext
> > password to use to authenticate as the user against another service,
> > which is why I'd strongly recommend against releasing with just
> > 'phase 1' done.. or at least heavily caveat'ing it that this isn't
> > actually real Kerberos support but is just an intermediate step that no
> > one should really deploy...
>
> AIUI that's not what's being proposed.
>
> Correct me if I'm wrong, but I think what's said is that this phase would:
>
> 1. Allow kerberos login *to pgadmin*.
> 2. Do exactly *nothing* to logins to the database server.
>
> So per (2) logins to the db server would work exactly the same as it
> does today, and bear no connection to the actual KRB login at all.
>

Correct.

>
> One question around that though -- when I click "save password" on a
> database connection in pgadmin, it gets stored on the pgadmin server.
> Isn't the key used to encrypt that derived from my password? If I'm
> logging into pgadmin without a password (using kerberos),what would
> that key be derived from?
>

Also correct - and right now, the plan is to disable password saving if
logged in using Kerberos.

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

EDB: http://www.enterprisedb.com