On Fri, May 9, 2025 at 3:23 PM Dave Page <dp...@pgadmin.org> wrote:
> Hi > > On Fri, 9 May 2025 at 08:45, Akshay Joshi <akshay.jo...@enterprisedb.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...@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’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 > >
