For the last year, we’ve been quietly working to add security-related rules in SonarQube’s language plugins. At September’s SonarQube Geneva User Conference we stopped being quiet about it. Read the rest of this page »
When used out-of-the-box, Sonar is a radiator for code quality continuously accessible by everyone. But of course, there are situations in which adding access control is necessary. Access control management in Sonar exists since version 1.12 (Nov. 2011) and covers most use cases:
When used out-of-the-box, Sonar is a code quality radiator accessible by everyone at anytime. Like for JIRA, Hudson, a post-it dashboard or any other piece of the development toolset transparency is a key success factor for adoption. So, by default in Sonar, anyone can access any project under continuous inspection and navigate through it.
But of course, there are situations where securing Sonar is necessary. Let’s imagine for 2 minutes a consulting company that does development for customers and wishes to allow those customers to follow their own projects in Sonar. Since the company has many customers, it is necessary that group of projects can be isolated to make sure each customer only has access to his own projects. Prior to Sonar 1.12, this was only possible by having one instance of Sonar per customer.
Since Sonar 1.12 there are services available in the web interface to handle this and to cover the following use cases :
All those use cases can be implemented through the Sonar web interface and will take effect immediately. The way security is handled in Sonar is pretty classic as the security policy is based on the following three concepts : user, group and role (global or by project). Let’s take the example of the “Project roles” page available at project level :
Three roles are available at project level : Administrator, User and Code Viewer. Users and/or a groups of users can be associated to each of those roles to get the required permissions.
User and group can be first created through the “Users” and “Groups” services available in the administration configuration section. Here is the screenshot of the “Groups” service :
That was authorization, let’s now talk about authentication. By default, user authentication is done against the Sonar DB (user table) but an external authentication engine can also used : OpenLDAP, Microsoft Active Directory, Apache DS, Atlassian Crowd … Three identity plugins already exist : two open source LDAP Plugin, Crowd plugin and a commercial one Identity Plugin. They all use the public Sonar authentication extension point.
To conclude, it is possible since Sonar 1.12 to easily implement a robust enterprise security policy. Those new functionality have been done with no impact whatsoever on Sonar users who do not want to activate security and want to keep full transparency.
During the last few months, Sonar has definitely become the leading Open Source Platform to manage Java code quality. The objective to democratize access to code quality is becoming concrete. Read the rest of this page »
However when analyzing source code, quality is only one aspect of things. The ultimate platform should be able to handle Quality, Security and Architecture. Sonar 2.0 will take care of Architecture with a DSM and several valuable Object Oriented metrics.
What is the plan to handle Security ? Technically speaking, there is no difference between a quality rule and a security rule. They both consist in writing a piece of code that analyzes an Abstract Syntax Tree (AST) or the bytecode depending on what needs to be done.
