Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kvjfY-0003Qt-4M for pgadmin-hackers@arkaria.postgresql.org; Sat, 02 Jan 2021 16:22:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kvjfW-0003Th-Dk for pgadmin-hackers@arkaria.postgresql.org; Sat, 02 Jan 2021 16:22:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kvjfV-0003TO-RI for pgadmin-hackers@lists.postgresql.org; Sat, 02 Jan 2021 16:22:18 +0000 Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kvjfP-0001YU-LK for pgadmin-hackers@postgresql.org; Sat, 02 Jan 2021 16:22:16 +0000 Received: by mail-ej1-x632.google.com with SMTP id ga15so30810231ejb.4 for ; Sat, 02 Jan 2021 08:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=foF4LWTTlmoh/Qp1/hczV0rUIYWUyKdM+I6gAvnl0z0=; b=jMjr05f+fu25doxBgQKlmHbMSLUAyMXN+GpKNisv+p5/Nlq2RLRPt61UIUaXpVGlC5 7xGCbGa1js+otk+OBeDo6iRW8nJErcKxdpVwE+CVAjLPqobFcBE4kHIjt5/KfgF4aiXL sbNVdJwadflcQkuZz7lXqAI/VsT9p6uMeXdzssoTazGZEwFiy05xaMn+v+q+OBq2NYoW g0HDk4pdMYNwSbe4zY9OJwGCMcn4HsAWtz6Z47LyncRq9jdTxu1XqLaOii552SruBgVQ FMSLL89XY7cBtvutn1kuJjDNmZa5PVzsMU3AgtcfyshZAsAA9PzXfAqU8Owc2Ovsj8M3 ssnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=foF4LWTTlmoh/Qp1/hczV0rUIYWUyKdM+I6gAvnl0z0=; b=XomBsyUgxEGn6jUo3/yo55lvDUCcrYQdR/46ZjcFj1xpu0Ya9oc/DyC4dDa0TTxUTh U4q3isrm3q1bxHIoXWA9GxXCHzDigeDAmGMnB9UOxjpX7izwf46d+emy4tnC5qKdDNDD 8geX9KRj1f7S454V/ZAUfayxHUEHhIlVSrb1+bEvotW86/1fIkE0JPY5mI8EJ5x19oTm xlGPJnVh6RFKt5NQJwaBtS3aRjFqxS8ojJCqN7Rh4nPE9+onexEZHuxuOPReIpwu70fU eZT9764WFUDEX93DCQuc5n6NB2bNxMLHM6d8VygS65WT5/gwdyNlrQymLqSU5puGo8Cq JQ6g== X-Gm-Message-State: AOAM5333wMSVLUCnvblqn/7tRJ8kHF6/Ml723dNGfZ0kaCx/SrXKAMMn ZBWny1R+g8e3GqJtaMEeZK4GGEuS3RCglDDddgZ+gA== X-Google-Smtp-Source: ABdhPJyv1mUAvr2jjtvs4UTzN/9qNUk/InBxOfU2HiBjWvttdmopIWkZwPLpLzVYrCYKY48bA69aCd0YhZFPezn0IXE= X-Received: by 2002:a17:907:3e85:: with SMTP id hs5mr62473316ejc.548.1609604530245; Sat, 02 Jan 2021 08:22:10 -0800 (PST) MIME-Version: 1.0 References: <20210102154130.GO27507@tamriel.snowman.net> <20210102155947.GQ27507@tamriel.snowman.net> In-Reply-To: <20210102155947.GQ27507@tamriel.snowman.net> From: Dave Page Date: Sat, 2 Jan 2021 16:21:59 +0000 Message-ID: Subject: Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1 To: Stephen Frost Cc: Khushboo Vashi , pgadmin-hackers Content-Type: multipart/alternative; boundary="0000000000004130e305b7ed42f0" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000004130e305b7ed42f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi On Sat, 2 Jan 2021 at 15:59, Stephen Frost wrote: > Greetings Dave! > > * Dave Page (dpage@pgadmin.org) wrote: > > On Sat, 2 Jan 2021 at 15:41, Stephen Frost wrote: > > > * Khushboo Vashi (khushboo.vashi@enterprisedb.com) wrote: > > > > Please find the attached patch to support Kerberos Authentication i= n > > > > pgAdmin RM 5457. > > > > > > > > The patch introduces a new pluggable option for Kerberos > authentication, > > > > using SPNEGO to forward kerberos tickets through a browser which wi= ll > > > > bypass the login page entirely if the Kerberos Authentication > succeeds. > > > > > > I've taken a (very short) look at this as it's certainly something th= at > > > 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 h= ow > > > they're actually being used (if at all), which is a very important pa= rt > > > 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 wo= rk > > > for constrainted delegation implementations. > > > > Phase 1 of this project (which this patch aims to implement) is to hand= le > > Kerberos logins to pgAdmin when running in server mode (as we=E2=80=99v= e already > > done for LDAP, except KRB authenticated users don=E2=80=99t see a login= page of > > course). Phase 2 will add support for logging into the PostgreSQL > servers - > > I believe that is where we=E2=80=99ll need to handle delegated credenti= als, > 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=E2=80=99t impersonate the user at all, it would just work as it d= oes 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=E2=80=99t work (unless the service account under whic= h the pgAdmin server is running has a valid ticket through other means). > -- --=20 Dave Page https://pgsnake.blogspot.com EDB Postgres https://www.enterprisedb.com --0000000000004130e305b7ed42f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Sat, 2 Jan 2021 at 15:59, Stephen Frost <sfrost@snowman.net> wrote:
Greetings Dave!

* Dave Page (dpage@p= gadmin.org) wrote:
> On Sat, 2 Jan 2021 at 15:41, Stephen Frost <sfrost@snowman.net> wrote:
> > * Khushboo Vashi (khushboo.vashi@enterprisedb.com) wrote:
> > > Please find the attached patch to support Kerberos Authentic= ation in
> > > pgAdmin RM 5457.
> > >
> > > The patch introduces a new pluggable option for Kerberos aut= hentication,
> > > using SPNEGO to forward kerberos tickets through a browser w= hich will
> > > bypass the login page entirely if the Kerberos Authenticatio= n 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 impo= rtant 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 li= bpq /
> > the Kerberos libraries that the delegated credentials can be foun= d in
> > the temporary file.=C2=A0 I don't see any of that happening i= n this patch- is
> > that already handled in some way?=C2=A0 If not, what's the pl= an for making
> > that work?=C2=A0 Also important is to make sure that this approac= h will work
> > for constrainted delegation implementations.
>
> Phase 1 of this project (which this patch aims to implement) is to han= dle
> Kerberos logins to pgAdmin when running in server mode (as we=E2=80=99= ve already
> done for LDAP, except KRB authenticated users don=E2=80=99t see a logi= n page of
> course). Phase 2 will add support for logging into the PostgreSQL serv= ers -
> I believe that is where we=E2=80=99ll need to handle delegated credent= ials, 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=E2=80=99t impersonate the user at all, it would ju= st work as it does now, requiring the user to supply a username/password fo= r scram/md5/ldap etc, or a cert for SSL auth. Connection to a PostgreSQL se= rver which required gss or sspi simply wouldn=E2=80=99t work (unless the se= rvice account under which the pgAdmin server is running has a valid ticket = through other means).
--
--
Dave Page
https://pgsnake.blogspot.com

EDB Postgres
https://www.enterprisedb.com
--0000000000004130e305b7ed42f0--