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

On Mon, Jan 11, 2021 at 4:50 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> Greetings,
>
> * Dave Page (dpage(at)pgadmin(dot)org) wrote:
> > On Mon, Jan 11, 2021 at 1:15 PM Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
> > > 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.
>
> Disable password *saving*, or disable password *using*?
>

I'm pretty sure I wrote "saving".

>
> 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.

>
> 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?

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.

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

EDB: http://www.enterprisedb.com