Re: [SOLVED] Re: pgAdmin 4 + python wheel + kerberos

Hi

On Wed, May 6, 2020 at 5:20 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:

>
> Any chance you could share that patch..? Considering that pgAdmin4 has,
> sadly, decided to go the (broken) route of adding LDAP basic-user auth,
>

Less secure != broken, unless you know something I don't (and bear in mind
I've seen your talk on the subject :-p )

LDAP was added as the first option whilst adding support for pluggable
authentication mechanisms, partly because it's the one we're most
familiar with, and partly because it's by far the most common option
requested by users (and yes, whilst like you I would love to be able to
tell them all to just use Kerberos, we both know that's not realistic).

> it'd really be good to, out of the box, make it support Kerberos-based
> auth, even with the limitations you've described here.
>

We already have a Kerberos module on our plan to follow on from the LDAP
one. Following that we plan to also add support for Kerberos authentication
to the database servers themselves.

>
> > Things I am not completely certain about:
> >
> > * I assume that the credentials are only used during the connect
> > (as afterwards the connection is authenticated and they shouldn't
> > have any use anymore for that connection).
>
> Not sure on this- hopefully a pgAdmin4 dev can answer, but it seems
> likely to me.
>

Correct.

>
> > * There may be occasions when the database is connected independent
> > of a user action from the web. I doubt that this is the case,
> > because pgadmin would need to ask for the database password at
> > that point, but I didn't analyze the code.
> > In that case there would be no REMOTE_USER information (or a wrong
> > one, which is worse).
>
> Ditto on this one.
>

There aren't any cases I can think of where a connection is made
independent of some sort of user interaction. It may not be obvious that an
interaction is going to create a connection though. At the moment (iirc) we
don't handle the case where credentials change in some way with new
connections (e.g. if using OTPs), but we do have a TODO for that. The
current assumption is that connection info doesn't change once connected.

>
> > * There is a feature called "async", or PQconnectStart(). This seems
> > to return *before* the connection is made, i.e. before the
> > KRB5CCNAME from the environment is consumed. But at least for now
> > it also seems that pgadmin does explicitely wait after this call
> > until the connection is established, so that this wait can be
> > included in the locked region.
>
> Maybe not ideal, but doesn't seem that bad.
>
> > * There is a feature called pgAgent, which does some scheduled
> > tasks, by whatever means. I didn't look into that, I have no idea
> > how that would authenticate to the database, but it certainly does
> > not work with my scheme.
>
> This would need its own Kerberos princ and then to have k5start running
> to pull out tickets for it in an ongoing manner and then whatever
> process is handling the pgAgent stuff would set its KRB5CCNAME to that
> credential cache.
>

FWIW, we do not have any current plans to work on pgAgent. I don't think
anyone has ever asked for Kerberos support for that.

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company