Hi Christophe,
My use case is as follows. We are using Azure DevOps git for source control and running sonarcloud scans through build pipelines. For sonarcloud login I am using my same AAD credentials that I am using for Azure DevOps. I am the sonarcloud administrator and was able to set up the organization token and running sonar scan successfully through build pipelines. However only I can login to sonarcloud. Is there a way I can get users added to a security group in AAD and add them to my organization so that even they can see and get the reports ?
Thank you for your answer.
For now, you cannot just add your user to a security group on AAD side, and add the group to your Sonarcloud organization.
The only thing you can do now is to ask your users to connect by themselves to Sonarcloud using Azure DevOps SSO. It will create an identity on Sonarcloud side. Then you will have to manually add them to your organization and projects.
We will definitely address this need as soon as possible, but I have no timeline for now.
Iāll post updates on this page
I will also like to request an update on this feature. Right now manually adding any user is quite a bit risky since while searching I may accidentally add a user who is potentially out side of my organization.
At a minimum the search interface for manual adding should show also the email address of the user and not just the uid of the user on the Sonar Cloud side. Example - if I am trying to add an user instead of showing āJohn Doe - 123556ā which makes it very difficult to know especially if its a common name and make sure that I am not adding an user who is not in my organization.
Is this feature still not implemented? We are a large organisation and evaluating sonar. We definitely need a way to add azure ad groups (either office 365 or security groups or both) to sonarcloud. When will this feature be released?
We need this functionality as well. Would love it if I could configure the following (and this might be a step in between):
Allow me to choose 1 or more Azure ADās and connect them to my org
Then restrict the members that I can add to my organization on those based on the AADās I selected for my org. That at least saves me asking for member ids and not knowing if they created an account using AAD
That at least would allow me to ensure only our company users are on our sonar cloud org. If you then also allow me to identify them (via API calls) based on their unique AAD login (upn) , I can also automatically remove them once offboarded.
@Christophe_Havard Please share an update on this topic. Maintenance automation is more and more important for larger organizations, like automated offboarding etc.
@zaat Iām sorry to say we havenāt move forward on this topic. Itās still in the pipe, but no ETA for now.
In order to refine my vision on this topic, may I ask you some questions @zaat ?
For example, you talk about āMaintenance automationā, what do you mean exactly by that? Do you have a painful use case on this topic youād like to share? As things are not written in stone, community input is always valuable
Hi @Christophe_Havard , thanks for the quick reply here.
To explain our case: I work for a financial company, spread around the world in 30 countries, and have many contractors in IT. You can imagine that every month we have a load of new contractors coming in and leaving us as well. From a security perspective we need to remove access immediately once someone has been offboarded. Also for all the regulation that we have to fulfil in all the 30 countries we have to comply to local financial company related laws and regulations.
When someone gets offboarded, through our official process, they should loose all access in all systems as they no longer work for us. With SonarCloud right now, it is not possible for us to detect if we have loopholes there. We cannot see the accounts based on our Azure AD. I can also not limit membership to accounts created based on our Azure AD. I can also not automatically have them added or removed as an organization member.
So what I would look for, maybe as intermediate:
Allow me to relate my organization to an Azure AD subscription, so only members from that subscription can be added to my organization in SonarCloud (to avoid me from selecting the wrong person)
Let me choose to automatically add members of our Azure AD subscription to be added to the organization (e.g. someone creates an account on SonarCloud based on our Azure AD, and gets added to our organization automatically).
When using the user-api, allow me to see their upn, so I can validate if they need to be removed. Or email address
When it comes to offboarding members, I would (as intermediate) like to be able to find the account in SonarCloud based on the Azure upn, so I can call a SonarCloud rest-api and have their membership to our organization removed. And maybe even the account removed?
Thats what I mean with maintenance automation: No manual interference to remove a member from the organization, no more needing to trust them to have used Azure AD login (instead of their own gmail and just send me that account). Right now I have no clue if all the members in our organization actually did use their Azure AD account correctly, making it not possible to be 100% sure that only validated users have access to our source code (especially after they have left our company).
Thank you very much @zaat , your feedback is super interesting
Regarding what you described, I have few more questions :
Do you have all your projects under a single SonarCloud organization or under multiple Organizations (related to your business units, or teams, or regions,etc)?
Let me choose to automatically add members of our Azure AD subscription to be added to the organization (e.g. someone creates an account on SonarCloud based on our Azure AD, and gets added to our organization automatically).
So, in other words, āautomatic user provisionningā on your SonarCloud organization, right? So it may mean that, for a given organisation, all members of the ālinkedā AAD would be added automatically to the SonarCloud organization? Would that be OK on your side as a first iteration?
Also, if users are automatically added to your SC organization, which permissions should they have by default? None? Execute Analysis?
I will keep your post as insights for this feature and will give update about this topic through this post.
I hope to address this during the year, but no ETA yet.
We have created a paid SonarCloud Organization for our private projects. We also use Azure DevOps and our users logs in to Azure DevOps using their Work Accounts using Azure AD. Currently, the way I can add the users to the Organization is by Searching for the users and add them to the organization. For this to work, our users first need to log in to SonarCloud using their Azure AD account. Then only I am able to search for them. Adding users this way presents some administrative overhead for us.
We were using SonarQube previously, and we had it hosted on our own VM. And We had used Azure Active-Directory Plugin for SonarQube installed and configured so our users can directly login to SonarQube using AAD without the need of adding them to manually.
Not being able to manually create the user (without asking the user to sign in first) is painful for a small organization.For larger organizations not having automated (de)provisioning is even worse.
Simply allowing API api/user_groups/add_user to add user to āMembersā group would solve this problem for us because we can build a self-service tool for users to add their logins to the organization with some validations built in to ensure only the proper logins are allowed.
Do you have all your projects under a single SonarCloud organization or under multiple Organizations (related to your business units, or teams, or regions,etc)?
If we imagine that we add āautomatic user provisioningā, that would mean that, for a given organisation, all members of the ālinkedā AAD would be added automatically to the SonarCloud organization, without any automatic group creation on SonarCloud side. Would that be OK for you as a first iteration?
Also, if users are automatically added to your SC organization, which permissions should they have by default? None? Execute Analysis?
A single SonarCloud organization. Its dedicated to 1 engineering business unit.
Not entirely. As this would result in several hundreds of users more than needed (including externals) added to the SonarCloud organization. We donāt want them to have access to our SonarCloud organization at all. If they would get access this would immediately result in a security incident. I suggest to add an optional AAD group filter to the scope, so a customer can filter what is synchronized and what not.
Default āMembersā membership is sufficient for our usage.
