Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uDKQ1-009HwV-8x for pgadmin-hackers@arkaria.postgresql.org; Fri, 09 May 2025 09:53:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uDKPw-00A3ri-Vk for pgadmin-hackers@arkaria.postgresql.org; Fri, 09 May 2025 09:53:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uDKPw-00A3qg-NB for pgadmin-hackers@lists.postgresql.org; Fri, 09 May 2025 09:53:20 +0000 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uDKPt-00106J-2K for pgadmin-hackers@postgresql.org; Fri, 09 May 2025 09:53:20 +0000 Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-30bfe0d2b6dso16533381fa.3 for ; Fri, 09 May 2025 02:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1746784397; x=1747389197; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ohJD8zxm179zUK7kSXOyBOiMTs4maShlbI8NT1POvLY=; b=SGnrS7nZDbhnG8PpkGgnmr7B/waGBCBT/SlwwUz/KL0XwbRLxsLDP+1+MexGNgqjHO 5OuCEJ896E03DDeFdXSOlqugZa793lTBKC+YgZW8Ze8xNorDFxCLTli8cuSgl9IDo/FG eqohz+VtN2Uc7CPy1XoLg50uM50IxbPW3G6DLlt3QIw8iPkoJClpsr1803uMWPZQkPr7 EMqxhICXN5hcIZNI5mqI0sLwWtKkImAQa1OZ7PVlDLAWhxlCCRqxu2icXxhZ9D2nVMWo DCOmMc6MtGvcn2TTFmZiIDmv3/FIPZYPnnzA3kqldQ8OLgTdWDXEh0SgM6+K0M7qrQfp G2Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746784397; x=1747389197; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ohJD8zxm179zUK7kSXOyBOiMTs4maShlbI8NT1POvLY=; b=QjXYnWV55xKWHPnWFQ/XDbWbdUT/y96nsLDTaEPkC7w+YkjzudaEggX5B26V/RaUlZ JFklU1Q/SKRzGk68BZayd52N6dAw0doXnymM6O13ba0NIiGnJEG6PMV2Rw0EOPik4UML Nev7Ijkk1FhILbiocmQXivLrBaN2SVRoQbTz/O1oEGLLtPjURxv8Z1k1PgXn+t9YCsyc fymp2ULha7xHXnhYaSqDFGEs3OFMEtFp3q4XOv423zWLzq3xVz3PUMUZAkFhQanSsQr9 rv3lwfz7zzxwrVma6x0fq7UPE+jj54L1QeP4d3vwc7iAPsLLvJ9bhaZEhQZV++M+EGbS GEIg== X-Gm-Message-State: AOJu0YwDzM9kFZY7wfnkoFv7R5bmcS9x8ysT0AGkassUkyoL+TpCgewl rYrBmjx2X+gpd/e9p3JmvzaIALMLYIWCBrJ2h9KngR94Ear1+QWFYtWW8smiWAgyrG03F+FECC3 U9ZdedXxc39KeAEfZC+sOyDNKkyqLaZRzYUbV X-Gm-Gg: ASbGncvXvfiX0dUCuSwqzNis5WU09YpERyMZmjlEmC43h/H9oD1+Rdca3YMSeUbhk4+ PmXjaEzBbQjgEg3pTNRVKGKFgwkR4I35Vzb+Np7muK3RE+IpEhwI/uiaEm0V+WJxNyi2mQPBuDA zHI9tmYry60m7MPP0vPsLt1h2v X-Google-Smtp-Source: AGHT+IGZzuQzSdhuNMTCdPfms6Ae0WBIyfKUZ1kj1jcy196zPnfU+wox8k7Mw4VZHmohGRZ0NIwnDahV6574kncLAN8= X-Received: by 2002:a2e:9fc5:0:b0:30d:626e:d03a with SMTP id 38308e7fff4ca-326c467d235mr11027031fa.34.1746784396551; Fri, 09 May 2025 02:53:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Fri, 9 May 2025 10:53:05 +0100 X-Gm-Features: ATxdqUEmBGD7qZ9A95kjaaxS9y3j1kQYlAdXkEi6tdoY1hfitlisR2OrTcap4Io Message-ID: Subject: Re: Regarding #8580 To: Akshay Joshi Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary="00000000000074b8f30634b0ef6f" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000074b8f30634b0ef6f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi On Fri, 9 May 2025 at 08:45, Akshay Joshi wrote: > Hi Hackers/Dave, > > I have started working on issue #8580 > , where the correct > error message should be displayed based on the user's authentication sour= ce > when an incorrect password is provided. > > *Actual Issue*: The admin has configured AUTHENTICATION_SOURCES =3D > ['internal', 'ldap']. A user with the email a@xyz.com exists only as an > internal user in the database, and there is no corresponding LDAP entry f= or > 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 err= or > 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=E2=80=99m proposing two po= ssible > 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 o= r > 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 databa= se. > > 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 check= ing > for the next authentication source. > > Yes. > *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 th= e > 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. --=20 Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com --00000000000074b8f30634b0ef6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Fri, 9 May 2025 at 08:45, = Akshay Joshi <akshay.jo= shi@enterprisedb.com> wrote:
Hi Hackers/Dave,

I have started working o= n issue #8580,=C2=A0where the correct error message should be di= splayed based on the user's authentication source when an incorrect pas= sword is provided.

Actual Issue:=C2=A0The a= dmin has configured AUTHENTICATION_SOURCES =3D ['internal', 'ld= ap']. A user with the email a@xyz.com exists only as an internal user in the database, and ther= e is no corresponding LDAP entry for this user. When this user attempts to = log in with an incorrect password, the system first tries internal authenti= cation, which fails. It then proceeds to check the next authentication sour= ce (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=E2=80=99= m proposing two possible solutions to address it:
Solution 1 (= Logic Changes):=C2=A0
Scenario 1: ['internal', = 9;ldap']:
  • If a user exists in the database with t= he specified authentication source (internal), attempt to authenticate usin= g internal. If authentication fails, return an error. No need to check for = the LDAP or next auth source.
Yes.= =C2=A0
  • If no user-a= uth source combination is found for internal, proceed to the next authentic= ation source (LDAP). Attempt LDAP login, and if successful (and auto-create= is enabled), create the user in the database.
Yes.
=C2=A0
Scenario 2: ['ldap', 'internal']=C2=A0
<= ul>
  • If the LDAP user does not exist in=C2=A0the database, but the same= =C2=A0user exists=C2=A0as an internal user, first try LDAP authentication. = If it fails, fall back to internal or the next configured auth source in th= e list.=C2=A0
    • Yes.=C2=A0
    • 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.
      • <= /ul>
    Yes.
    =C2=A0
    Note: -=C2=A0In the above approach, it is t= he administrator's responsibility to configure the order of authenticat= ion sources appropriately.

    Agre= ed.
    =C2=A0

    =
    Solution 2 (GUI Changes):=C2=A0Add a single login button with a= drop-down menu to select the authentication source (e.g., "Internal&q= uot;, "LDAP") on the login page, as we already display N buttons = for N OAuth2 configurations, which can be removed for a cleaner user experi= ence.
    OR=C2=A0
    Alternatively, add a separate button lab= eled "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=C2=A0= the backend authentication. That seems like something they shouldn't ne= ed to concern themselves with.
    =C2=A0
    --
    Dave Page
    PostgreSQL: <= a href=3D"https://www.postgresql.org" target=3D"_blank">https://www.postgre= sql.org
    --00000000000074b8f30634b0ef6f--