The Quality Profiles service is central to SonarQube, since it is where you define your requirements by defining sets of rules (ex: Methods must not have a complexity greater than 10).
Ideally, all projects will be measured with the same profile for any given language, but that's not always practical. For instance, you may find that:
- Technological implementation differs from one application to another (for example, different coding rules may apply when building threaded or non-threaded Java applications).
- You want to ensure stronger requirements on some of your applications (internal frameworks for example).
Which is why you can define as many quality profiles as you wish. To manage quality profiles, go to Quality Profiles (top bar), where you'll find profiles grouped by language. Here's an overview of this page:
As you can see above, language plugins always come with a predefined built-in profile (usually called "Sonar way") so that you can get started very quickly with SonarQube analyses. This is why as soon as you install a new language plugin, at least one quality profile will be available for you.
Each language must have a default profile (marked with a green check). Projects that are not explicitly associated with a specific profile will be analyzed using the language's default profile.
The Quality Profiles service can be accessed by any user (even anonymous users). All users can view every aspect of a profile. That means that anyone can see which rules are included in a profile, and which ones have been left out, see how a profile has changed over time, and compare the rules in any two profiles.
To make rule profile changes (create, edit or delete) users must be granted the Administer Quality Profiles and Gates permission.
A project administrator can choose which profiles his project is associated with. See Project Administration for more.
Out of the box, SonarQube comes with a complete mechanism to manage security (authentication + authorization). Configuring security allows you to cover two main use cases:
- Manage access rights to components, information, etc.
- Enable customization (custom dashboards, notifications, etc.) of SonarQube for users
Here are examples of security restrictions you can enforce by configuring security in SonarQube:
- Secure a SonarQube instance by forcing authentication prior to accessing any page
- Make a given project invisible to anonymous users
- Restrict access to a project to a given group of users
- Restrict access to a project's source code to a given set of users
- Define who can administer a project (setting exclusion patterns, tuning plugins configuration for that project, etc.)
- Define who can administer a SonarQube instance
Authentication and authorization can also be delegated to an external system: LDAP or Active Directory with the SonarQube LDAP Plugin, PAM with the SonarQube PAM Plugin or Crowd with the SonarQube Crowd Plugin. SSO is also supported through the SonarQube OpenID plugin.
Another aspect of security is the encryption of settings such as passwords. SonarQube provide a built-in mechanism to encrypt settings.