The way authorization is implemented in SonarQube is pretty standard. It is possible to create as many users and groups of users as needed. The users can then be attached (or not) to (multiple) groups. Groups and / or users are then given (multiple) permissions. The permissions grant access to projects, services and functionalities.
To administer groups and users, choose Administration > Security, and use the sub-menu items.
Multiple integrations that allow the delegation of authentication are available (see the Plugin Library and Other Plugins), but you can manually create and edit users at Settings > Security > Users. For manually-created users, login and password can be set at creation. Manually-created users can edit their passwords.
During both user creation and edit, you can set an account's screen name, email address. User login and email address will be implicitly recognized by the Issue Assignment feature as SCM accounts if applicable, but you can set additional SCM accounts explicitly.
A group is a set of users.
To create a new group, go to Administration > Security > Groups > Add new group.
To edit the membership of a group, click the icon next to the membership total.
Two groups have a special meaning:
- Anyone is a group that exists in the system, but that cannot be managed. Every user belongs to this group, including Anonymous user.
- sonar-users is the default group to which users are automatically added.
To set global permissions, log in as a System administrator and go to Administration > Security > Global Permissions.
- Administer System: All administration functions for the instance: global configuration.
- Administer Quality Profiles: Any action on quality profiles.
- Administer Quality Gates: Any action on quality gates
- Execute Analysis: Execute analyses (project, view, report, developer), and to get all settings required to perform the analysis, even the secured ones like the scm account password, and so on.
- Create Projects: Initialize the structure of a new project before its first analysis. This permission is also required when doing the very first analysis of a project that has not already been created via the GUI.
Project permissions are available from the project-level Administration menu: Administration > Permissions.
Project visibility may be toggled between public or private. Making a project private hides its source code and measures from the Anyone group. For both public and private projects, three different permissions can be set:
- Administer Issues: Change the type and severity of issues, resolve issues as being "Won't Fix" or "False Positive" (users also need "Browse" permission).
- Administer Security Hotspots: "Detect" (convert) a Vulnerability from a "Security Hotspot", reject, clear, accept or reopen a "Security Hotspot" (users also need "Browse" permission).
- Administer: Access project settings and perform administration tasks (users also need "Browse" permission).
- Execute Analysis: Execute analyses (project, view, report, developer), and to get all settings required to perform the analysis, even the secured ones like the scm account password, the jira account password, and so on.
Private projects have two additional permissions:
- Browse: Access a project, browse its measures, issues and perform some issue edits (confirm/resolve/reopen, assignment, comment).
- See Source Code: View the project's source code.
Note that permissions are not cumulative. For instance, if you want to be able to administer the project, you also have to be granted the Browse permission to be able to access the project (which is the default for Public project).
You can either manually grant permissions for each project to some users and groups or apply permission templates to projects.
Permission Templates for Default Project Permissions
SonarQube ships with a default permissions template, which automatically grants specific project permissions to certain groups when a project (or developer, or view) is created. It is possible to edit this template, to create additional templates, and to have a template apply only to a subset of new projects.
This is done through permission templates. Go to Administration > Security > Permission Templates.
Creating permission templates
To create a new template, use the "Create" button on Administration > Security > Permission Templates. It is possible to provide a Project key pattern. By default, every new project matching this key pattern will have the permissions described by the template.
Editing Project Templates
Templates are empty immediately after creation. Clicking on the template name will take you to its permission editing interface.
Project Creators permissions
Project Creators is a special group that appears only in the project template permission editing interface. Any permissions assigned to this group will at the time of project creation be granted to the single user account used to create the project. This is only useful for users who are granted the Global-level Project Creation permission. This allows SonarQube administrators to let a group of users create and administer projects autonomously.
While project templates can be applied after project creation, applying a template that includes "Project Creators" permissions to an existing project will not grant the relevant permissions to the project's original creator.
Reset project permissions to a template
To apply permission templates to projects to to Projects > Management. You can either apply a template to a specific project using the project-specific Actions > Apply Permission Template option or use the Bulk Apply Permission Template to apply a template to all selected projects.
Note that there is no relation between a project and a permission template, meaning that:
- the permissions of a project can be modified after a permission template has been applied to this project
- none of the project permissions is changed when a permission template is modified
I have locked myself out
To recreate a System administrator: