MIME-Version: 1.0
References: 
 <CAFOhELdXhWMR2zS4dnH+SudN0s7LiENH+vczC0YhuifPgm+G5g@mail.gmail.com>
 <20210102154130.GO27507@tamriel.snowman.net>
 <CA+OCxozp+n+Mq+t=hPH1ExwT-MJbrhY0ujgkf+UoUriHo1PpGA@mail.gmail.com>
 <20210102155947.GQ27507@tamriel.snowman.net>
 <CA+OCxoydYmasD36n7Zk5_UPh9x03-QRqF53=sYbx3-rSYxPZsQ@mail.gmail.com>
 <20210103173112.GR27507@tamriel.snowman.net>
 <CABUevEztMrWc9bxxDSL=1d8hCwPRu=HzM0wTLYBYoQwdQvKhzg@mail.gmail.com>
 <CA+OCxoxMGiqVr1xoy6AKB0iuHiSp77ODeLJM_HFZ4fnUux+8rQ@mail.gmail.com>
 <20210111165011.GP27507@tamriel.snowman.net>
 <CA+OCxoyF3w+3bdQpCFnMeUrSpjkyX=a1XkudGz9Ep4PQNeSmvA@mail.gmail.com>
 <20210111174221.GQ27507@tamriel.snowman.net>
 <CA+OCxozRocruLjk=Mvh7sUzp9tkx9cvOFLdYvu3nEGriW0QEzg@mail.gmail.com>
In-Reply-To: 
 <CA+OCxozRocruLjk=Mvh7sUzp9tkx9cvOFLdYvu3nEGriW0QEzg@mail.gmail.com>
From: Magnus Hagander <magnus@hagander.net>
Date: Tue, 12 Jan 2021 11:04:43 +0100
Message-ID: 
 <CABUevEwtt5+ZBqjKayAsyzXVifUdHHQTeV1-5M5k=eOVbYDwLw@mail.gmail.com>
Subject: Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1
To: Dave Page <dpage@pgadmin.org>
Cc: Stephen Frost <sfrost@snowman.net>,
 Khushboo Vashi <khushboo.vashi@enterprisedb.com>,
	pgadmin-hackers <pgadmin-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Jan 12, 2021 at 10:08 AM Dave Page <dpage@pgadmin.org> wrote:
>
> Hi
>
> On Mon, Jan 11, 2021 at 5:42 PM Stephen Frost <sfrost@snowman.net> wrote:
>>
>>
>> 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.
>
>
> Which is no worse than the current situation - in fact it's arguably bett=
er because there's one less system that isn't Kerberised.
>
> Don't forget, you (as the system administrator) also have the choice of w=
hether or not to use Kerberos. If you're not happy to have the pgAdmin auth=
entication be kerberised whilst the database server access is not, then don=
't enable Kerberos until phase 2 is complete.
>
>>
>>
>> > You basically seem to be saying that once a user logs into something u=
sing
>> > Kerberos, *everything* else they login to from there must also be done
>> > using Kerberos - which clearly will not be the case in the vast majori=
ty 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 suspect that may not be the case, or at least most people will be worki=
ng in mixed environments, e.g. Kerberos on their local network with non-Ker=
berised RDS servers for example. This is certainly something I've seen in t=
he field many times.

+1. I can see a lot of cases where people would like to benefit from
the *convenience* of Kerberos login into their pgadmin, and then
continue to use a db connection that does not use Kerberos. There's
many orgs that for example have a policy that says they *must* use
passwords in to the db regardless of Kerbeos. We can argue whether
that's a smart policy or not, but it's very real, and those people
would still be able to benefit from a Kerberos login into pgadmin.

Getting those people to do kerberos into pgadmin and then password
intot he database would be a strong improvement over ldap to pgadmin
and password into the database. Sure, if the ldap password and the db
password is the same the difference isn't that big, but more often
than not the db password is independent.

RDS is a good example of this, but there are definitely plenty of
non-cloud environments who would also benefit fro that.


>> I don't understand all this push-back.
>
>
> There are benefits for some users with phase one alone, so I don't see (a=
nd still don't) a need to hold it back. It also potentially allows us to ge=
t feedback on things that don't work as expected earlier, to minimise any r=
e-work that might be required. Don't forget that pgAdmin releases monthly (=
except around EOY for obvious reasons), and incrementally releases and adds=
 features, unlike PostgreSQL.
>
>>
>>
>> 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.
>
>
> Phase 2 is scheduled to be done immediately.

\o/


--=20
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/