Version: Enterprise Edition - Version 10.2.1 (build 78527)
How is SonarQube deployed: Docker
User Sync with a GitHub EMU instance
Just that, user Sync with a GitHub EMU instance which works fine until we hit a bug
Hi,
we have encountered a somewhat serious issue with the SonarQube user sync when using a GitHub EMU instance as the SSO provider.
How to reproduce:
• We have a user with a mail address, let’s say foo@bar.com and added them to the AD Group which is connected to our GitHub EMU instance.
• This user gets synced to out GitHub EMU instance as foo_emutag where the emutag is defined by our GitHub enterprise.
• This user in turn gets synced to SonarQube as foo_emutag with the mail address foo@bar.com.
• That user’s mail changed from foo@bar.com to foo@bar.de.
• We removed the .com account from the AD group and added .de one.
• The user now gets synced to GitHub as foo_emutag (same name) but the identity is now based on the .de account instead. This is no problem on GitHub’s side and the new user is a different entity
• SonarQube’s (apparently) treats these foo_emutag users as the same entity and tries to look up the user foo@bar.com which no longer exists (either on GitHub or our AD). This breaks the entire user sync.
Apologies for our late reply. Were you able to work around the issue somehow?
First some technical details about what happens in SonarQube: all the logic can be understood from our open-source code in UserRegistrarImpl.java.
To summarize:
SQ tried to find the user based on its GitHub ID → failed because it’s a new entity on GitHub so SQ never saw it, that’s normal!
Then SQ tried to find the user by its GitHub Login → This succeeded! I’m assuming that what you reference as foo_emutag is the GitHub login of the user, so this matching makes sense
As soon as SQ matches the user by its GitHub login, he also validates the email is the same to avoid login recycling. So SQ checks if the GitHub email is the same that it has in its DB → fails! Obviously, foo@bar.de on GH is not the same as foo@bar.com on SQ
SQ thinks that someone is trying to recycle this account by using the same login (and so trying to benefit from its access permissions), so it refuses to match the user, and then you have the error Failed to authenticate with login 'LOGIN' It should be noted that this error message is not great because this code was initially designed for authentication, but either way, it’s similarly used for account sync on Automatic Provisioning. We’ll adjust this message!
Now that we understand what went wrong, we can better assess the situation. The fact that you have a different GitHub user (ie. a different GitHub ID) that is using the same login but a different email confuses SonarQube. In the past, this had been identified as a potential security problem (SONAR-15172) so we don’t allow it anymore, ie. we don’t blindly update the account details and go on matching the user.
I guess you don’t have much control over that, but I’d say if the user is the same in AD, it should be the same in GitHub even after the email change, ie. the same GitHub user should be used so a matching on the GitHub ID would work.
What would solve the situation is to:
Updating the email would be the best, but you can’t because it’s an external user
You can update the GitHub ID, using /api/users/update_identity_provider but you can’t if you have Auto-provisioning enabled. So a realistic solution would be to:
disable Auto-provisioning
use /api/users/update_identity_provider with:
login = the SQ generated login, you can get it from the UI, just right the name on the Users page
newExternalProvider = github
newExternalIdentity = the new GitHub ID of the user, which I think you can only get from their API, ie. https://api.github.com/users/LOGIN (field id, adjust the URL if you are using a GitHub Server instance)
thanks for the reply. This workaround is similar to what we used. We have somewhat direct control over the linked AD group but no control over what GitHub does here. So we removed the user, waited for the sync to GitHub, waited for the sync to SonarQube which removed the problematic user and then added them back to the AD group with the new mail.
The real problem for us is that this fully blocked SonarQube’s user sync which is unpleasant but we can work around that given that this is not a common scenario.
