Re: [SOLVED] Re: pgAdmin 4 + python wheel + kerberos - Mailing list pgadmin-support
| From | Dave Page |
|---|---|
| Subject | Re: [SOLVED] Re: pgAdmin 4 + python wheel + kerberos |
| Date | |
| Msg-id | CA+OCxoyijk681=qQ07TP3qjCbjeFAg4t00A-PGx3wReJpSfZQw@mail.gmail.com Whole thread Raw |
| In response to | Re: [SOLVED] Re: pgAdmin 4 + python wheel + kerberos (Stephen Frost <sfrost@snowman.net>) |
| Responses |
Re: [SOLVED] Re: pgAdmin 4 + python wheel + kerberos
(Stephen Frost <sfrost@snowman.net>)
|
| List | pgadmin-support |
Hi
On Wed, May 6, 2020 at 5:20 PM Stephen Frost <sfrost@snowman.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
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
pgadmin-support by date: