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 1uDIQ8-008sJA-Kq for pgadmin-hackers@arkaria.postgresql.org; Fri, 09 May 2025 07:45:25 +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 1uDIQ7-009Db0-KS for pgadmin-hackers@arkaria.postgresql.org; Fri, 09 May 2025 07:45:23 +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 1uDIQ7-009DaR-Ak for pgadmin-hackers@lists.postgresql.org; Fri, 09 May 2025 07:45:23 +0000 Received: from mail-lf1-x12e.google.com ([2a00:1450:4864:20::12e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uDIQ3-000zFA-0u for pgadmin-hackers@postgresql.org; Fri, 09 May 2025 07:45:22 +0000 Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-54b166fa41bso2198881e87.0 for ; Fri, 09 May 2025 00:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1746776717; x=1747381517; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=ZBlO+TCKEfz/uUMQtiuSg7vybhveuZp1yrFOSog/BxE=; b=fdFWTLzPszchfGVyuj284Wg+R/4VKzEVadx/lSVFJj46Bz1jxbtVQ6gtfkPlA3XUph mCt4y/rj/RrJjPdbx8cSRy6KBGGnkD0Y0f0Z8rcBSbAgkUzSqkVoz1Bz+1alrDh3LLvx 31Qqv6+Y3t8zS0cpSbhv9nWOH2OnPIke6F5yA4ISg98EK4uagbHtzaqyBtaqAa6f9se0 tCklxFPaTTCec2oQE/2hRRSupcF3UKL3AeyHhA9d01FXOWVnLn8DBBlJgNz7uJhGE0bG unCswMW+vNWFYx+4coqFiObX7/4NXc3zebtjo7wSY+9Z5IVqh/Qu2p7uuKiA84taay+X t7pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746776717; x=1747381517; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ZBlO+TCKEfz/uUMQtiuSg7vybhveuZp1yrFOSog/BxE=; b=bgCwlk+y3z8P8+hPQoNRTRjzAQ2EyHdJdZwDLOPsiaQqZ8N5Mt1qcF6qjCI2O0jLVa Xfoev3HxdGtFTJ21ijd+heO4oLC+yXHWo1IiuN/ZJj5fj6DPqRLY5WQHoa3GkHk4oVrg F7Pkkf5/D1x9Bl4/0+UQ4zODggLWYTTzy5dg/XqgRLzdH7DTI7DzIQqNGa7vxwbN+xd4 DbwHpP6r/+SfGque5KIAqqZR01XSxROdBbQPGr62ss/ejNrEZRZzimYkawoZqTD5H9Ai ZtdzOHif8W/AL1M2+vfunN/4PuqLK+Lu1SFiPvgK1K6Wk6lEjsZoiwghX7gTTQUuZ/WM hLPw== X-Gm-Message-State: AOJu0YxpTbPYd8q/rjiU2ARcAGgRKTwX3th86Ckxlcsa5s+Sfsn3321N GTZwRLF28/nfMDshtohu9EelWHobxcDvm8+iN8kezi/bK/r0yZTJGRBtv1Itf5FE7stT15cpZy/ 1OESM4wGCnR+lahhU10mbkYs9+jcoScjZ1mW6RuCacTvQSUIfZg== X-Gm-Gg: ASbGncvdQ+AtUwb9y9+Nj+4LVrxZnDcsgWKPgb4W6dVCPYV4jzA4sNdh+D99W4amopW DaAYKRAm86tsq89aYoqdkE7rs6wp1BYQssSpH0EAPZ523K2rft1/bDERbLDdLv92LJ6Ss1oQxtV UXbSd9KAQTGMYhdtONllIHkhDCjKvWRr5Tg6L8tEjzW7W6nSELieQ+QA== X-Google-Smtp-Source: AGHT+IHM5H9jtpSFbYBHv5X8KDsfZWj7KZcRP2aF6JpoBqt6yj8qjDhtwG77lTAnHwvY9QfDUyo5gqs6yEgiBMuGui8= X-Received: by 2002:a05:6512:10ca:b0:54e:85bc:d151 with SMTP id 2adb3069b0e04-54fc67e6065mr744129e87.46.1746776716890; Fri, 09 May 2025 00:45:16 -0700 (PDT) MIME-Version: 1.0 From: Akshay Joshi Date: Fri, 9 May 2025 13:15:05 +0530 X-Gm-Features: AX0GCFuKVqalbKMQIJimo8RWJComsr729tE5gNQVG9NUpp3iknkInd00UD6soNs Message-ID: Subject: Regarding #8580 To: pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000b67b850634af25a4" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000b67b850634af25a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Hackers/Dave, I have started working on issue #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 =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 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=E2=80=99m proposing two poss= ible 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. - 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= . *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. - If the LDAP user does exist in the database, attempt to authenticate via LDAP. If LDAP authentication fails, return the error without checkin= g for the next authentication source. *Note:* - In the above approach, it is the administrator's responsibility to configure the order of authentication sources appropriately. *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. Need your inputs/suggestions on this. Akshay Joshi Principal Engineer | Engineering Manager | pgAdmin Hacker enterprisedb.com * Blog*: https://www.enterprisedb.com/akshay-joshi * GitHub*: https://github.com/akshay-joshi * LinkedIn*: https:// www.linkedin.com/in/akshay-joshi-a9317b14 --000000000000b67b850634af25a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hackers/Dave,

I have star= ted working on issue #8580,=C2=A0where the correct error message should be display= ed based on the user's authentication source when an incorrect password= is provided.

Actual Issue:=C2=A0The admin = has configured AUTHENTICATION_SOURCES =3D ['internal', 'ldap= 9;]. A user with the email a@xyz.com exist= s only as an internal user in the database, and there is no corresponding L= DAP entry for this user. When this user attempts to log in with an incorrec= t password, the system first tries internal authentication, which fails. It= then proceeds to check the next authentication source (LDAP), as per the c= onfigured logic. Since no matching LDAP user exists, an LDAP-related error = is returned, even though the user is intended to be authenticated only inte= rnally. His/her account will never get locked.

Thi= s behavior appears to be incorrect to me. I=E2=80=99m proposing two possibl= e solutions to address it:
Solution 1 (Logic Changes):=C2=A0
Scenario 1: ['internal', 'ldap']:
=
  • If a user exists in the database with the specified authentica= tion source (internal), attempt to authenticate using internal. If authenti= cation fails, return an error. No need to check for the LDAP or next auth s= ource.
  • If no user-auth source combination is found for internal, pr= oceed to the next authentication source (LDAP). Attempt LDAP login, and if = successful (and auto-create is enabled), create the user in the database.
Scenario 2: ['ldap', 'internal']= =C2=A0
  • If the LDAP user does not exist in=C2=A0the databa= se, 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 a= uth source in the list.=C2=A0
  • If the LDAP user does exist in the da= tabase, attempt to authenticate via LDAP. If LDAP authentication fails, ret= urn the error without checking for the next authentication source.
Note: -=C2=A0In the above approach, it is the administra= tor's responsibility to configure the order of authentication sources a= ppropriately.

Solution 2 (GUI Changes):=C2=A0Add a single login button with a drop-down menu to select the authenticat= ion 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=C2=A0
Altern= atively, add a separate button labeled "Login with LDAP" to expli= citly trigger LDAP authentication.

Need your input= s/suggestions on this.


=
<= colgroup>
=C2=A0 Blog: https://www.enterprisedb.com/akshay-joshi
=C2=A0 GitHub: https://github.com/akshay-joshi
=C2=A0 LinkedIn: <= a href=3D"http://goog_373708537" target=3D"_blank">https://www.linkedin.com/in/akshay-= joshi-a9317b14
--000000000000b67b850634af25a4--

Akshay Joshi

<= p dir=3D"ltr" style=3D"line-height:1.2;margin-top:0pt;margin-bottom:0pt">Principal En= gineer | Engineering Manager | pgAdmin Hacker

enterprisedb.com