[ Enterprise-ready is a series of posts focused on Enterprise expectations. You’ll discover features built on top of our developer-first foundations, that enable usage of our products at scale, and allow for company-wide adoption of Code Quality & Code Security best-practices ]
In this first post of Enterprise-ready, we’ll be covering SonarQube functionality purpose-built to help enterprises set up and manage User Authentication (AUTHN) & User Authorization (AUTHZ) in their existing environments. A DevOps pipeline is a concatenation of many different tools that help build, test, validate, deploy software applications. Anytime a company scales past a handful of employees, it would make no sense if user accounts had to be managed in each of these tools individually. It is rather a standard expectation for any Enterprise-ready solution to integrate seamlessly with Identity Provider solutions already in use at a company level. We’re continuously making sure SonarQube meets this expectation, and this blog post gives you an overview of the various options we offer to integrate SonarQube with your existing Identity Provider.
When it comes to centralized authentication in an enterprise context, LDAP (Lightweight Directory Access Protocol) is historically one of the top-of-mind options. It’s an open protocol to interface with Directory Services (OpenLDAP, Apache Directory, Microsoft Active Directory, and so many others..) which store users’ information and credentials.
This is the base use-case, which SonarQube fully supports: validating user’s credentials through LDAP. All this requires is a preliminary configuration of SonarQube’s connectivity to the LDAP Server (the Directory). Once that is in place, SonarQube will systematically submit all login requests to the 3rd-party LDAP server. Note that if the user account does not yet exist in SonarQube, it will be provisioned on the spot as access is granted (process often referred to as ‘just-in-time provisioning’).
Associating your full name and email address with your user ID is standard practice, and SonarQube handles that auto-synchronization, so it can use the information throughout the UI and in its notifications. The SonarQube-LDAP integration systematically and automatically updates these user records on the fly, each time the user logs in. Beyond central authentication, this helps ensure consistency of user information across your IT setup.
LDAP deployments can range from single-location to worldwide geo-distributed setups where multiple LDAP Servers are meshed together in serving the company’s needs. At SonarSource we are continuously listening to feedback and have built the LDAP functionality that helps such global businesses in truly going all-in with LDAP:
- Support for multiple LDAP servers: SonarQube can be connected to different LDAP servers. This allows concatenation of distinct directories, and also enables redundancy.
- Support multiple authentication methods: SonarQube itself needs to authenticate to the LDAP server for security purposes (prior to exchanging any user information). SonarQube offers support for the standard protocols used in such context: CRAM-MD5 , DIGEST-MD5 & GSSAPI .
While LDAP and Active Directory are different Directory Services, it’s important to keep in mind that Microsoft Active Directory does support the LDAP Protocol! This means that all of the LDAP integration functionality described above, is equally available when connecting SonarQube to an Active Directory server!
While LDAP integration still requires users to feed in their user/password information in each individual tool, SSO (Single-Sign On) offers to delegate authentication to your Identity Provider and thereby provides users with a single login experience and a seamless experience of launching business applications with authentication happening behind the scenes.
With SonarQube you can delegate authentication to a SAML 2.0 Identity Provider. After the initial configuration is made, SonarQube will display a ‘Log in with SAML’ button for users to authenticate, from which point with SAML protocol will take it from there to allow (or deny!) the authentication.
Multiple SAML Identity Providers (Okta ; Auth0 ; OneLogin; Keycloak ; etc.) exist, and various online tutorials are available (for example: Azure Active Directory SSO with Sonarqube). Our Community Forum is a good place to exchange examples and best-practices for each. For example, if you’re interested in reading more on the SAML topic:
- A guide to SonarQube and SAML Authentication with Okta
- A guide to SonarQube and SAML authentication with OneLogin
This additional authentication setup consists of proxying SonarQube behind a server that will handle authentication of all HTTP requests. See our documentation to learn more about HTTP Header Authentication.
We’re staying on the topic of SSO, but this time tying it in with the DevOps Platforms your dev teams are using daily. Platforms like GitHub or GitLab have gone far beyond offering ‘Code Repositories’, and truly offer a suite of functionalities for development teams to manage their codebases, do code reviews, run automated checks and even deploy their application(s). They are essentially central platforms for dev teams, and in that spirit can even be used as a central authentication backend!
If you’ve already done the work of mirroring your users and groups in one of these DevOps platforms, SonarQube can take advantage and use it for authentication. SonarQube 8.9 LTS supports SSO via GitHub (GitHub Enterprise or GitHub.com) and also GitLab (GitLab Self-Managed and GitLab.com).
Users’ authentication will redirect through the platform and, aside from the first time where they must explicitly grant SonarQube permission (to log them in this way), this will then be seamless once they have a current active session.
You’ve now seen all the various options SonarQube offers to delegate authentication, and smoothly integrate with any existing setup you would have. But using a tool is more than getting to log in: permissions play a big role in what each user can do within the tool, and permissions are often managed for groups of users.
Whether it’s LDAP, Active Directory, GitHub or others, they all offer the ability to manage groups of users, and organize the user base accordingly. So when you delegate authentication, you wouldn’t want to still manually have to replicate group membership, you want to delegate that too!
SonarQube fully supports the delegation of authorization via groups, allowing you to centralize your entire management of users, groups and permissions.
SonarQube ties in with your role-based access control (RBAC) setup by pulling group membership information from your Directory Service. If a group with the same name exists in SonarQube, with specific permissions assigned to it, the user will automatically inherit these permissions (at login time). We call this ‘Group Mapping’, and it can be enabled with each of the above user authentication methods.
Here’s an example of the configuration to enable group mapping with GitLab:
Now that you’ve discovered the various ways SonarQube can integrate with your user authentication and authorization setup, we can only recommend one next step: try it out in practice! Each of these methods only requires a quick config (detailed in our documentation), and you’ll then get to experience first-hand what the user login and user management experience looks like. This is also a good opportunity to leverage the staging licenses you are entitled to if you use a commercial edition of SonarQube.
This wraps up our first entry of Enterprise-ready. We hope you discovered how SonarQube is ready indeed, to integrate with your existing Enterprise Authentication and Authorization setup.