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

Greetings,

* Dave Page (dpage@pgadmin.org) wrote:
> On Mon, Jan 11, 2021 at 4:50 PM Stephen Frost <sfrost@snowman.net> wrote:
> > If you're saying that, when Kerberos is enabled, users will never be
> > prompted to provide a password because password-based auth has been
> > disabled, then perhaps that's reasonable.  I don't know how useful such
> > a pgadmin setup would be, but at least it wouldn't be violating one of
> > the core values that using Kerberos brings.
> >
> > If you're saying that this is just disabling password *saving*, then
> > that implies that if someone actually wants to use pgadmin to, uh, log
> > into a PostgreSQL server which is configured for md5 or SCRAM auth or
> > LDAP based auth that the way that'll work is that pgadmin will prompt
> > the user for a password, which the user will provide and which will
> > then be sent from the client to the pgadmin system in the clear, and
> > which pgadmin will turn around and use to log into PG with, right?
>
> Yes.

Alright, glad I wasn't completely misunderstanding something.

> > It's the latter than I'm concerned with because it just wouldn't be
> > appropriate for a Kerberized service which is set up to use Kerberos to
> > then prompt the user for a password.
>
> Well you never answered my previous question about that. Why is it
> appropriate for an FDW to do that, but not pgAdmin? Or for a user on a
> kerberised machine to use a web browser to access a non-kerberised site? Or
> frankly pretty much anything outside of a windows domain or kerberos
> environment that a user inside the environment might want to use?

Pretty sure I didn't say it was appropriate for an FDW to do that, it
really isn't, but FDWs are also a side feature of the overall product,
not a core component, and you have to be granted specific rights to be
able to use an FDW.

Accessing systems outside of the Kerberized environment is obviously a
different situation as you *can't* use the Kerberos credentials- and,
hopefully, everyone is using password managers and has a distinct and
different password for every service they do use outside of the
Kerberized environment.  When you're talking about a set of systems
which live inside of the Kerberized environment, however, it's simply
not sensible to ask the user to provide their *domain-level* credentials
which an attacker could use to log in as that user to the entire domain
and have complete access over their account and that's exactly what is
likely to end up being the case here because the only way to set this up
would be Kerberos for pgAdmin and LDAP for PG- at least until delegated
credentials are implemented.

> You basically seem to be saying that once a user logs into something using
> Kerberos, *everything* else they login to from there must also be done
> using Kerberos - which clearly will not be the case in the vast majority of
> deployments.

Everything else they login to from there in the same Kerberized
environment absolutely should be done using Kerberos delegated
credentials.  That's the point of Kerberos delegation.  Are you modeling
this approach based on some existing system which accepts Kerberos
logins but then *doesn't* allow use of delegated credentials to log into
other Kerberized systems from there?  Surely SSH works great with
delegated credentials, as does any website that uses mod_auth_kerb or
mod_auth_gss, or IIS..

I sure hope that the vast majority of deployments where pgAdmin is set
up with Kerberos will be using Kerberos for logging into PG with
delegated credentials, and further, that we will be *strongly*
encouraging that as otherwise you might as well use LDAP auth for all of
it and accept that any compromise of the web server or of PG will result
in complete compromise of any user's account who accesses the system.

I don't understand all this push-back.

The intent is to do the 'phase 2', right?  And it hopefully will happen
in relatively short order, no?  At least, I'd think it would make sense,
while people have developer environments set up and working with
Kerberos to go ahead and get that part done.  All I'm saying is that the
'phase 1' part really shouldn't be independently released, or if it is,
it should be *heavily* caveated that it is strongly discouraged for
people to run it in an environment where pgadmin and PG are in the same
Kerberized environment because it's not possible to set that up, with
just phase 1 done, in a manner which would avoid the pgadmin and PG
servers seeing the user's password.

Thanks,

Stephen