Hi all, I have a white labelled domain that I am struggling to use with the login gdc API endpoint. The overarching use case is to enable SAML SSO and execute step 2 of configuring the SSO provider in the Service Provider-initiated scenario. I am attempting to get TTs/SSTs so I can use the SSO Providers API endpoints however I am getting 405 not allowed at this endpoint when using the correct JSON body and the only admin user and password of the GoodData instance. Feel like I'm doing something wrong here - any help would be appreciated.

Hello Paiwand, the likely reason here seems to be that you are trying to set up authentication for different product. From what I can see, you are using documentation for GoodData Platform product, while your subscription seem to be for newer product - GoodData Cloud. How to set up authentication in GoodData Cloud is described in this part of documentation.

Hi Marek, Thanks for the clarification. Could you assist in troubleshooting the PUT Organization endpoint? /api/v1/entities/admin/organizations/:id I am getting the following output:

{
  "detail": "The requested endpoint does not exist or you do not have permission to access it.",
  "status": 404,
  "title": "Not Found",
  "traceId": "90ad8f1c0bf7b1f9230d233ec2ea8e3d"
}

using this body

{
  "data": {
    "id": "localis",
    "type": "organization",
    "attributes": {
      "allowedOrigins": [],
      "earlyAccess": "",
      "hostname": "<http://app.localis.co|app.localis.co>",
      "jitEnabled": false,
      "name": "Localis",
      "oauthClientId": "clientId",
      "oauthClientSecret": "ClientSecret",
      "oauthIssuerId": "auth0",
      "oauthIssuerLocation": "<https://localis.au.auth0.com>",
      "oauthSubjectIdClaim": "sub"
    }
  }
}

Hi Paiwand, I can’t validate this myself, however are you using correct organization id? Org id. is typically not readable word and do not correspond with your hostname. You can find your organization ID in your GD welcome email.

That was it 🙂 thanks

Sorry @Paiwand Karem, JIT provisioning is bit beyond my experience but I have notified colleagues who would be better suited to help

Hi Paiwand, Auth0 is a 3rd party provider, so it's a bit out of our scope, but I was doing some testing, so I can share some findings: You have following claims that we need in the ID token:

sub
given_name, family_name
email
urn.gooddata.user_groups

sub - it's always there, it's the unique identifier of the user in your auth0 tennant given_name, familiy_name - I was surprised because it seems that there's no easy way to add these through UI, but they are standard user parameters, that could easily be added through user API email - should be there always as it's a needed parameter when creating the user urn.gooddata.user_groups - this is a custom claim and it was only one that's not straightforward - only way we found is indeed through actions in auth0 and we haven't found a mention of any other way in their documentation/forums

Hey Boris, thanks for that. Yeah I'm a bit stumped as I'm looking for a way to send back that information to GoodData so it can be used for a user signup though I cannot find any place that actually shows how to edit that token. It seems like it is already handled with the SSO side of things when someone uses Google for example on the Auth0 portal sitting on top of the whitelabelled GoodData instance. I would've thought that token is what Auth0's actions handles. though I cannot get past the login screen despite having handled those inputs via Actions in their UI. It seems like there is no intuitive way to edit that token that is supposedly sent back as it is apparently outside the realm of Auth0 actions...

the OIDC works in a way that (SP) GoodData will request scopes that should be in the ID token and the IdP (auth0) will send the claims that are part of these scopes in the ID token. You basically just need to make sure that the required parameters are part of the users data. You mention that you cannot get past the login screen - what excatly do you mean? Because the JIT still requires the user to be logged in to auth0 tennant, it will just provision the user to gooddata if it already isn't there....

I get an empty page and no provisioned users

okay, that's quite self explaining.... these need to be added through auth0 user API: https://auth0.com/docs/api/management/v2/users/patch-users-by-id

I see, thank you

One option is to do some custom registration form using API (or maybe some native functionality of auth0) Second option is to have some automation to fill these parameters (with either dummy values or parsing the name property), which is maybe possible through actions

Alright, I'll have a play around, appreciate the pointers. While I have your attention as well - the moment I switched from GoodData's auth0 instance to our own, I seemed to lose access (at least via UI and the current auth0 setup) to the account provisioned by the support team that had admin access.

{
            "id": "2f3faa2a-1427-43d4-839e-1067961ab83f",
            "type": "user",
            "attributes": {
                "authenticationId": "google-oauth2|114876045742542820210",
                "firstname": "Paiwand",
                "lastname": "Karem",
                "email": "paiwand@localis.co"
            },
            "links": {
                "self": "<https://app.localis.co/api/v1/entities/users/2f3faa2a-1427-43d4-839e-1067961ab83f>"
            }
        },
   {
            "id": "paiwand",
            "type": "user",
            "attributes": {
                "authenticationId": "auth0|66336fecad53dc15b4cce02a",
                "email": "paiwand@localis.co"
            },
            "links": {
                "self": "<https://app.localis.co/api/v1/entities/users/paiwand>"
            }
        }

You can see there are now two accounts with the same email with the latter being the one provisioned by the support team for my original access. It's associated the same email to our new auth0 instance and did not translate across anything else (probably due to the current user provisioning setup being incorrect). I do still have the original accounts API token and am using that to interact with the API. Is there an endpoint to grant this new user admin access?

Hi Paiwand, the parameter used for matching the user is the authenticationId so the value

auth0|66336fecad53dc15b4cce02a

which points to our auth0 needs to be replaced with id from your own auth0 (be sure to use

?include=userGroups

parameter when updating the user, in order to not lock them out of admin group and losing access for your api token)