Sync only Mail addresses from specific domains from GitHub

We currently encountered the following issue in our setup: We are using GitHub for Code Hosting and as Login Method for SonarQube. Most of our developers do have a private GitHub account which they also use within the organization for their work.
Now those devs mostly have set their private E-Mail address set as their primary Mail Address. When SQ syncs a GitHub account into a Account in SQ the primary address is always used, which we don’t want for several reasons: We don’t want to leak this “unnecessary” data into our tool, and we don’t want to risk sending organization related notifications to our devs private mail accounts.

A way I could think of to fix this would be asking our devs to add their organization mail address (which can be easily detected, since its @companyname.tld) as a secondary mail address and then having a way to tell sonarqube to not use the primary e-mail address but instead use any E-Mail address which matches a given allowed domain (or a list of domains), or not apply an E-Mail address at all when such a domain does not exist for a user.

Would something like this be possible?

Hello Michael
when your company allowed (invited) developers to join your company github organization through their personal github accounts, you voluntarily blurred the line between personal and professional use of those github accounts, and developers accepted invitations to do it.

In SonarQube only users can subscribe to notifications, and only for themselves. I see no difference here with the setup you have in place. Developers cannot complain to receive notifications to which they subscribed on their personal email account since they accepted to join a personal account to your github organization (and they can change that if needed). And your company cannot complain to having professional content leaking out of its email infrastructure since you invited this with the external github accounts invitations.

As for the ‘leak’ of personal information from to your SonarQube instance, in my view you already have this personal data under your organization responsibility in github.

If having those personal emails used in SonarQube is truly an issue, my advice clearly is to fix the root cause for it, through the application of a strict email policy on github side.
Or to switch to some other authentication mechanism on SonarQube.

Best regards

@Sylvain_Combe thank you for that detailed explanation. But I want to disagree on your strong “your company cannot complain to having this or that”. Just because we decided to host code with Github doesn’t mean that we have to push personal information into other tools.

Back to topic:
Authenticating is the one perspective. The other perspective is to map tasks from SonarQube (e.g. remove a certain code smell) to the committer in GitHub. It would be also helpful if everyone had the chance inside SonarQube to come up with such a mapping. For instance, if everyone had the opportunity to specify an additional email inside SonarQube for the accounts which have been created driven by GitHub, that would also be a solution. Is there something like that?

Best regards,

Hello Michael
when delegated authentication feature is used on a SonarQube for some users, no change or addition can be applied to login or email information for those users.

However, you are still able to add any number of SCM identifiers to those accounts, as with any SonarQube account, so that login identifiers from the blame data can be attached to an account in SonarQube.
This must be done by an administrator of your SonarQube instance and can be automated or scripted thru the APIs ( api/users/update with scmAccount parameter).
In that way, a developer could login thru a corporate github account, while contributing to the projects through their usual personal account, and only their additional github login would be stored in DB. They will not be able to add this SCM identifier for themselves though.


1 Like

@Sylvain_Combe Sorry to revive this thread but it’s exactly what I came here looking for.

With respect, I disagree with your assertion.

GitHub enterprise let’s us be very specific and controlling about the difference between private organization repositories and the personal aspect of the GitHub account. When we were evaluating using GitHub we specifically asked this question of if we should force users to create a second enterprise account that used their work email as the primary email address since the features to allow us to actually control the accounts was far down the roadmap. GitHub’s direct answer was something along the lines of “The account is their professional identity, they should use that, we will give you all the controls you need to protect your IP”. Users have to authorize SSH keys to the org, they have to log into SSO before they can access repos, security groups are synced with AD, they can only get notifications from those repositories to a domain we authorize, etc, etc.

I believe this is a gap in functionality on the SonarQube side to require and use a specific email domain. There’s already a setting to require the user to be a member of a specific organization, this feels like the same thing on a different property.