SAML IDP Initiated Login

I’m not seeing this in the SAML plugin documentation, how do we initiate login from the IDP -> Sonarqube? If we set the SSO URL as https://sonar.mycompany.com/oauth2/callback/saml we receive the error message:

You're not authorized to access this page. Please contact the administrator.

Reason: Cookie 'OAUTHSTATE' is missing

when we try to initiate login from our IDP (in our case Okta). Is there a different URL that we should be trying instead, or is this functionality not currently present in the SAML plugin? Logging in from the Sonarqube login page works so we know that everything else is configured correctly. Sonarqube is the only application we have that we haven’t been able to get IDP initiated login working from.

1 Like

UPDATE: see below. Firefox user error on my part.

I get this issue as well.

I wind up having to manually visit https://sonar.example.com/ in order to use SonarQube after a SAML login. It doesn’t always happen, but when it does it’s very confusing for my users.

UPDATE: see below. Firefox user error on my part.

I just got this to occur in an SP initiated flow from https://sonar.example.com/sessions/init/saml?return_to=%2F.

After SAML login I’m redirected to https://sonar.example.com/sessions/unauthorized?message=Cookie+‘OAUTHSTATE’+is+missing

If I manually visit https://sonar.example.com/ after the login has worked and I can see private projects again.

It only appears to happen after inactivity (maybe session timeout).

If I explicitly log out and then visit https://sonar.example.com/sessions/init/saml?return_to=%2F, it also happens consistently.

If I explicitly log out, then visit https://sonar.example.com/sessions/new, then click Log In with SAML it logs in without issues.

Hi,

Sorry for the late replay, it seems that Okta is not returning the value sent into the parameter RelayState when initiating SSO process.
Would you be able to verify if the URL sent from Okta to SonarQube contains or not this parameter ?

Regards

1 Like

This was a Firefox thing for me.

I dug a little deeper, and it turned out to be a really odd interaction with Container tabs in Firefox. I was opening https://sonar.example.com/sessions/init/saml?return_to=%2F in a non-Container tab, but my SAML IdP domain was set to always open in my Work Container. As a result it lost the OAUTH_STATE cookie set by /sessions/init/saml after it went to load the IdP.

The flow is like this:

  1. (no Container) visit https://sonar.example.com/sessions/init/saml?return_to=%2F
  2. (no Container) load response (including OAUTHSTATE cookie) and redirect to IdP URL with SAMLRequest
  3. (Work Container) IdP URL is set to always open in the Work Container so browser loads it here
  4. (Work Container) load response and redirect to https://sonar.example.com/oauth2/callback/saml (with no OAUTHSTATE cookie)
  5. (Work Container) redirect to OAUTHSTATE cookie missing error page

The fix is to set the sonar.example.com domain and the IdP domain to open in the same Container (in my case, Work). It also works if neither Sonar nor the IdP domain are set to use Container tabs. I tried with distinct Container tabs and it doesn’t work.

IdP-initiated logins are not supported. You need to use an SP-initiated login URL like https://sonar.example.com/sessions/init/saml?return_to=%2F.

In Okta, I use a bookmark app for this.

SonarQube explicitly sets an OAUTHSTATE cookie when the SP-initiated login URL is visited and checks for that cookie when the SAMLResponse is posted to the ACS (Assertion Consumer Service) URL at https://sonar.example.com/oauth2/callback/saml. It is not possible to set a working OAUTHSTATE cookie from an IdP-initiated login flow.

I was able to get it working using a bookmark app in Okta.

1 Like

Thanks for explaining the solution @AlainODea !

1 Like

Hello @julienlancelot,

To use this bookmark cannot be a solution.
Do you have another idea how we can fixed? Or another workaround?

1 Like

I second @qalinn - can we get some work on this to make it more seamless? A bookmark app on Okta isn’t a solution, it’s a hack. What can we do as a community to help support this change?

Hello!

Could you elaborate? Sorry I’m a bit ignorant on this one. I think I have the same problem with Keycloak.

I’ve configured Sonarqube via the SAML plugin via: https://docs.sonarqube.org/latest/instance-administration/delegated-auth/, and by doing so… I get the redirection to the IDP/Keycloak page… however after I l ogin, I get the same error.

I’m uncertain of what you mean for your solution?

Hi Julien,

Could you please help us with the correct RelayState value that must be configured in Okta for the correct work of SSO from Okta dashboard?

Thanks

Hi Ivan,

I don’t know how Okta is working so I’m not able to help you.
I’ve created a JIRA ticket https://jira.sonarsource.com/browse/SONAR-12688 to solve this issue.

Regards

Hi Julien,
Thanks for your reply and the ticket!

SAML auth is working correctly with Okta during login process from the default SonarQube page (https://sonarqube.example.com/sessions/init/saml?return_to=%2F).
But I have this issue related to cookies during login from the IdP side (Identity Provider).
From my understanding, the root cause of the issue is that Okta doesn’t set OAUTHSTATE cookie during request to the SonarQube instance. But the cookie generates during login that initiated by SP (Service Provider).

You can take a look at the attached screenshots and compare cookies.

In fact the cookie “OAUTHSTATE” is created by SonarQube when the parameter RelayState is correctly feed in HTTP response during callback.
I’ve no idea why Okta didn’t set this parameter…

Yes, it’s more complex than I thought before)
Thanks for your reply, Julien.
In my opinion, it would be nice to update the Jira ticket with more details from our discussion

I figured out a hack to fix this (instead of using the Bookmark app suggested above).
I’ve basically configured a redirect from /sessions/unauthorized to /sessions/init/saml?return_to=%2F
And it worked just like any other login through IdP!
This redirection should be doable on any HTTP proxy server like Nginx. But in my case, I used added a redirection rule on AWS application Load Balancer. The load balancer redirection configuration is as shown in the below screenshot:


Hope this helps out someone stuck with this issue.

Hi Sharat,

I have tried with this. Not working for me. Getting 404 error

https://qitsonarqube.honeywell.com/sonarqube/sessions/saml/init/saml?return_to=%2F%sonarqube

Can you assist with the above.

Thanks !!
Manoj

Hi Julien,

We have integrated Sonarqube with PingFederate IDP .Getting an error while login.
Logs below:

2020.04.17 11:06:09 DEBUG web[AXGDNwSHGiojiL7hAAQL][c.o.saml2.Auth] processResponse success --> PHNhbWxwOlJlc3BvbnNlIFZlcnNpb249IjIuMCIgSUQ9InVkZy1uckxMV2suQ3J2NjEyaHdmU0pyc1JfcCIgSXNzdWVJbnN0YW50PSIyMDIwLTA0LTE3VDExOjA2OjA4LjkyNloiIHhtbG5zOnNhbWxwPSJ1
2020.04.17 11:06:09 TRACE web[AXGDNwSHGiojiL7hAAQL][sql] time=1ms | sql=select p.prop_key as "key", p.is_empty as empty, p.text_value as textValue, p.clob_value as clobValue, p.resource_id as resourceId, p.user_id as userId from properties p where p.prop_key=? and p.resource_id is null and p.user_id is null | params=sonar.auth.saml.providerName
2020.04.17 11:06:09 DEBUG web[AXGDNwSHGiojiL7hAAQL][auth.event] login failure [cause|CSRF state value is invalid][method|OAUTH2][provider|EXTERNAL|SAML][IP|10.120.3.58|10.68.132.131][login|]
2020.04.17 11:06:10 TRACE web[AXGDNwSHGiojiL7hAAQM][o.s.s.u.UserSessionFilter] Thread[http-nio-0.0.0.0-9000-exec-4,5,main] serves /sonarqube/sessions/unauthorized
2020.04.17 11:06:10 TRACE web[AXGDNwSHGiojiL7hAAQN][o.s.s.u.UserSessionFilter] Thread[http-nio-0.0.0.0-9000-exec-5,5,main] serves /sonarqube/api/navigation/global

This is in browser
You’re not authorized to access this page. Please contact the administrator.
Reason: CSRF state value is invalid
Can you help
Thanks!!
Manoj

Have you added the redirection rule in AWS ALB? And you using the default SAML plugin that is available for free in Sonarqube?