No provider key found in URI

  • Using SonarQube 7.3
  • Attempting to use SAML authentication using PingFed IdP
    ** Have configured IdP to to issue the SAML assertion
    ** Have configured SonarQube according https://docs.sonarqube.org/display/PLUG/SAML+Authentication+Plugin
    ** Configured Assertion Consumer Service URL to :9000/oauth2/callback (???)
    ** When assertion is posted to that URL SonarQube responds with “You’re not authorized to access this page. Please contact the administrator.”

The web.log in TRACE mode mysteriously informs “No provider key found in URI” (see below).
TIA for any help deciphering this.

2018.09.24 11:58:22 DEBUG web[][j.m.mbeanserver] ObjectName = Tomcat:type=RequestProcessor,worker=“http-nio-0.0.0.0-9000”,name=HttpRequest1
2018.09.24 11:58:22 DEBUG web[][j.m.mbeanserver] name = Tomcat:type=RequestProcessor,worker=“http-nio-0.0.0.0-9000”,name=HttpRequest1
2018.09.24 11:58:22 DEBUG web[][j.m.mbeanserver] Send create notification of object Tomcat:name=HttpRequest1,type=RequestProcessor,worker=“http-nio-0.0.0.0-9000”
2018.09.24 11:58:22 DEBUG web[][j.m.mbeanserver] JMX.mbean.registered Tomcat:type=RequestProcessor,worker=“http-nio-0.0.0.0-9000”,name=HttpRequest1
2018.09.24 11:58:23 TRACE web[AWYMTZVq0onP1Ft3AAAA][o.s.s.u.UserSessionFilter] Thread[http-nio-0.0.0.0-9000-exec-1,5,main] serves /oauth2/callback
2018.09.24 11:58:23 ERROR web[AWYMTZVq0onP1Ft3AAAA][o.s.s.a.AuthenticationError] No provider key found in URI
2018.09.24 11:58:23 TRACE web[AWYMTZVq0onP1Ft3AAAB][o.s.s.u.UserSessionFilter] Thread[http-nio-0.0.0.0-9000-exec-2,5,main] serves /sessions/unauthorized
2018.09.24 11:58:23 TRACE web[AWYMTZVq0onP1Ft3AAAC][o.s.s.u.UserSessionFilter] Thread[http-nio-0.0.0.0-9000-exec-3,5,main] serves /api/l10n/index

I’m having the same issue.

I get a little further by using /oauth2/callback/sonarqube, but then it fails saying this:
Failed to retrieve IdentityProvider for key ‘sonarqube’
java.lang.IllegalArgumentException: Identity provider sonarqube does not exist o
r is not enabled
at org.sonar.server.authentication.IdentityProviderRepository.getEnabled
ByKey(IdentityProviderRepository.java:54)
at org.sonar.server.authentication.AuthenticationFilter.resolveProviderO
rHandleResponse(AuthenticationFilter.java:56)
at org.sonar.server.authentication.OAuth2CallbackFilter.doFilter(OAuth2C
allbackFilter.java:68)
at org.sonar.server.platform.web.MasterServletFilter$GodFilterChain.doFi
lter(MasterServletFilter.java:126)
at org.sonar.server.platform.web.MasterServletFilter.doFilter(MasterServ
letFilter.java:95)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.sonar.server.user.UserSessionFilter.doFilter(UserSessionFilter.java:87)
at org.sonar.server.user.UserSessionFilter.doFilter(UserSessionFilter.java:71)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
… lots of stacktrace

I suspect learning what to put in for providerKey in this URI /oauth2/callback/{providerKey} would solve this.

I figured it out. It’s /oauth2/callback/saml not /oauth2/callback… This is a documentation bug.

I had to clear cookies for my sonarqube domain to make login work after some testing. You may get CSRF or OAUTH_TOKEN errors otherwise.

Here are settings that work for Okta:

Attribute Statements

  • login = user.login
  • name = user.login
  • email = user.email

Group Attribute Statements

  • groups Starts with: example-internal:sonarqube-

Corresponding settings in SonarQube (https://sonarqube.example.com/admin/settings?category=saml)

  • sonar.auth.saml.applicationId = sonarqube
  • sonar.auth.saml.providerName = SAML
  • sonar.auth.saml.providerId = entityId from SAML metadata, aka Identity Provider Issuer URI
  • sonar.auth.saml.loginUrl = HTTP-POST binding location from SAML metadata, Identity Provider Single Sign-On URL
  • sonar.auth.saml.certificate.secured = X509Certificate text in KeyInfo use=signing from SAML metadata, X.509 Certificate
  • sonar.auth.saml.user.login = login
  • sonar.auth.saml.user.name = name
  • sonar.auth.saml.user.email = email
  • sonar.auth.saml.group.name = groups
1 Like

A post was split to a new topic: Synchronize groups using SAML authentication on Okta

Thanks for finding this ! In Keycloak it was working without appending saml, but it will also work with it so I’ve updated the documentation.

2 Likes

Hi Team,

I have all the configuration properly as mentioned above. But seeing the following errors. Can you please suggest.

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

Reason: Cookie ‘OAUTHSTATE’ is missing
"

web.log:2019.08.02 17:35:03 DEBUG web[AWxStCuWuJXEkokKABYI][auth.event] login failure [cause|Cookie ‘OAUTHSTATE’ is missing][method|OAUTH2][provider|EXTERNAL|SAML][IP|10.0.4.247|10.0.2.171][login|]

web.log:2019.08.02 17:28:33 DEBUG web[AWxStCuWuJXEkokKABUA][auth.event] login failure [cause|CSRF state value is invalid][method|OAUTH2][provider|EXTERNAL|SAML][IP|10.0.4.247|10.0.2.171][login|]

Thanks for your time,
Hanumanth

Has anyone figured out the “OAUTHSTATE” error? IdP initiated login fails on this error for me every time, and it is preventing me from deploying the Sonarqube with SSO to more of my users.

If you’re using Okta, then it seems it’s not working for the moment : https://jira.sonarsource.com/browse/SONAR-12688

Correct, I’m using Okta. I can engage support for help if this is an issue in the Okta side (but it seems to be an issue with the current plugin). Is there an ETA for when this will be fixed?

There’s no ETA for this issue to be fixed. If you have time, you can help us by trying to understand why he HTTP parameter “RealState” is not send in the request.

Hey Julien,

Are you referring to the “RelayState”? By default, the RelayState property is blank, unless specified manually. What relay state would SonarQube expect for an IdP-initiated login? Is the solution as simple as supplying a default relay state?

Taylor

In fact, the SAML authentication is setting a random value in the “RelayState” HTTP parameter and in a cookie before the call to the IdP-initiated login.
Then, during the callback, SonarQube expects to receive this value in the “RelayState” HTTP response, and check that the value is the same than the one in the cookie.

When using Okta, there seems to be no “RelayState” HTTP response during the callback.

Hello,

Is there a way that you can assist with the below issue.

Thank you!!
Manoj

+We are using PingFederate IDP