[ 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 ]
TL;DR overview
- SonarQube Server supports LDAP and SSO authentication, enabling enterprise teams to manage access using their existing corporate directory services rather than maintaining separate SonarQube credentials.
- LDAP integration allows automatic user provisioning and group synchronization, so that developers and teams can be onboarded or offboarded centrally through Active Directory or other LDAP-compatible directories.
- SSO support includes SAML 2.0 integration with identity providers such as Okta, Microsoft Entra ID (Azure AD), and Ping Identity, providing a streamlined login experience for large organizations.
- Properly configured authentication and SCIM provisioning reduces administrative overhead for platform teams and enforces access controls aligned with corporate security policies.
In this first post of Enterprise-ready, we’ll be covering SonarQube Server 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 Server meets this expectation, and this blog post gives you an overview of the various options we offer to integrate SonarQube Server with your existing Identity Provider.
SonarQube Server integration with LDAP and Active Directory
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.
LDAP Authentication and just-in-time provisioning
This is the base use-case, which SonarQube Server fully supports: validating user’s credentials through LDAP. All this requires is a preliminary configuration of SonarQube Server’s connectivity to the LDAP Server (the Directory). Once that is in place, SonarQube Server will systematically submit all login requests to the 3rd-party LDAP server. Note that if the user account does not yet exist in SonarQube Server, it will be provisioned on the spot as access is granted (process often referred to as ‘just-in-time provisioning’).
Auto-synch of Name and email via LDAP
Associating your full name and email address with your user ID is standard practice, and SonarQube Server handles that auto-synchronization, so it can use the information throughout the UI and in its notifications. The SonarQube Server-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.
Going the extra mile: support for multiple LDAP servers and multiple security protocols
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 Server can be connected to different LDAP servers. This allows concatenation of distinct directories, and also enables redundancy.
- Support multiple authentication methods: SonarQube Server itself needs to authenticate to the LDAP server for security purposes (prior to exchanging any user information). SonarQube Server offers support for the standard protocols used in such context: CRAM-MD5 , DIGEST-MD5 & GSSAPI .
Last but not least: SonarQube Server and Microsoft Active Directory
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 Server to an Active Directory server!
Going the extra mile: SSO with SonarQube 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.
SAML authentication (Okta; OneLogin; Azure AD etc.)
With SonarQube Server you can delegate authentication to a SAML 2.0 Identity Provider. After the initial configuration is made, SonarQube Server 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 Server). 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 Server and SAML Authentication with Okta
- A guide to SonarQube Server and SAML authentication with OneLogin
HTTP-header authentication
This additional authentication setup consists of proxying SonarQube Server behind a server that will handle authentication of all HTTP requests. See our documentation to learn more about HTTP Header Authentication.
Authentication via DevOps Platforms (GitHub SSO ; GitLab SSO)
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 Server can take advantage and use it for authentication. SonarQube Server 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 Server permission (to log them in this way), this will then be seamless once they have a current active session.
Bringing it all together: delegating Authorization with SonarQube Server
You’ve now seen all the various options SonarQube Server 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 Server fully supports the delegation of authorization via groups, allowing you to centralize your entire management of users, groups and permissions.
RBAC - Role Based Access Control
SonarQube Server 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 Server, 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:
Time to try it all out!
Now that you’ve discovered the various ways SonarQube Server 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 Server.
This wraps up our first entry of Enterprise-ready. We hope you discovered how SonarQube Server is ready indeed, to integrate with your existing Enterprise Authentication and Authorization setup.