Azure AD SCIM/SAML issues with SonarQube Enterprise

SonarQube Server / Community Build
,
1

Must-share information (formatted with Markdown):

  • which versions are you using: SonarQube Server v10.6 (92116) (I know, I know, trying to schedule an upgrade, will probably switch to the 2025 LTA)
  • how is SonarQube deployed: zip
  • what are you trying to achieve: Some of our users are unable to log in. We suspect this is a casing issue.
  • what have you tried so far to achieve this:

We are attempting to solve our user login issues by setting the username/email address ToLower case in the SCIM provisioning and in the SAML claim. We made the configuration changes in SCIM but after forcing a re-sync, the email addresses are not changing in SonarQube. Do you have any suggestions on how we can force the username/email to update? Any logs that could be provided to help us discover why they are not updating?

image
image1500×662 28.9 KB

Thanks

2

Hey @stumt!

I think your issue should actually be fixed by an upgrade – while the ticket might not spell it out, SONAR-23012 was created after another customer reported similar behavior (e-mail not being updated on SonarQube when updated in Entra)

If you’re waiting for the LTA… it’s coming so soon that the docs are already published (so are the docker images). Check back later this week!

3

Hi @Colin!

Thank you for the prompt reply. That does sound like the culprit. I will work with my team to plan the upgrade to the 2025 LTA after it is available.

4

Hi @Colin!

We upgraded to 2025.1 LTA, and are still having some issues with SCIM/SAML. Our SAML configuration was temporarily broken, we think because when we were first trying to set this up back with 10.5 or 10.6 we tried to get the assertion encryption working (unsuccessfully). Despite the sign requests slider being set to off, a certificate must still have been loaded which was causing the SAML to not function. We have cleared those settings out, though, and SAML is functioning once again, sort of (see below).

We reconfigured the SCIM and SAML configuration to apply lower case transformations to the user mail attribute, and those users who already had lower case emails in SonarQube are able to log in. Any user with CamelCased or otherwise not lower case emails are still unable to log in. Restarting provisioning in on the Microsoft side is not updating these accounts in SonarQube with the lower cased values.

What we’re thinking now is that we’re just going to have to bite the bullet and purge these problematic accounts from SonarQube and then restart provisioning again. I verified with a test user that if I remove their account from SonarQube and selectively reprovision that account, it comes over in lower case as desired. I don’t see any options in the web UI for bulk deletion of accounts, so I was going to start looking at the API to see what are our options.

  1. Do you concur that removing the problematic accounts from SonarQube and reprovisioning is likely the best path forward for us?
  2. If yes to #1, do you have any advice for how we can most efficiently remove these accounts from SonarQube?
  3. If no to #1, what would you suggest?

Thanks,
Sean

5

Hey again @stumt!

You should be able to fix this without removing the accounts from SonarQube.

Based on your description I’m not sure in which case an e-mail is

I don’t know exactly how your users are coming through, so I’m not sure which one is best to use, but these APIs should cover all your bases. A simple call to GET api/users/search should make it clear how the e-mail is used and which attribute needs updated.

{
  "paging": {
    "pageIndex": 1,
    "pageSize": 50,
    "total": 1
  },
  "users": [
    {
      "login": "admin",
      "name": "Administrator",
      "active": true,
      "email": "test@test.com",
      "groups": [
        "sonar-administrators",
        "sonar-users"
      ],
      "tokensCount": 9,
      "local": true,
      "externalIdentity": "admin",
      "externalProvider": "sonarqube",
      "avatar": "b642b4217b34b1e8d3bd915fc65c4452",
      "lastConnectionDate": "2025-02-20T14:51:45+0100",
      "managed": false
    }
  ]
}

All of those APIs are deprecated in lieu of PATCH /api/v2/users-management/users/{id}, but I find the PATCH much more complicated than simple POST requests. That being said, it is also an option.

6

Hi @Colin !

Thanks for that advice. I was able to whip up a quick script with the v2 API. PATCH wasn’t that bad with Python requests library; just add a Content-Type header set to application/merge-patch+json, and the json parameter to the patch function with the payload. I updated the email, externalId, and externalLogin fields.

One thing to note is that I had to disable SCIM and SAML while doing this, otherwise the PATCH is rejected. After all the API calls were done, I turned SAML and SCIM back on in SonarQube and restarted SCIM provisioning in Microsoft Entra. All the user accounts have converted back to managed from local. Not sure if I would have had to do this step using the APIs you called out, but no matter it’s all working now.

Thanks,
Sean

7

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.