From: | Khushboo Vashi <khushboo(dot)vashi(at)enterprisedb(dot)com> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org> |
Cc: | Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org> |
Subject: | Re: Regarding #8580 |
Date: | 2025-05-09 10:33:50 |
Message-ID: | CAFOhELcvwq05pWf9zZD7RPOCmjdPXXevWfdwp7aMk6dXG2am6g@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
On Fri, May 9, 2025 at 3:23 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
> Hi
>
> On Fri, 9 May 2025 at 08:45, Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com>
> wrote:
>
>> Hi Hackers/Dave,
>>
>> I have started working on issue #8580
>> <https://github.com/pgadmin-org/pgadmin4/issues/8580>, where the correct
>> error message should be displayed based on the user's authentication source
>> when an incorrect password is provided.
>>
>> *Actual Issue*: The admin has configured AUTHENTICATION_SOURCES =
>> ['internal', 'ldap']. A user with the email a(at)xyz(dot)com exists only as an
>> internal user in the database, and there is no corresponding LDAP entry for
>> this user. When this user attempts to log in with an incorrect password,
>> the system first tries internal authentication, which fails. It then
>> proceeds to check the next authentication source (LDAP), as per the
>> configured logic. Since no matching LDAP user exists, an LDAP-related error
>> is returned, even though the user is intended to be authenticated only
>> internally. His/her account will never get locked.
>>
>> This behavior appears to be incorrect to me. I’m proposing two possible
>> solutions to address it:
>> *Solution 1 (Logic Changes): *
>> *Scenario 1: ['internal', 'ldap']:*
>>
>> - If a user exists in the database with the specified authentication
>> source (internal), attempt to authenticate using internal. If
>> authentication fails, return an error. No need to check for the LDAP or
>> next auth source.
>>
>> Yes.
>
>>
>> - If no user-auth source combination is found for internal, proceed
>> to the next authentication source (LDAP). Attempt LDAP login, and if
>> successful (and auto-create is enabled), create the user in the database.
>>
>> Yes.
>
>
>> *Scenario 2: ['ldap', 'internal']*
>>
>> - If the LDAP user does not exist in the database, but the same user
>> exists as an internal user, first try LDAP authentication. If it fails,
>> fall back to internal or the next configured auth source in the list.
>>
>> Yes.
>
>>
>> - If the LDAP user does exist in the database, attempt to
>> authenticate via LDAP. If LDAP authentication fails, return the error
>> without checking for the next authentication source.
>>
>> Yes.
>
If the user is registered for multiple authentications (per entries in our
database), the next in line should be checked if one fails.
>
>> *Note:* - In the above approach, it is the administrator's
>> responsibility to configure the order of authentication sources
>> appropriately.
>>
>
> Agreed.
>
>
>>
>> *Solution 2 (GUI Changes): *Add a single login button with a drop-down
>> menu to select the authentication source (e.g., "Internal", "LDAP") on the
>> login page, as we already display N buttons for N OAuth2 configurations,
>> which can be removed for a cleaner user experience.
>> OR
>> Alternatively, add a separate button labeled "Login with LDAP" to
>> explicitly trigger LDAP authentication.
>>
>
> I don't like this solution, as it requires the end user to understand how
> their admin has setup the backend authentication. That seems like something
> they shouldn't need to concern themselves with.
>
> --
> Dave Page
> pgAdmin: https://www.pgadmin.org
> PostgreSQL: https://www.postgresql.org
> pgEdge: https://www.pgedge.com
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2025-05-09 10:49:56 | Re: Regarding #8580 |
Previous Message | Dave Page | 2025-05-09 09:53:05 | Re: Regarding #8580 |