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

Greetings,

* Khushboo Vashi ([hidden email]) wrote:
> Please find the attached patch to support Kerberos Authentication in
> pgAdmin RM 5457.
>
> The patch introduces a new pluggable option for Kerberos authentication,
> using SPNEGO to forward kerberos tickets through a browser which will
> bypass the login page entirely if the Kerberos Authentication succeeds.

I've taken a (very short) look at this as it's certainly something that
I'm interested in and glad to see work is being done on it.

I notice that 'delegated_creds' is being set but it's unclear to me how
they're actually being used (if at all), which is a very important part
of Kerberos.

What's commonly done with mod_auth_kerb/mod_auth_gss is that the
delegated credentials are stored on the filesystem in a temporary
directory and then an environment variable is set to signal to libpq /
the Kerberos libraries that the delegated credentials can be found in
the temporary file.  I don't see any of that happening in this patch- is
that already handled in some way?  If not, what's the plan for making
that work?  Also important is to make sure that this approach will work
for constrainted delegation implementations.

Greetings Dave!

* Dave Page ([hidden email]) wrote:
> On Sat, 2 Jan 2021 at 15:41, Stephen Frost <[hidden email]> wrote:
> > * Khushboo Vashi ([hidden email]) wrote:
> > > Please find the attached patch to support Kerberos Authentication in
> > > pgAdmin RM 5457.
> > >
> > > The patch introduces a new pluggable option for Kerberos authentication,
> > > using SPNEGO to forward kerberos tickets through a browser which will
> > > bypass the login page entirely if the Kerberos Authentication succeeds.
> >
> > I've taken a (very short) look at this as it's certainly something that
> > I'm interested in and glad to see work is being done on it.
> >
> > I notice that 'delegated_creds' is being set but it's unclear to me how
> > they're actually being used (if at all), which is a very important part
> > of Kerberos.
> >
> > What's commonly done with mod_auth_kerb/mod_auth_gss is that the
> > delegated credentials are stored on the filesystem in a temporary
> > directory and then an environment variable is set to signal to libpq /
> > the Kerberos libraries that the delegated credentials can be found in
> > the temporary file.  I don't see any of that happening in this patch- is
> > that already handled in some way?  If not, what's the plan for making
> > that work?  Also important is to make sure that this approach will work
> > for constrainted delegation implementations.
>
> Phase 1 of this project (which this patch aims to implement) is to handle
> Kerberos logins to pgAdmin when running in server mode (as we’ve already
> done for LDAP, except KRB authenticated users don’t see a login page of
> course). Phase 2 will add support for logging into the PostgreSQL servers -
> I believe that is where we’ll need to handle delegated credentials, correct?

Yes, though I sure hope there isn't a plan to release just 'phase 1'
since that would imply that the user is still sending their password to
pgAdmin in some form that pgAdmin then turns around and impersonates the
user, basically completely against how Kerberos auth should be working
in this kind of a intermediate service arrangement.

In other words, if just 'phase 1' is released, it'd probably be CVE
worthy right out of the gate...

Greetings,

* Dave Page ([hidden email]) wrote:
> On Sat, 2 Jan 2021 at 15:59, Stephen Frost <[hidden email]> wrote:
> > * Dave Page ([hidden email]) wrote:
> > > On Sat, 2 Jan 2021 at 15:41, Stephen Frost <[hidden email]> wrote:
> > > > * Khushboo Vashi ([hidden email]) wrote:
> > > > > Please find the attached patch to support Kerberos Authentication in
> > > > > pgAdmin RM 5457.
> > > > >
> > > > > The patch introduces a new pluggable option for Kerberos
> > authentication,
> > > > > using SPNEGO to forward kerberos tickets through a browser which will
> > > > > bypass the login page entirely if the Kerberos Authentication
> > succeeds.
> > > >
> > > > I've taken a (very short) look at this as it's certainly something that
> > > > I'm interested in and glad to see work is being done on it.
> > > >
> > > > I notice that 'delegated_creds' is being set but it's unclear to me how
> > > > they're actually being used (if at all), which is a very important part
> > > > of Kerberos.
> > > >
> > > > What's commonly done with mod_auth_kerb/mod_auth_gss is that the
> > > > delegated credentials are stored on the filesystem in a temporary
> > > > directory and then an environment variable is set to signal to libpq /
> > > > the Kerberos libraries that the delegated credentials can be found in
> > > > the temporary file.  I don't see any of that happening in this patch-
> > is
> > > > that already handled in some way?  If not, what's the plan for making
> > > > that work?  Also important is to make sure that this approach will work
> > > > for constrainted delegation implementations.
> > >
> > > Phase 1 of this project (which this patch aims to implement) is to handle
> > > Kerberos logins to pgAdmin when running in server mode (as we’ve already
> > > done for LDAP, except KRB authenticated users don’t see a login page of
> > > course). Phase 2 will add support for logging into the PostgreSQL
> > servers -
> > > I believe that is where we’ll need to handle delegated credentials,
> > correct?
> >
> > Yes, though I sure hope there isn't a plan to release just 'phase 1'
> > since that would imply that the user is still sending their password to
> > pgAdmin in some form that pgAdmin then turns around and impersonates the
> > user, basically completely against how Kerberos auth should be working
> > in this kind of a intermediate service arrangement.
> >
> > In other words, if just 'phase 1' is released, it'd probably be CVE
> > worthy right out of the gate...
>
> It wouldn’t impersonate the user at all, it would just work as it does now,
> requiring the user to supply a username/password for scram/md5/ldap etc, or
> a cert for SSL auth. Connection to a PostgreSQL server which required gss
> or sspi simply wouldn’t work (unless the service account under which the
> pgAdmin server is running has a valid ticket through other means).

That *is* impersonating the user..

Kerberized services really should *not* be accepting a cleartext
password to use to authenticate as the user against another service,
which is why I'd strongly recommend against releasing with just
'phase 1' done.. or at least heavily caveat'ing it that this isn't
actually real Kerberos support but is just an intermediate step that no
one should really deploy...

On Sun, Jan 3, 2021 at 6:31 PM Stephen Frost <[hidden email]> wrote:
>
> Greetings,
>
> * Dave Page ([hidden email]) wrote:
> > On Sat, 2 Jan 2021 at 15:59, Stephen Frost <[hidden email]> wrote:
> > > * Dave Page ([hidden email]) wrote:
> > > > On Sat, 2 Jan 2021 at 15:41, Stephen Frost <[hidden email]> wrote:
> > > > > * Khushboo Vashi ([hidden email]) wrote:
> > > > > > Please find the attached patch to support Kerberos Authentication in
> > > > > > pgAdmin RM 5457.
> > > > > >
> > > > > > The patch introduces a new pluggable option for Kerberos
> > > authentication,
> > > > > > using SPNEGO to forward kerberos tickets through a browser which will
> > > > > > bypass the login page entirely if the Kerberos Authentication
> > > succeeds.
> > > > >
> > > > > I've taken a (very short) look at this as it's certainly something that
> > > > > I'm interested in and glad to see work is being done on it.
> > > > >
> > > > > I notice that 'delegated_creds' is being set but it's unclear to me how
> > > > > they're actually being used (if at all), which is a very important part
> > > > > of Kerberos.
> > > > >
> > > > > What's commonly done with mod_auth_kerb/mod_auth_gss is that the
> > > > > delegated credentials are stored on the filesystem in a temporary
> > > > > directory and then an environment variable is set to signal to libpq /
> > > > > the Kerberos libraries that the delegated credentials can be found in
> > > > > the temporary file.  I don't see any of that happening in this patch-
> > > is
> > > > > that already handled in some way?  If not, what's the plan for making
> > > > > that work?  Also important is to make sure that this approach will work
> > > > > for constrainted delegation implementations.
> > > >
> > > > Phase 1 of this project (which this patch aims to implement) is to handle
> > > > Kerberos logins to pgAdmin when running in server mode (as we’ve already
> > > > done for LDAP, except KRB authenticated users don’t see a login page of
> > > > course). Phase 2 will add support for logging into the PostgreSQL
> > > servers -
> > > > I believe that is where we’ll need to handle delegated credentials,
> > > correct?
> > >
> > > Yes, though I sure hope there isn't a plan to release just 'phase 1'
> > > since that would imply that the user is still sending their password to
> > > pgAdmin in some form that pgAdmin then turns around and impersonates the
> > > user, basically completely against how Kerberos auth should be working
> > > in this kind of a intermediate service arrangement.
> > >
> > > In other words, if just 'phase 1' is released, it'd probably be CVE
> > > worthy right out of the gate...
> >
> > It wouldn’t impersonate the user at all, it would just work as it does now,
> > requiring the user to supply a username/password for scram/md5/ldap etc, or
> > a cert for SSL auth. Connection to a PostgreSQL server which required gss
> > or sspi simply wouldn’t work (unless the service account under which the
> > pgAdmin server is running has a valid ticket through other means).
>
> That *is* impersonating the user..
>
> Kerberized services really should *not* be accepting a cleartext
> password to use to authenticate as the user against another service,
> which is why I'd strongly recommend against releasing with just
> 'phase 1' done.. or at least heavily caveat'ing it that this isn't
> actually real Kerberos support but is just an intermediate step that no
> one should really deploy...

AIUI that's not what's being proposed.

Correct me if I'm wrong, but I think what's said is that this phase would:

1. Allow kerberos login *to pgadmin*.
2. Do exactly *nothing* to logins to the database server.

So per (2) logins to the db server would work exactly the same as it
does today, and bear no connection to the actual KRB login at all.

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?

Greetings,

* Dave Page ([hidden email]) wrote:
> On Mon, Jan 11, 2021 at 1:15 PM Magnus Hagander <[hidden email]> 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*?

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?

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.

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.

Hi Khushboo,

I've just done the code review. Apart from below, the patch looks good to me:

1) Move the auth source constants -ldap, kerberos out of app object. They don't belong there. You can create the constants somewhere else and import them.

+app.PGADMIN_LDAP_AUTH_SOURCE = 'ldap'

+app.PGADMIN_KERBEROS_AUTH_SOURCE = 'kerberos'

2) Are we going to make kerberos default for wsgi ?

--- a/web/pgAdmin4.wsgi

+++ b/web/pgAdmin4.wsgi

@@ -24,6 +24,10 @@ builtins.SERVER_MODE = True

 

 import config

 

+

+config.AUTHENTICATION_SOURCES = ['kerberos']

+config.KERBEROS_AUTO_CREATE_USER = True

+

3) Remove the commented code.

+            # if self.form.data['email'] and self.form.data['password'] and \

+            #         source.get_source_name() ==\

+            #         current_app.PGADMIN_KERBEROS_AUTH_SOURCE:

+            #     continue

4) KERBEROSAuthentication could be KerberosAuthentication

class KERBEROSAuthentication(BaseAuthentication):

5) You can use the constants (ldap, kerberos) you had defined when creating a user.

+                    'auth_source': 'kerberos'

6) The below URLs belong to the authenticate module. Currently they are in the browser module. I would also suggest rephrasing the URL from /kerberos_login to /login/kerberos. Same for logout.

Also, even though the method GET works, we should use the POST method for login and DELETE for logout.

+@blueprint.route("/kerberos_login",

+                 endpoint="kerberos_login", methods=["GET"])

+@blueprint.route("/kerberos_logout",

+                 endpoint="kerberos_logout", methods=["GET"])

On Tue, Dec 22, 2020 at 6:07 PM Akshay Joshi <[hidden email]> wrote:

Hi Aditya

Can you please do the code review?

On Tue, Dec 22, 2020 at 3:44 PM Khushboo Vashi <[hidden email]> wrote:

Hi,

Please find the attached patch to support Kerberos Authentication in pgAdmin RM 5457.

The patch introduces a new pluggable option for Kerberos authentication, using SPNEGO to forward kerberos tickets through a browser which will bypass the login page entirely if the Kerberos Authentication succeeds.

The complete setup of the Kerberos Server + pgAdmin Server + Client is documented in a separate file and attached.

This patch also includes the small fix related to logging #5829

Thanks,

Khushboo

--

Thanks & Regards

Akshay Joshi

pgAdmin Hacker | Principal Software Architect

EDB Postgres

Mobile: +91 976-788-8246

--

Thanks,

Aditya Toshniwal

pgAdmin hacker | Sr. Software Engineer | edbpostgres.com

"Don't Complain about Heat, Plant a TREE"

Hi Khushboo

Seems you have attached the wrong patch. Please send the updated patch.

On Wed, Jan 13, 2021 at 2:35 PM Khushboo Vashi <[hidden email]> wrote:

Hi,

Please find the attached updated patch.

Thanks,

Khushboo

On Fri, Jan 1, 2021 at 1:07 PM Aditya Toshniwal <[hidden email]> wrote:

Hi Khushboo,

I've just done the code review. Apart from below, the patch looks good to me:

1) Move the auth source constants -ldap, kerberos out of app object. They don't belong there. You can create the constants somewhere else and import them.

+app.PGADMIN_LDAP_AUTH_SOURCE = 'ldap'

+app.PGADMIN_KERBEROS_AUTH_SOURCE = 'kerberos'

Done 

2) Are we going to make kerberos default for wsgi ?

--- a/web/pgAdmin4.wsgi

+++ b/web/pgAdmin4.wsgi

@@ -24,6 +24,10 @@ builtins.SERVER_MODE = True

 

 import config

 

+

+config.AUTHENTICATION_SOURCES = ['kerberos']

+config.KERBEROS_AUTO_CREATE_USER = True

+

Removed, it was only for testing. 

3) Remove the commented code.

+            # if self.form.data['email'] and self.form.data['password'] and \

+            #         source.get_source_name() ==\

+            #         current_app.PGADMIN_KERBEROS_AUTH_SOURCE:

+            #     continue

Removed the comment, it is actually the part of the code. 

4) KERBEROSAuthentication could be KerberosAuthentication

class KERBEROSAuthentication(BaseAuthentication):

Done. 

5) You can use the constants (ldap, kerberos) you had defined when creating a user.

+                    'auth_source': 'kerberos'

Done. 

6) The below URLs belong to the authenticate module. Currently they are in the browser module. I would also suggest rephrasing the URL from /kerberos_login to /login/kerberos. Same for logout.

Done the rephrasing as well as moved to the authentication module.

 

Also, even though the method GET works, we should use the POST method for login and DELETE for logout.

Kerberos_login just redirects the page to the actual login, so no need for the POST method.

I followed the same method for the Logout user we have used for the normal user.

 

+@blueprint.route("/kerberos_login",

+                 endpoint="kerberos_login", methods=["GET"])

+@blueprint.route("/kerberos_logout",

+                 endpoint="kerberos_logout", methods=["GET"])

 

On Tue, Dec 22, 2020 at 6:07 PM Akshay Joshi <[hidden email]> wrote:

Hi Aditya

Can you please do the code review?

On Tue, Dec 22, 2020 at 3:44 PM Khushboo Vashi <[hidden email]> wrote:

Hi,

Please find the attached patch to support Kerberos Authentication in pgAdmin RM 5457.

The patch introduces a new pluggable option for Kerberos authentication, using SPNEGO to forward kerberos tickets through a browser which will bypass the login page entirely if the Kerberos Authentication succeeds.

The complete setup of the Kerberos Server + pgAdmin Server + Client is documented in a separate file and attached.

This patch also includes the small fix related to logging #5829

Thanks,

Khushboo

--

Thanks & Regards

Akshay Joshi

pgAdmin Hacker | Principal Software Architect

EDB Postgres

Mobile: +91 976-788-8246

--

Thanks,

Aditya Toshniwal

pgAdmin hacker | Sr. Software Engineer | edbpostgres.com

"Don't Complain about Heat, Plant a TREE"

--

Thanks & Regards

Akshay Joshi

pgAdmin Hacker | Principal Software Architect

EDB Postgres

Mobile: +91 976-788-8246