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 1ldW1o-0000yL-Fr for pgadmin-hackers@arkaria.postgresql.org; Mon, 03 May 2021 10:42:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ldW1n-0005bJ-D8 for pgadmin-hackers@arkaria.postgresql.org; Mon, 03 May 2021 10:42:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ldW1m-0005bB-W5 for pgadmin-hackers@lists.postgresql.org; Mon, 03 May 2021 10:42:15 +0000 Received: from mail-io1-xd2c.google.com ([2607:f8b0:4864:20::d2c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ldW1f-0005j3-Ue for pgadmin-hackers@postgresql.org; Mon, 03 May 2021 10:42:14 +0000 Received: by mail-io1-xd2c.google.com with SMTP id z14so3661546ioc.12 for ; Mon, 03 May 2021 03:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xwlmz7Rh0yCcEgvE1SmHh7U2itcZ8DMMyGs7+RQb9dM=; b=T0lj7UBKBiDaH05TbFnPxf/MuWTr+BZbo56yUd5/VgEdZbp7yAkIw7JdgvnzLWJBdI sim6v/MtyXYvkSpnLxKFg2g0zDy4tv4p40W2E/3swC6RMHV5GZIZIaXNJ/yk1TFlpCLd EJWHrR2soXH7DJ5AobeaRMhIoUpgFw/YX9KctPAFapji+UwOawPygMrb/GT4YKGh/kyP e1IlKQHH9WaWAA5BGRcGwHCmC/dv9YIGmcJczDenIqrHAihSUraS+WPx1uDT4MWvEvN9 YTr3RRkHQ/y7CVY1jN6Zh8f0IHDehGQIUST201zB+pYG4WnDLipFyBIzzHbNFoADQaTZ E1Lw== 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=Xwlmz7Rh0yCcEgvE1SmHh7U2itcZ8DMMyGs7+RQb9dM=; b=swx9MuvCE+dt86wN1cRHDSQdlX/DaFbhRv2ztcSNscFIv+lK0/wKebvSadq1ebGFjy C/U4/G5/+nN+vISNC5s0xd7tfCjSsInFNYLNcd/frlXHn1V7eeXKp00y2qQnVZqCJomM /EfiHgr3k3cKE5YN2ZxpNfm1rOAR/JCDEq+GT0XOglk/XKBpDJ83WW/D0dOHztJeDglx ukmFhUx3E2yF4lpA76gclmlgGBKXjmJz7K8C8BXGNXJ/QV+Dl+jgrUTLY0Bd0Vb8coar WFmYq4W6zujPr0ShZaPkfRCYz9mcAmy5DXzmBU9E4zO8xAE93Igwj5PQrDnFyriMCLVi V5SA== X-Gm-Message-State: AOAM533N0U94AEq6dMVxHhPJ3FXWyhjjjuZ567X519KEODdu+tgGVWz6 VD6FhwBued78bYN2bXfV5Jy5IVDEOeyKLrlBzyqx+nJZOdaVGcXqBRHkGq9BshLCvG7mWEPpQ0Z piUyOY+vsb3vsiFxyoShb3VacMIDK9q8/bbfgh1V0T8h7tl/OEPw/Ymuxz8W6bPO4Er8pzVZpi7 dcN0clci5P6XemIizIZEfKjtuv0/ys+XNUrxbiR++tYHh+HsnKwnw1xYsQ2Y2Ftqo= X-Google-Smtp-Source: ABdhPJwBtozIVQm9uBjI85CWZGWRgcaYu9cHr89jNAS4TnXVFuy8Si/r4JpPdrUpN1Wk7sbKj5YNoGa1syvo3ps0cPw= X-Received: by 2002:a5e:8a47:: with SMTP id o7mr13568001iom.57.1620038525646; Mon, 03 May 2021 03:42:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Akshay Joshi Date: Mon, 3 May 2021 16:11:54 +0530 Message-ID: Subject: Re: [pgAdmin4][Patch] - RM 6158 - Logging into PostgreSQL servers with Kerberos Authentication To: Khushboo Vashi Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000d8131805c16a9ce4" X-CLOUD-SEC-AV-Info: enterprisedb,google_mail,monitor X-CLOUD-SEC-AV-Sent: true X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d8131805c16a9ce4 Content-Type: text/plain; charset="UTF-8" Thanks, patch applied. On Mon, May 3, 2021 at 2:50 PM Khushboo Vashi < khushboo.vashi@enterprisedb.com> wrote: > Hi Akshay, > > Please find the attached updated patch. > > Thanks, > Khushboo > > On Mon, Apr 26, 2021 at 12:42 PM Akshay Joshi < > akshay.joshi@enterprisedb.com> wrote: > >> Hi Khushboo >> >> I have applied your patch and started testing it in different scenarios. Following >> are the GUI review comments: >> >> - Update the comments about Kerberos support for AUTHENTICATION_SOURCES >> in config.py. >> >> Done. > >> >> - You will have to create a migration file again. Getting "Error: >> Multiple head revisions are present for given argument" >> >> Done. > >> >> - Increase the height of the server dialog as after adding "Kerberos >> Authentication?" switch Connection tab showing scroll bars. >> >> This is the default behaviour of all the dialogues, for example: Table > Advanced tab > >> >> - Desktop/Server mode Getting No such file or directory: >> '/var/lib/pgadmin/krbccache'. KERBEROS_CCACHE_DIR should only be >> created in Server Mode and AUTHENTICATION_SOURCES is 'kerberos'. >> >> Done > >> >> - Server Dialog "Kerberos Authentication?" switch control should be >> enabled only in Server Mode and AUTHENTICATION_SOURCES is 'kerberos'. >> >> Done > >> >> - "Kerberos Authentication?" switch should be disabled when the >> server is connected. >> >> Even if the user changes the setting when the server is connected, the > effect will take place only on reconnection, so I think we can leave it as > it is. > >> >> - In Desktop mode AUTHENTICATION_SOURCES must be '*internal*' doesn't >> matter what mode is provided in *config.py *or* config_local.py*. In >> fact, we should create a flag '*authentication_mode*' which will be >> set after the valid authentication source has been detected/connected. *For >> example,* the user has provided AUTHENTICATION_SOURCES = >> ['kerberos', 'internal'], it is unable to connect using kerberos and then >> the user has provided a valid email and password so we will set ' >> *authentication_mode*' to 'internal' and the rest of the logic will >> be based on that flag. >> >> This was already taken care of. > >> >> - >> >> >> - Connect to any database server and check backend logs following >> error is visible: >> - KeyError: 'KRB5CCNAME' *Solution*: It should not call >> "kerberos_validate_ticket()" function until AUTHENTICATION_SOURCES is >> 'kerberos' and Server Mode is true. >> >> Fixed. > > >> *AUTHENTICATION_SOURCES = ['kerberos']:* >> >> - Kerberos is not set up: Open pgAdmin page, enter email and password >> two message box popped up one with valid Kerberos error and the second one >> with "None" as a string. >> >> Fixed > >> >> - Similarly, if AUTHENTICATION_SOURCES = ['kerberos', 'internal'] and >> it is failed to connect using kerberos, then provide an email, and the >> wrong password two message boxes popped up one with Kerberos error and >> another with Password error. >> >> Somehow, I couldn't find the fix for this issue, for now we can ignore > this as this will not affect the login process. > >> >> - In the User Management dialog 'kerberos' should not be visible in >> the authentication source dropdown. As there is no point creating kerberos >> user from there. >> >> We have provided an option to add manual users for Kerberos also the same > as LDAP. > >> >> - Add local server(without kerberos) to the browser tree, set >> "Kerberos Authentication?" to True, try to connect by providing the >> password it always returns "fe_sendauth: no password supplied" error. If >> possible can we identify and change the error message? >> >> Fixed > >> >> - Add database server where kerberos authentication is ON, make >> changes in pg_hba.conf with the wrong user name, then try to connect to the >> database server. The server tries to connect and the spinner is visible and >> never stops. It should raise a proper error message. There are some other >> scenarios where entries in pg_hba.conf is wrong. >> >> Fixed > >> >> - *Suggestion 1*: As per current implementation even if "Kerberos >> Authentication?" is set to false the user can connect to the database >> server by providing any password or blank password. It is difficult for the >> user to identify it is connected using GSSAPI. I would suggest providing >> the control in the properties dialog which tells the database server is >> connected using GSSAPI. >> >> I have removed the old implementation in which the user was able to > connect the PostgresQL even if a user has not selected "Kerberos > Authentication" but we have a valid kerberos ticket and pg_hba is > configured to support it. So, now users can get the idea about the > connection through The "Kerberos authentication" flag displayed on the > properties tab. > >> >> - *Suggestion 2*: If it is possible to detect that the database >> server is connected using Kerberos then we should disable the 'Username' >> control as for Kerberos both the users (pgadmin user and database user ) >> must be the same. >> >> >> *Note:- *pgAdmin on OSX not working with Kerberos authentication. Failed >> with error "Your GSSAPI implementation does not have support for >> manipulating credential stores directly" Need to document this behavior. >> > > Thanks, > khushboo > >> >> *Code review still remains, which I'll be started after the above fixes.* >> >> On Wed, Apr 14, 2021 at 2:06 PM Khushboo Vashi < >> khushboo.vashi@enterprisedb.com> wrote: >> >>> Hi, >>> >>> Please find the attached patch with some minor improvements. >>> >>> Thanks, >>> Khushboo >>> >>> On Wed, Apr 7, 2021 at 11:50 PM Khushboo Vashi < >>> khushboo.vashi@enterprisedb.com> wrote: >>> >>>> Hi, >>>> >>>> Please find the attached patch for RM 6158: Support Kerberos >>>> Authentication - Phase 2. >>>> This patch includes the support for logging into PostgreSQL servers >>>> with Kerberos authentication. >>>> >>>> Thanks, >>>> Khushboo >>>> >>>> >> >> -- >> *Thanks & Regards* >> *Akshay Joshi* >> *pgAdmin Hacker | Principal Software Architect* >> *EDB Postgres * >> >> *Mobile: +91 976-788-8246* >> > -- *Thanks & Regards* *Akshay Joshi* *pgAdmin Hacker | Principal Software Architect* *EDB Postgres * *Mobile: +91 976-788-8246* --000000000000d8131805c16a9ce4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, patch applied.

On Mon, May 3, 2021 at 2:50 PM Khush= boo Vashi <khushboo.v= ashi@enterprisedb.com> wrote:
Hi Akshay,

<= /div>
Please find the attached updated patch.

= Thanks,
Khushboo

On Mon, Apr 26, 2021 at 12:42 PM Akshay Jos= hi <a= kshay.joshi@enterprisedb.com> wrote:
Hi Khushboo

<= /font>
I have applied your patch= and started testing it in different scenarios.=C2=A0Following are the GUI review comments:=
  • Update the comments abo= ut Kerberos support for=C2=A0AUTHENTICATIO= N_SOURCES in=C2=A0config.py.
Done.=C2=A0
<= div dir=3D"ltr">
  • You will have= to create a migration=C2=A0file again. Getting "Error: Multipl= e head revisions are present for given argument"
=
Done.=C2=A0
  • Increase the height of the server = dialog as after adding=C2=A0"Kerberos Authentication?" switch Con= nection tab showing scroll bars.
Thi= s is the default behaviour of all the dialogues, for example: Table Advance= d tab=C2=A0
  • Desktop/Server mode Getting No such file or directory: '/v= ar/lib/pgadmin/krbccache'.=C2=A0KERBEROS_CCACHE_DIR should only be created in Server Mode and AUTHENTICATI= ON_SOURCES is 'kerberos'.
Done=C2=A0
  • Server Dialog "Kerberos Authentication?" = switch control should be enabled only in Server Mode and=C2=A0AUTHENTICATION_SOURCES is 'kerberos'.
Done=C2=A0
  • "Kerberos Authentication?" switch= should be disabled when the server is connected.
Even if the user changes the setting when the server is conne= cted, the effect will take place only on reconnection, so I think we can le= ave it as it is.=C2=A0
  • In Desktop mode=C2=A0AUTHENTICATION_SOURCES must= be 'internal' doesn't matter what mode is provided in <= b>config.py or config_local.py. In fact, we should create a flag= 'authentication_mode' which will be set after the valid aut= hentication source has been detected/connected. For example,=C2=A0th= e user has provided=C2=A0 AUTHENTICATION_SOURCES =3D ['kerberos', &= #39;internal'], it is unable to connect using kerberos and then the use= r has provided a valid email and password so we will set 'authentica= tion_mode'=C2=A0to 'internal' and the rest of the logic wil= l be based on that flag.
This wa= s already taken care of.=C2=A0
  • Connect to any data= base server and check backend logs following error is visible:
    • <= ul>
  • KeyError: 'KRB5CCNAME'=C2= =A0=C2=A0Solution:=C2=A0It should not call "kerberos_validate_ticket()"= function until=C2=A0AUTHENTICATION_SOURCES is 'kerberos' and Serve= r Mode is true.
Fixed.= =C2=A0
=C2=A0
AUTHENTICATION_SOURCES =3D ['kerberos'= ]:
  • Kerberos is not set up: Open pgAdmin page= , enter email and password two message box popped up one with valid Kerbero= s error and the second one with "None" as a string.
Fixed=C2=A0
  • Similarly, if=C2= =A0AUTHENTICATION_SOURCES =3D ['kerberos', 'internal'] and = it is failed to connect using kerberos, then provide an email, and the wron= g password two message boxes popped up one with Kerberos error and another = with Password error.
Somehow, = I couldn't find the fix for this issue, for now we can ignore this as t= his will not affect the login process.=C2=A0
  • In the User Man= agement dialog 'kerberos' should not be visible in the authenticati= on source dropdown. As there is no point creating kerberos user from there.=
We have provided an option to= add manual users for Kerberos also the same as LDAP.
  • Add lo= cal server(without kerberos) to the browser tree, set "Kerberos Authen= tication?" to True, try to connect by providing the password it always= returns "fe_sendauth: no password supplied" error. If possible c= an we identify and change the error message?
Fixed=C2=A0
  • Add database server where kerbero= s authentication is ON, make changes in pg_hba.conf with the wrong user nam= e, then try to connect to the database server. The server tries to connect = and the spinner is visible and never stops. It should raise a proper error = message. There=C2=A0are some other scenarios where entries in pg_hba.conf i= s wrong.
Fixed=C2=A0
  • Suggestion 1: As per current implementation even if=C2=A0=C2= =A0"Kerberos Authentication?" is set to false the user can connec= t to the database server by providing any password or blank password. It is= difficult for the user to identify it is connected using GSSAPI. I would s= uggest providing the control in the properties dialog which=C2=A0tells the = database server is connected using GSSAPI.
    • I have removed the old implementation in which the user was ab= le to connect the PostgresQL even if a user has not selected "Kerberos= Authentication" but we=C2=A0have a valid kerberos ticket and pg_hba i= s configured to support it. So, now users=C2=A0can get the idea about the c= onnection through The "Kerberos authentication" flag displayed on= the properties=C2=A0tab.
    • Suggestion 2: If it is poss= ible to detect that the database server is connected using Kerberos then we= should disable the 'Username' control as for Kerberos both the use= rs (pgadmin user and database user ) must be the same.=C2=A0

    Note:- pgAdmin on=C2=A0OSX not working with Ker= beros authentication. Failed with error "Your GSSAPI implementation do= es not have support for manipulating credential stores directly" Need = to document this behavior.

    Thanks,
    khushboo=C2=A0

    Code review still re= mains, which I'll be started after the above fixes.
    =
    On Wed= , Apr 14, 2021 at 2:06 PM Khushboo Vashi <khushboo.vashi@enterprisedb.com&= gt; wrote:
    Hi,

    Please find the attached patc= h with some minor improvements.

    Thanks,
    = Khushboo

    On Wed, Apr 7, 2021 at 11:50 PM Khushboo Vashi <khushboo.vas= hi@enterprisedb.com> wrote:
    Hi,

    Please find the = attached=C2=A0patch for RM 6158: Support Kerberos Authentication - Phase 2.=
    This patch includes the support for logging into PostgreSQL serv= ers with Kerberos authentication.

    Thanks,
    Khushboo



    --
    Thank= s & Regards
    Akshay Joshi
    pgAdmin Hacker | Principal Softw= are Architect
    EDB Po= stgres
    Mobile: +91 976-788-8246



    --
    Thanks & Regards
    Akshay Joshi
    pgAdmi= n Hacker | Principal Software Architect
    EDB Postgres
    Mobile: +91 976-788-8246

    --000000000000d8131805c16a9ce4--