LDAP authentification with multiple attributes cause Email... is already used

On SonarQube 9.9, with LDAP as the authentication provider.

Standard logins (with uid) work well, including the group mapping.

Recently, we have added the mail attribute as possible login.
Ldap configuration : ldap.user.request=(&(|(objectClass=posixAccount)(objectClass=inetOrgPerson))(|(uid={login})(mail={login})))

For new users, the authentification works well for mail or uid when they always use the same attribute as login : mail or uid

For previously authenticated users, the authentication accepts only the previous user’s login attribute, otherwise the authentication fails with the following error:

  • Either: [auth.event] login failure [cause|Email '...@...' is already used][method|FORM][provider|ldap][IP|127.0.0.1|][login|...@...]

  • Or: [auth.event] login failure [cause|Email '...@...' is already used][method|FORM][provider|ldap][IP|127.0.0.1|][login|my_user_login]

Explanation:

  1. User1 first logs in with his/her uid = user1

  2. Authentication succeeds, the user is provisioned in SonarQube with the internal id LDAP_default: user1, and the resolved mail is user1@sample.com

  3. User1 logs out

  4. User1 logs in again with his/her mail = user1@sample.com

  5. SonarQube executes the LDAP Search (success) for users, details, and the groups.

  6. SonarQube checks the duplicate mail and raises the above error.

I understand the need for duplicate email across différent providers or even the same Realm provider, however, for this case, the resolved user is exactly the same. No real users have the same email in this case.

SonarQube makes the duplicate decision based on mail and login.

Yes, the typed logins in the form are different: user1 vs user1@sample.com.

No, the internal provider user’s ids are not different, same resolved DN: uid=user1,dc=sample,dc=com

How to fix this issue? :

  • Either use the internal provider id to confirm the Email duplicate (DN for LDAP). The current implementation does not store this information, but it could on the next login.

  • Or use the internal provider logical id (RDN of LDAP Object class: uid or sAMAccountName) to confirm the Email duplicate. This attribute does not exist for now in LDAP provider. When this optional attribute is not provided, SonarQube executes the same implementation. Otherwise, when the email matches, add another comparison using this attribute value to build LDAP_default: $rdn. Therefore, LDAP_default: user1 will be consistent regardless of the way the user was authenticated.

Hi,

Welcome to the community!

We’re simply not set up for this. We take the identity as it’s written in the login form when authenticating via LDAP, not the resolved identity.

 
HTH,
Ann