Hi all I hope you are in good health. I am experiencing an issue with good data integeration. I have enabled JIT (Just-in-Time) provisioning in my GoodData organization settings with the following request:

{
  "data": {
    "attributes": {
      "content": {
        "enabled": true,
        "userGroupsScopeEnabled": true,
        "userGroupsScopeName": "urn.gooddata.scope/user_groups",
        "userGroupsClaimName": "urn.gooddata.user_groups",
        "userGroupsDefaults": []
      },
      "type": "JIT_PROVISIONING"
    },
    "id": "jitProvisioning",
    "type": "organizationSetting"
  }
}

The organization settings have been successfully updated. I have also assigned workspaces to user groups. Issue: I am now sending the

urn.gooddata.user_groups

claim with the user groups assigned to the users. I have verified that: 1. The JWT token contains the groups under

urn.gooddata.user_groups

. 2. I also added the groups under

urn.gooddata.scope/user_groups

. However, when integrating the iframe in our web app, I am still getting a 401 Unauthorized error. Questions: 1. Is there any additional configuration required in GoodData settings to ensure user group-based provisioning works correctly? 2. Could there be any issue with the JWT structure, such as missing other scopes or claims that GoodData expects?

Hi Siraj, Thank you for reaching out to us. I recommend checking our documentation on setting up JIT User Provisioning. Additionally, you mentioned experiencing an error. Could you please provide the time window when the error occurred? If possible, sharing a TraceID related to the error would be very helpful. I will keep you updated.

Hi, It gives 401 Unauthenticated error. Date: Fri, 28 Feb 2025 073707 GMT There is no trace id etc.

Hi Siraj, Thank you for the information. We found some errors, but they were not very informative for us. We still need more context. Does the issue occur only within the iframe, or does it also happen when logging into your Cloud environment directly? Could you please provide a screenshot or, even better, a short video of the behavior? Feel free to send it via DM. Additionally, a HAR file would be helpful as well. Thank you in advance for your cooperation.

But in that case how will we use the JIT User provisioning? If I create the user via api or gooddata UI it works but not for JIT User provisioning.

In order for the configured settings to take effect, you will first need to disable it as currently the old setting take precedence over the new setting until we fully deprecate it.

Hi, I have used the api: {{baseUrl}}/api/v1/entities/admin/organizations/:id to set the jitEnabled to false. Then used the new api {{baseUrl}}/api/v1/entities/organizationSettings/:id to set the attribute to enabled using the request below.

{
  "data": {
    "attributes": {
      "content": {
        "enabled": true,
        "userGroupsScopeEnabled": true,
        "userGroupsScopeName": "urn.gooddata.scope/user_groups",
        "userGroupsClaimName": "urn.gooddata.user_groups",
        "userGroupsDefaults": [
          "defaultUserGroup"
        ]
      },
      "type": "JIT_PROVISIONING"
    },
    "id": "jitProvisioning",
    "type": "organizationSetting"
  }
}

But it still shows the same error.

Good morning Siraj. I am an engineer at GoodData and am helping to take a look at this now.

Good Morning, That was not intentional, I think it was a mistake, I updated it back.

I am seeing this in our logs:

An error occurred while attempting to retrieve the UserInfo Resource from '<https://login.n3o.cloud/userinfo>': response contains invalid content type 'text/html'. The UserInfo Response should return a JSON object (content type 'application/json') that contains a collection of name and value pairs of the claims about the authenticated End-User. Please ensure the UserInfo Uri in UserInfoEndpoint for Client Registration conforms to the UserInfo Endpoint, as defined in OpenID Connect 1.0: '<https://openid.net/specs/openid-connect-core-1_0.html#UserInfo>'

Do I need to change the Auth0 credentials back to the old application? we want to use the new application.

No, that's okay. Just making sure that was not also unintentional.

All the profile claims are there in the jwt token already.

Happy to hear it. Curious as it may help in future situations, was there a change on your end in Auth0? Or it just started working?

I did not make any change except the one (Issuer Location) that was not intentional and identified above.

Okay, now on to JIT. I want to be sure I'm understanding correctly. You are trying to use JIT with JWT, not JIT with OIDC login (via configured oauth provider). Is this correct?

Yes you are right.

Okay, well I think therein lies the issue. JWT + JIT is not something we support. We only support OIDC + JIT. Our documentation on JIT is in the OIDC section only for this reason, with the JWT documentation not mentioning it. Rather, the JWT documentation explains the only way in which it works, which is to first create a user and then create a JWT using the

userId

of that user as the

sub

claim.

Hi Siraj, We apologize for any inconvenience this may have caused. As Christopher mentioned, support for JSON Web Tokens (JWT) and Just-In-Time (JIT) is currently unavailable. We have submitted product feedback on your behalf requesting support for these features. To help us better understand your needs, could you please provide more details about how this issue is impacting your organization? We will make sure to include your feedback in our submission. At this time, we cannot provide an estimated time of arrival (ETA) for their implementation. However, you can stay updated on the latest features by following our release notes for GD Cloud. If you need further assistance, please let us know.

I was following this article. I think its my mistake to say JIT with JWT. I think we are creating the user first in OIDC provider which is Auth0 in our case. We are sending all the required claims as well in the jwt token. I am following this article below, I intercepted the jwt token which has all these claims as well. https://www.gooddata.com/blog/just-in-time-user-provisioning/#

Hi Siraj, no problem. May I ask once more if you can share with us a screenshot or video pointing out the issue? or if you can provide more details about it. Maybe explain once more, because we got a bit loss in this.

That call was from gooddata, when it tried to get the token for authentication, During the flow they also tried to retrieve the userinfo from auth0. After the access token is retrieved this is supplied to the user info endpoint of the Auth0 to get the user info. Auth0 was not accepting the header with too many claims.