We’ve setup SonarQube internally, and configured OKTA SAML.
Port 80 redirects to port 443.
When logging in via SAML, we get
You’re not authorized to access this page. Please contact the administrator.
Reason: The response was received at http://sonarqube.internal.io/oauth2/callback/saml instead of https://sonarqube.internal.io/oauth2/callback/saml
From Sonar, when I test the SAML config, I get a green “success” for SAML Authentication Test.
Hey there.
What are you using to serve SonarQube over HTTPS (a reverse proxy like IIS, Nginx, httpd…)?
We have now added NGINX, but we get a different error:
You’re not authorized to access this page. Please contact the administrator.
Reason: This account is already associated with another authentication method. Sign in using the current authentication method, or contact your administrator to transfer your account to a different authentication method.
The setup is as:
NLB (443) → NGINX (443) → Sonar (9000)
We are using nginx installed on the same EC2 instance as SonarQube with the following config:
server {
listen 80;
listen [::]:80;
server_name sonarqube.internal.io;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
client_max_body_size 100M;
server_name sonarqube.internal.io;
ssl_certificate /etc/ssl/certs/sonarqube.crt;
ssl_certificate_key /etc/ssl/private/sonarqube.key;
access_log /var/log/nginx/sonarqube.access.log;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-SSL on;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto https;
proxy_pass http://127.0.0.1:9000;
proxy_redirect off;
}
}
Our Architecture consists of an NLB with a listener on TCP 443 - which points to the SonarQube instance target group.
When we test the SAML config from Sonar side, it works.
But when we login via OKTA, it fails.
Is there an A-Z documented setup on how to set up SonarQube Enterprise with SSL using NLB on AWS infrastructure using terraform?
Hey there.
It looks like you’ve passed the SAML issue and now face another issue.
Are you already using SonarQube with another delegated authentication method (such as LDAP) which you’re transitioning away from?
No, its an out of the box setup. I even deactivated the account I was logging in as, and tried again. No luck.
Hi @RoMB2tK4J7LQ3h ,
Does the user you’re trying to login with via SAML already exist as a local user?
If that is the case, you will have to update the identity provider of the user using POST api/users/update_identity_provider endpoint using saml as a value of the newExternalProvider and and the value of the login of the user in Okta(most likely email) as newExternalIdentity.
Hi Wojciech, I deleted the user I was testing with, so I am not sure that applies.
Does deactivating (deleting) the user actually delete the user?
For now we are using a half baked solution, using OKTA’s LDAP endpoint, and we’ve configured sonar.properties ldap to work with it, but its about 10-12 second slow when logging in, i.e. from AWS Cloud to OKTA cloud LDAP auth over TLS.
There is a manual and step by step on how to setup a new server (e.g. community) on AWS with OKTA integration, that would be great.
If you select the option to Delete user's personal information, the account is deleted.
Otherwise, deactivating only removes the some of the user data e.g. email address and marks the user as deactivated.
Either way, the user should still be able to log in.
If you deactivate the user, does the error message still say This account is already associated with another authentication method.? It should not be the case for a deactivated user.
We have a guide about setting up SAML with Okta, the cloud provider used makes no difference for the set up of SAML.