User Mapping Problems in v2 Snapshot

[srvrguy]

after trying the this snapshot I get an error that the email-address is already used by another user. so it looks like the user mapping fails and it want to create a new one. has there something changed here?

Originally posted by @OneCyrus in https://github.com/hkamel/sonar-auth-aad/issues/120#issuecomment-1363016597

[srvrguy]

Due to changes in data provided by the v2 endpoints, the user account building is a bit different than that done in the v1 code. Additionally, due to deprecations in SonarQube API, the login generation selection is not supported.

First, the SonarQube change. As of version 8.0, the user login is considered an internally-managed field. No matter what "loginStrategy" was set to, the plugin setting would be ignored. You can find a bit more details in the code comments for the SonarQube API.

As for the MS changes, some of the fields the v1 plugin was using are not present in the v2 tokens. As a result, I had to make some changes that should give the same results, primarily, but may be different in some cases. As the API comments above note, the user is matched based on the "provider login" value.

To figure out what's going on, I'll need to know how the existing v1 user provider login looks in the SQ database, and what the new plugin version is trying to set for the same fields. If this is a non-critical user, you can try to change their existing SQ account to a different e-mail address, log the user in, and then compare the database fields for each user. Then, you can let me know what's different about the user entries. Hopefully, I can then find if the old value is presented somewhere and use that as the primary choice for the value.

[OneCyrus]

just made some tests and verified with manual changes in the database. with the v2 plugin it fails because of case sensitivity. the filed external_login in the database was all lower case and it needed to be changed to the specific case with initial uppercase characters. after that it matched the same user identity again.

probably the best way would be to move to a case insensitive comparison or make everything lowercase.

also verified the external_id field which doesn't look to be case sensitive.

[srvrguy]

That makes sense. The matching is within SonarQube itself, so I can't control that portion being case-sensitive. I could just force the external login data to all lowercase, but I worry that might cause other kinds of trouble. I'll have to give this some thought. Ultimately, there may be no way that will guarantee 100% compatibility.

[srvrguy]

Looking at the MS docs, sample token outputs, and the ADAL4J code, I'm 90% certain that the values for "provider login" were always lowercase. As such, I've now forced the values to always be lowercase. If all goes well, I'll likely put out a beta in the next week.

[vittoriocanilli]

Any update on this topic?

[srvrguy]

I'm still planning a proper release soon but have not had the time to do so.

[thoabbe]

Hi, do you have any update?

Some users cannot log in via SAML (Azure AD) with Message (entry in weblogs): 2023.04.26 09:41:31 ERROR web[AYeoIHTZuo4b7DvbBhMB][o.a.a.a.AadIdentityProvider] Exception:org.sonar.server.authentication.event.AuthenticationException: Email ‘xxx’ is already used

The /api/users/search api returns following user

   {
        "login": "x-y21466",
        "name": "X Y",
        "active": true,
        "email": "xxx@yyy.com",
        "groups": [
            "sonar-admins",
            "sonar-users"
        ],
        "tokensCount": 0,
        "local": false,
        "externalIdentity": "xxx@yyy.com",
        "externalProvider": "aad",
        "avatar": "4a34614ae2045a9b7a93fba8795bb588",
        "lastConnectionDate": "2023-03-22T12:53:11+0000"
    }

Our case might be related with this issue since all concerned email addresses have upper AND lowercase letters.

Thank you Thomas

SonarQube Enterprise Version: 9.9 (build 65466) Azure Active Directory (AAD) Authentication Plug-in for SonarQube INTEGRATION: 2.0.0