Configuring SonarQube SAML with Authentik
22 May 2026
I run SonarQube and Authentik on my homelab and wanted SSO so I’m not managing a separate SonarQube password. Here’s the configuration I landed on after some trial and error.
Authentik side
Create a new SAML provider in Authentik with these settings:
| Setting | Value |
|---|---|
| ACS Binding | Post |
| Audience | (leave empty) |
The Audience field should be left blank. SonarQube includes its own entity ID in the AuthnRequest, and if Audience is set in Authentik it needs to match exactly, so leaving it empty avoids the issue.
Set the Application slug to sonarqube, which is what shows up in the SSO URL.
SonarQube side
In Administration → Configuration → Authentication → SAML:
| Setting | Value |
|---|---|
| Application ID | sonarqube |
| Provider ID | https://sonar.example.com/saml2/metadata |
| SAML Login URL | https://auth.example.com/application/saml/sonarqube/sso/binding/redirect/ |
| Identity Provider Certificate | Full PEM (with -----BEGIN CERTIFICATE----- headers) |
The Provider ID is SonarQube’s own metadata URL, used as the entity ID in outgoing requests. Replace sonar.example.com with your SonarQube hostname.
Paste the full PEM certificate block including the header and footer lines, not just the base64 content. If you get a 500 error when saving, the certificate is probably encoded wrong. Make sure it starts with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE-----.
Attribute mappings
Authentik uses these attribute names by default, which is what goes into SonarQube’s attribute fields:
| SonarQube field | Attribute |
|---|---|
| SAML user login attribute | http://schemas.goauthentik.io/2021/02/saml/username |
| SAML user name attribute | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name |
| SAML user email attribute | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress |
| SAML group attribute | http://schemas.xmlsoap.org/claims/Group |
The login attribute is in Authentik’s own namespace (schemas.goauthentik.io), not the WS-Federation one. I initially used the wrong one and got a flow that would authenticate but not log in.
What I left off
- Sign requests: disabled. Enabling it requires a service provider private key to be configured too, otherwise SonarQube sends requests it marks as signed but aren’t, and Authentik rejects them.
- Service provider private key: not needed for basic SSO.
Testing
SonarQube has a test button next to the Save button in the SAML config page. It runs through the auth flow in a new tab and shows the raw assertion, so you can check the attribute names are what you expect before switching SSO on for real.