Re: Regarding #8580

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Dave Page <[email protected]>
To: Akshay Joshi <[email protected]>
Cc: Khushboo Vashi <[email protected]>
Cc: pgadmin-hackers <[email protected]>
Subject: Re: Regarding #8580
Date: Tue, 13 May 2025 07:08:06 -0400
Message-ID: <CA+OCxoz8Tmo+xHaM1HLknZPr8QvuVXE6UhQZMN_9oq0rBREf+A@mail.gmail.com> (raw)
In-Reply-To: <CANxoLDdmNbnXYT8xB+6JTzrBkYUmDoncLMo5TrzCyGXJNqxBuQ@mail.gmail.com>
References: <CANxoLDcQQbHcWJi3V7ENyysQ8JoCSoVD47Z+UJMTpF3b=PAp6g@mail.gmail.com>
	<CA+OCxox5DM_OaCa7MJYFYzc4BVmh9SCg_=s9jWLTmLUvWFzG+g@mail.gmail.com>
	<CAFOhELcvwq05pWf9zZD7RPOCmjdPXXevWfdwp7aMk6dXG2am6g@mail.gmail.com>
	<CA+OCxozvoCo2f6XqOJxiw9Hwq7EK1MO431udfDF8PsHngicdWw@mail.gmail.com>
	<CANxoLDdOEu_GFaCwarprfAiVQFtm02Q20Fdb5=--Xr3BTB=uPQ@mail.gmail.com>
	<CA+OCxow=rwY_2YRg05qTzvFqqSskq9Xcp7NapEPMu0kFWFBOPw@mail.gmail.com>
	<CANxoLDd=-vV-_qc4N1q4AFz1QbQ66m_Q8mBxVY4xuWkEasYF5A@mail.gmail.com>
	<CA+OCxozpzppfn9hJky9FvvfG89=r+ZV7Ui85H+ntESAcG0i8og@mail.gmail.com>
	<CANxoLDdmNbnXYT8xB+6JTzrBkYUmDoncLMo5TrzCyGXJNqxBuQ@mail.gmail.com>

Hi

On Mon, 12 May 2025 at 03:07, Akshay Joshi <[email protected]>
wrote:

> Hi Dave/Hackers,
>
> We found another scenario during testing. I know these cases can be
> tricky, but they’re valid. For example, if the auth sources are set to ['ldap',
> 'internal'] and there's both an LDAP and internal user with the same
> email (e.g., "[email protected]").
>
> If the LDAP user tries to log in but forgets the password, the system
> first checks LDAP, then internal. Since the internal login also fails, the
> error shown is for the internal user, not LDAP. This can confuse users.
>
I'm not sure how it would confuse users; "Incorrect username or password"
applies in both cases - and we shouldn't be exposing information about
which authentication methods were attempted and subsequently failed anyway,
as that leaks information that could be useful to an attacker.


> To avoid this kind of confusion, it might be better to add a separate
> 'Login with LDAP' button on the login page (Please refer to the attached
> screenshot). This way, users can choose the right option directly.
>
> On Fri, May 9, 2025 at 6:31 PM Dave Page <[email protected]> wrote:
>
>>
>>
>> On Fri, 9 May 2025 at 12:48, Akshay Joshi <[email protected]>
>> wrote:
>>
>>>
>>>
>>> On Fri, May 9, 2025 at 4:50 PM Dave Page <[email protected]> wrote:
>>>
>>>>
>>>>
>>>> On Fri, 9 May 2025 at 12:14, Akshay Joshi <
>>>> [email protected]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, May 9, 2025 at 4:20 PM Dave Page <[email protected]> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, 9 May 2025 at 11:34, Khushboo Vashi <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, May 9, 2025 at 3:23 PM Dave Page <[email protected]> wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> On Fri, 9 May 2025 at 08:45, Akshay Joshi <
>>>>>>>> [email protected]> 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 [email protected] 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.=
>>>>>>>
>>>>>>
>>>>>> I think that's reasonable, but *only* in that case where there's
>>>>>> another source already present in the DB.
>>>>>>
>>>>>
>>>>>   In that case, the core issue remains unresolved. As mentioned
>>>>> earlier, the system checks internal authentication first (based on the
>>>>> configured order), and then attempts LDAP if the user exists. However, it
>>>>> consistently returns an error for LDAP, and the account is never locked
>>>>> even after exceeding the maximum number of login attempts.
>>>>>
>>>>
>>>> So, just lock all matching accounts.
>>>>
>>>
>>>     One more scenario I just thought of with 'Auto Create User'. Suppose
>>> that [email protected] exists as an internal user in the database, but there is
>>> no corresponding LDAP entry. When the user attempts to log in with an
>>> incorrect password, the system checks the database for entries from other
>>> authentication sources and throws an error. In this case, the 'Auto Create
>>> User' functionality will not be triggered.
>>>
>>>     I think we can either keep the current behavior as it is and close
>>> the issue (since I reported it), or add a rule with documentation saying
>>> that login should follow the order of the authentication sources. In most
>>> cases, users who prefer LDAP can just set the auth source to ['ldap',
>>> 'internal'], which should work fine.
>>>
>>
>> Right, I believe that would be the typical case.
>>
>> --
>> Dave Page
>> pgAdmin: https://www.pgadmin.org
>> PostgreSQL: https://www.postgresql.org
>> pgEdge: https://www.pgedge.com
>>
>>

-- 
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
pgEdge: https://www.pgedge.com

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Regarding #8580
  In-Reply-To: <CA+OCxoz8Tmo+xHaM1HLknZPr8QvuVXE6UhQZMN_9oq0rBREf+A@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox