You have no account on SonarQube. (Using SCIM with AzureAD)

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    A: Version 10.1.0
  • how is SonarQube deployed: zip, Docker, Helm
    A: On VM (zip)
  • what are you trying to achieve
    A: Grant external users access to sonarqube via SAML authentication.
  • what have you tried so far to achieve this
    A: Set up SCIM, SAML according to the sonarqube official docs.

We have successfully setup SCIM to sync Groups from Azure to Sonarqube, however for some strange reason external users are unable to login.
We have followed the sonarqube docs and as mentioned the provision seems to work.

I can see the users and groups both in sonarqube and azure, however some external users with a different domain get the following error message when logging in:

{'login': 'USER', 'name': 'first second', 'active': True, 'email': 'USER@XMICROSOFT.COM', 'groups': [ 'sonar-users'], 'tokensCount': 0, 'local': False, 'externalIdentity': ''USER@XMICROSOFT.COM', 'externalProvider': 'saml', 'avatar': 'XXXXXXXXXXXX, 'lastConnectionDate': '2023-03-29T11:58:02+0000', 'managed': True},

Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!

Hi,

Do these users exist in Azure?

 
Ann

Yes, the user exist in Azure.

Here is an example with another user:
In the SCIM provisioning logs, we see a lot of failures, too:
Investigating with the Sonarqube logs, the error is:
“2023.08.07 13:52:54 INFO web[AYnE4+ZWth8NkIqdAfu5][com.A.C.B.E] Error while processing request: Email ‘BLA@BLUBB.DE’ is already used”

As said, the user exists in Azure AD and in Sonarqube:

  {
            "login": "bla-blubb-de123",
            "name": "Bla Blubb (BLA@BLUBB.DE)",
            "active": true,
            "email": "BLA@BLUBB.DE",
            "groups": [
                "A",
                "B",
                "C",
                "sonar-users"
            ],
            "tokensCount": 0,
            "local": false,
            "externalIdentity": "bla@blubb.de",
            "externalProvider": "saml",
            "avatar": "xxx",
            "lastConnectionDate": "2023-07-27T15:00:55+0000",
            "managed": false
        }

But when the user logs into sonarqube, the same error (you have no account on SonarQube) is shown.

I am wondering why this user has a “managed”: false flag and shown as a local user in the UI although the user should be managed by SCIM/SAML.

How could this issue be resolved?
Thank you,
Thomas

1 Like

Hi Thomas,

Thanks for the confirmation. I’ve flagged this for the experts.

 
Ann

2 Likes

Hi @Thomas_Abbe,

Thank you for your report.

Could you switch the Web server log level to debug (see doc) and send us the full stacktrace?

Currently, I suspect that the username send via SCIM by Azure does not match the one registered in SonarQube. One of the potential reason would be that the mapping defined in Attribute Mapping screen of the provisioning section in your Azure Enterprise Application is not correct for the user name. Please make sure to follow point 6.c of the SonarQube SCIM/Azure doc.

Also, can you confirm that it works for the majority of users (they are both able to login and displayed as non-local)? and that only users from a different domain can’t login (and are flagged as local)?

Hi @aurelien.poscia,

Problem:

In step 2 of the attributes and claims (see doc), the SAML user login attribute* refers to …/claims/emailaddress. We tried to match the configuration described in the officals docs however the SAML user login attribute cannot be set to …/claims/emailaddress (see below):

Workaround:

Instead sonarqube insists to use …/claims/name. By adjusting the attributes & Claims in our Azure Enterprise app we managed to get it to work (could be added to the sonarqube documentation to make things more transparent).

Additional info:

One more problem we’ve encoutered we’d like to sure…

Sonarqube requires a givenname and a surname in order for users to be synced via scim. Now that we manage technical users via Azure AD, we had previously created Azure AD technical users that were trying to be synced. Due to the fact that these users were created before the attribute mappings, their given names and surnames did not exist and the sync was failing.

Using expressions, we successfully synchronized older technical users, who lacked specific properties that scim required in order to be synced:

Hope this post helps others who may experience similar issues.
@Thomas_Abbe if you have more info, feel free to elaborate :slight_smile:

Kind regards
Kadir

Thanks a lot @kislow

We will update the docs since our instructions are incorrect.

1 Like

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