Re: [pgAdmin4][Patch] - RM 6158 - Logging into PostgreSQL servers with Kerberos Authentication

Hi Akshay,

Please find the attached updated patch.

Thanks,
Khushboo

On Mon, Apr 26, 2021 at 12:42 PM Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)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(dot)vashi(at)enterprisedb(dot)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(dot)vashi(at)enterprisedb(dot)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 <http://edbpostgres.com>*
>
> *Mobile: +91 976-788-8246*
>