SSO integration with HTTP header is not working

SonarQube Server / Community Build
1

Hello team,

I am currently running SonarQube Community Edition Version 9.9.3 with LDAP integration and Nginx as the reverse proxy on Linux, and want to switch to SSO authentication using HTTP header.

The SSO identity provider is authenticating users properly, and Nginx is passing access back to SonarQube, and setting the headers (X-Forwarded-Login and X-Forwarded-Name) as well.

However, SonarQube doesn’t seem to be doing anything. Users are not logged in. I can still log in as a local admin user. I turned on debug, but don’t see any auth.event entries in web.log either.

I have following configuration entries in sonar.properties:

sonar.web.sso.enable=true
sonar.web.sso.loginHeader=X-Forwarded-Login
sonar.web.sso.nameHeader=X-Forwarded-Name
sonar.web.sso.emailHeader=X-Forwarded-Email

Any idea what might be wrong with my setup?

Thanks

Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!

2

Hey there.

Have you migrated your users from using LDAP auth to HTTP Header Auth?

You can find more details about doing this in this guide I wrote!

3

Hello Colin,

Thanks for getting back to me!

I read your guide, but didn’t know I have to do that first.

Will I have to convert all the existing users before the integration works? Or when I convert a user, it should work for the user?

Also what happens if it is a new user?

Thanks,

Hongyuan

4
  • You can convert users 1 by 1, which is great for testing!
  • New users will get logged in automatically once you start using HTTP Header Auth
5

Hi Colin,

I am trying to convert a user, but it doesn’t seem to work for me:

curl -X GET -u squ_xxx: 'https://sq.domain.com:8443/sonar/api/users/search'
<html>
<head><title>302 Found</title></head>
<body>
<center><h1>302 Found</h1></center>
<hr><center>nginx/1.20.2</center>
</body>
</html>

curl -X POST -u squ_xxx: 'https://sq.domain.com:8443/sonar/api/users/update_identity_provider?login=abc&newExternalIdentity=a.bc@domain.com&newExternalProvider=sonarqube'
<html>
<head><title>302 Found</title></head>
<body>
<center><h1>302 Found</h1></center>
<hr><center>nginx/1.20.2</center>
</body>
</html>

https://sq.domain.com:8443/sonar is the URL for the test server. It will go to our SSO server for authentication, then pass to our nginx server, and then back to the test SQ server.

The token is for the local admin user.

Any ideas?

This is the first time I am using your API. Your help is sincerely appreicated!

Hongyuan

6

Hi Colin,

I got the user search working, but found out that some of our users have LDAP_default as their externalProvider, and the rest have sonarqube, which is weird. I am not sure how it got to this state. We have been using LDAP up to this point and never changed it.

So I guess I need to change all of them to sonarqube now, right?

With LDAP, the user login is their ldap user ID; with SSO, their login will be their email, so I guess I need to manually change their login using the API as well?

Thanks so much for your help!

Hongyuan

7

Hi Colin,

I tried to update my account from this:

{“login":“dyi”,“name”:“DAVID_YI”,“active”:true,“email”:"david.yi@domain.com”,“groups”:[“sonar-users”],“tokensCount”:0,“local”:false,“externalIdentity”:“dyi”,“externalProvider”:“sonarqube”,“avatar”:“1212234a92a795e63320f1fc20bc1c2f”},

to this:

{“login":"david.yi@domain.com”,“name”:“DAVID_YI”,“active”:true,“email”:"david.yi@domain.com",“groups”:[“sonar-users”],“tokensCount":0,“local”:false,“externalIdentity”:"david.yi@domain.com”,“externalProvider”:“sonarqube”,“avatar”:“1212234a92a795e63320f1fc20bc1c2f”},

In the web.log, I do see this:

web[o.s.s.a.HttpHeadersAuthentication] HTTP headers authentication enabled

but the SSO authentication is still not happening.

Any ideas?

Thanks for your help!

Hongyuan

8

Is the value of X-Forwarded-Login when you browse SonarQUbe david.yi@domain.com? You should be able to confirm this in your Browser’s Dev Tools.

9

Yes…I confirmed that before you tried to update user login. I just confirmed again. x-forwarded-login, x-forwarded-email and x-forwarded-name are all set properly.

11

Hi Colin,

https://sq.domain.com:8443/sonar is the URL for my server. It will first go to our SSO server for authentication, then pass to the Nginx server at https://sq.domain.com:9191/sonar, and finally go back to the SQ server at http://sq.domain.com:9090/sonar.

I have a separate nginx configuration file for SQ:

server {
    listen              9191 ssl;
    server_name         sq.domain.com;

    ssl_certificate     /etc/nginx/ssl/certchain;
    ssl_certificate_key /etc/nginx/ssl/sq.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
    add_header Strict-Transport-Security "max-age=31536000;includeSubDomains;preload" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Forwarded-Login $http_remote_user always;
    add_header X-Forwarded-Name  $http_user_display_name always;
    add_header X-Forwarded-Email $http_remote_user always;
    underscores_in_headers on;

    #charset koi8-r;
    access_log  /var/log/nginx/sq.access.log main;
    error_log   /var/log/nginx/sq.error.log debug;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    location /sonar {
        proxy_pass http://sq.domain.com:9090/sonar;
    }

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

I am not sure if my nginx configuration is correct. Though HTTPS works just fine.

Thanks,

Hongyuan

12

Hello Hongyuan,

I will message you privately to share some logs. I would like to confirm what you are seeing before proceeding.

13

Actually, going back to your curl example:

Can you make sure to add the -L flag so that it follows the redirect?

Also:

You changed the login, but not the External Provider. Are you trying to convert a local user’s login? This will not convert an LDAP user to SAML user. Do you want to convert an LDAP user to a SAML user?

15

Hello @Joe,

I didn’t get any message from you. Did you send it to david.hy.yi@gmail.com?

I am not using SAML. Instead I am trying to use HTTP Header Authentication for SSO integration. The key for the Identity Provider HTTP Header Authentication is “sonarqube”. Since my current key is “sonarqube” already, so I didn’t change it.

image
image646×328 20.3 KB

I am currently using LDAP for authentication. My current external provider should be LDAP_Default, but for some reason, it is “sonarqube”. I don’t know why. I have about 307 users, and all of them are using LDAP integration, but only about 67 of them have LDAP_default as their external provider. The rest have “sonarqube” as their external provider.

Should I change it to LDAP_default and then back to sonarqube?

Also when using HTTP Header Authentication, do users still need to click “log in” to be authenticated? When I tried it, I see the following in the web.log:

2024.11.19 07:44:20 DEBUG web[AZNFF9+RsNlJO+nAAAAQ][auth.event] login failure [cause|User is not local][method|FORM][provider|LOCAL|local][IP|x.x.x.x|][login|david.yi@domain.com]

I tried to delete myself to make myself a new user, and it doesn’t work either:

2024.11.19 08:36:14 DEBUG web[AZNFQPbG8LjQI7j5AABk][auth.event] login failure [cause|No active user for login][method|FORM][provider|LOCAL|local][IP|x.x.x.x|][login|david.yi@domain.com]

Regarding your comment about the curl command, I tried the following today:

curl -L -X POST -u squ_xxx: 'https://sq.domain.com:9191/sonar/api/users/update_login?newLogin=a.bc@domain.com&login=abc'

{"errors":[{"msg":"User \u0027abc\u0027 doesn\u0027t exist"}]}

curl -L -X POST -u squ_xxx: 'https://sq.domain.com:8443/sonar/api/users/update_login?newLogin=a.bc@domain.com&login=abc'

The port 8443 is to reach the external identity provider. Once the authentication is done, it will pass to the Nginx server on the port 9191. The user login has been changed from “abc” to its email address, so the first curl works as expected, but the second curl command doesn’t seem to work.

Thanks,

Hongyuan