All our projects are under a single SonarCloud organization with source code in Azure DevOps repos
Same position as Alexander. The idea of adding users to SonarCloud organization automatically is great but we would like to restrict users based on certain AAD security groups in org settings. Not everyone in our AAD has access to Azure DevOps today.
Default “Members” membership is sufficient.
Another related question on this topic: when we add a user to the Members group today, how do we know if the user account was created in sonarcloud with the login type as we expected as Azure DevOps? Currently we search a user based on our company’s email address when adding it to the Sonarcloud organization. But it’s possible that someone create a GitHub, Gitlab or Bitbucket account with our company’s email address and login to Sonarcloud with it to have the footprint created. We will have no way of knowing it before adding such unexpected accounts into our Sonarcloud organization.
Can Sonarcloud enforce that only accounts created with the expected login type (Azure DevOps in our case) can be added to the “Members” group?
Thanks for your answer @AlexandervD and @shawnz88
It will help me better design the solution we will propose.
I’ll keep you updated
Kind regards,
Christophe
@Christophe_Havard hello! Where is this item in your backlog? If it is blocking multiple organisations from adopting your cloud product it is surprising that nearly two years after the request you are still asking design questions.
Azure SSO is a pretty basic feature, if you spend 1 day with your dev team you should have all the stories defined.
Hi @gbrissonnette ,
This topic will hopefully be on our official roadmap for 2022. I have no more news for now and will keep you informed when things move
We have a similar scenario, with ± 60 users to onboard, something I did not budget on being a one by one, multi step process. There is a good chance we would not have signed up to the cloud version if I had known about this issue. My bad for not doing my homework fully, I was warned that history could not be migrated but I missed that users could not be. I feel that this should be give much more priority than it has.
Here is my feedback for your 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)?
A single SonarCloud org, with a single Azure DevOps subscription
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?
I would be happy with that, it will be more users than needed but that is acceptable for us. If we could limit it to users in a contributor role, that will be a perfect match.
Also, if users are automatically added to your SC organization, which permissions should they have by default? None? Execute Analysis?
In my case, I need read only access mainly, to be able to read the detailed report. But if we could pick a group or have a default role, we could set default permissions how we pleased.
Shesh, even being able to log in with a single readonly account would be an improvement. Currently it just takes the current user session and does not provide an option to log in with a different Azure DevOps user.
Oh side note, It is possible to create a single shared readonly account if your security permits. Just Chrome was auto redirecting me without the chance to change the username.
Tagging in here to vocalize that I’m insanely disappointed this feature isn’t implemented. I’m looking at API endpoints and what I know is available on the Azure DevOps side, and to be totally honest I’m considering writing a serverless function to do this on my own. I understand core features are important and this is obviously a github-first product but… for anyone with more than a couple dozen Azure DevOps users it’s absurd to have to do a global search of SonarCloud users instead of being connected to a platform group.
Since this thread is being monitored I’d urge the folks working on it to get an MVP out first:
Allow admin option to automatically sync all users in an Azure DevOps Collection.
Send notification emails to those users allowing them to login and join the Sonar Org.
Process changes hourly to remove users from the Sonar Org when removed from ADO, and/or send new emails for new users in ADO.
After MVP is out:
Allow the limiting of synced users to an ADO Team Project
Allow the limiting of synced users to an ADO Group
Allow the “blacklisting” of users who may be in ADO that we may not want in Sonar
Allow the limiting of synced users to ADO Access tiers (Stakeholder etc.) to propogate limitations on viewing source code
Allow the limiting of synced users to those from a specific Azure AD tenant
Hey @NielMagSW & @Ryanman ,
Thank you very much for your detailed feedback. Please rest assured that this thread is followed and all your feedback is noted and discussed
Currently it just takes the current user session and does not provide an option to log in with a different Azure DevOps user.
This relates to this ability to select your Azure tenant when connecting to SonarCloud. Right?
@Ryanman
Since you are mentioning “collection”, I guess you’re using Azure DevOps Server? Or were you referring to an Azure DevOps Organization?
Also
Allow admin option to automatically sync all users in an Azure DevOps Collection.
So you’d expect a way to visualise the list of provisioned users even before they actually onboard SonarCloud. Correct?
Also, if we connect SonarCloud to an AAD and automatically provision all users, what do you think should happen if there are like 2000 users in the AAD? I do have an opinion on this but I’d love to have yours.
Thanks for your reply. I have since discovered it is a Chrome issue\feature. If you use a different browsers or fight with Chrome longer, you can get access to work off a single shared user. It is not pretty, easy or secure, but it gets the job done.
Speaking to your 2nd question, I think that if you can specify even a single AD group, that will make the AAD solution far more usable under many scenarios. Technically, it should not be a significant complication.
I used the incorrect terminology (been using TFS/VSTS/ADO for a while now so…). I’m referring to an Organization here.
An MVP wouldn’t need a visualization component, in my opinion. I already know who’s in my Organization or who’s in a Project. Most people, hopefully, are already synchronizing who’s included in their Org/Project from their Azure AD (Now Entra ) instance. Another technical detail is that connecting with an Organization may be more difficult than a Project, so the latter is even sufficient as an approach. Microsoft suggests that most orgs use just one Project anyway.
Finally, there’s another option to get this done for most orgs: Support SCIM in Sonar Cloud. This has to be the highest value option around. The team may not be viewing this as a “Feature” but I promise you that for enterprise customers it’s enormous. This will do more than solve the “problem” with Azure DevOps, it’ll open this platform up to a huge number of identity providers and essential automation that makes SonarCloud unworkable at scale. My org is only ~100 users and this is already something that makes SonarCloud worse than every single other SaaS product in our enterprise.
In any case, the number of votes to add this feature through some mechanism in the productboard platform already puts this at the very top of the whole list.
Finally, while I may regret saying this, integrating SCIM can be an add-on service, a premium that scales along with the number of lines of code that’s being analyzed.
our organization would like to move to Sonarcloud too, but we can’t because there’s no authenticating with Azure AD. We are in 2023 now, is there still no ETA? Our CISO has forbidden the use of PAT tokens to integrate with Azure DevOps. So this is becoming quite critical for us.
+1 for this as with all others. In 2023 SSO with AzureAD must be supported if you wish any organisation to use SonarCloud. Account and role provision/deprovision with SCIM also needs to be supported as a minimum.
So here we are moving into 2024 and this is yet to be added…maybe it’s time for our organization to commence looking at alternative solutions to SonarCloud.
) instance. Another technical detail is that connecting with an Organization may be more difficult than a Project, so the latter is even sufficient as an approach. Microsoft suggests that most orgs use just one Project anyway.