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:
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:
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)?
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):
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).
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: