Multiple OIDCs

You can set up specific OIDC providers to be supported in your organization. Whether your company uses different providers or your tenants want to use their own, the Multiple OIDC (MOIDC) feature makes it possible. It allows users to access GoodData using their external identity provider credentials (also known as identity federation), eliminating the need for separate credentials.

Authentication Logic

Enabling multiple identity providers requires a slight change in the authentication process. Here is how it works once everything is set up:

When an unauthenticated user tries to access your organization, they are redirected to a simple login page and asked for their email address. Based on the email suffix (e.g., for example@gooddata.com, the email suffix is gooddata.com), we determine which provider is responsible for the user’s authentication and redirect them there. Once authenticated, they can access the GD platform.

Users can be mapped from each provider using Just-In-Time (JIT) User Provisioning or the API process as described in the Create a User section.

JIT Provisioning Enabled

If a user does not exist in your organization (usually the first time they try to access it), their account is created automatically during authentication.

JIT Provisioning Disabled

If you create a user with the correct authenticationId from the provider, they will be mapped correctly once they log in. If a user does not exist or has an incorrect authenticationId, their account will not be created automatically, and they will receive a 401 Unauthorized error.

Dedicated Super Admin Provider

Once this feature is set up, we will provide you with the API for managing the OIDC providers (more details below). Create a dedicated super admin identity provider that authenticates admins managing identity providers. These admins can add, edit, or delete any identity provider using this API.

To ensure maximum security, a completely separate authentication flow is applied to these management APIs. The authentication flow of the MOIDC management APIs goes against your own dedicated super admin identity provider. This OIDC provider of your selection will be used for authentication to the MOIDC APIs only. Our support team will ask you to provide the details of this super admin IDP during the initial setup of the MOIDC feature.

Setting Up Multiple OIDCs

To set up multiple OIDC providers, follow these steps:

1. Contact Support: Reach out to our support team to enable this feature and inform them whether you want to use JIT provisioning. The support team will assist with the initial setup.

   You will need to provide us with the following details of the dedicated super admin provider:

   • Issuer
   • Client ID
   • Client secret

   Additionally, we will need the following details of your current identity provider (IDP):

   • Client secret

   • Unique identifier(s) valid for login via identity provider

     The identifier is a domain name used to direct users to the correct provider for authentication. For example, an organization is configured for MOIDC with two providers: Okta and Auth0. Okta’s identifier is gooddata.com and Auth0’s is example.com. If User A enters UserA@example.com on the login page, then, based on their email, the authentication request is sent to Auth0.

     At least one identifier must be specified, but no more than 50. Each identifier must have a minimum length of 1 and a maximum length of 40. Additionally, each identifier must adhere to the following pattern: [\w\s+=.@-]+.

   By default, the user claim in the ID token is set to sub. If your super admin or existing provider uses a different user claim, inform our Support team during the initial setup. When registering such provider, you can add oauthSubjectIdClaim to the attributes in the payload with the desired string value. For example, if your provider uses uid instead of sub, set oauthSubjectIdClaim to uid in the attributes.

   Encrypt Client Secrets

   We strongly recommend encrypting the Client Secrets to prevent unauthorized access. You can use the GoodData PGP key or another encryption method. For guidelines on encrypting a document using PGP, see the GNU Privacy Handbook.

2. Configure Authentication:

   • Our support team will give you a new sign-in redirect URI.
   • Register this URI in your current OIDC provider and use it in any providers you add to your authentication flow in the future.
   • Regardless of whether you are using JIT provisioning or not, add the GoodData custom scope (urn.gooddata.scope/user_groups) to your current provider and any providers you add to your authentication flow in the future.
   • If using JIT provisioning, modify the ID token sent by your OIDC provider to contain the urn.gooddata.user_groups claim (a GoodData-specific claim used for user group membership definition). This claim will now be requested by the urn.gooddata.scope/user_group scope during the new authentication flow. See JIT provisioning for more details.
   • Each OIDC provider should be configured to use Client Secret (sometimes referred to as Client Secret Post) as the authentication method.

3. Configure the Super Admin Identity Provider:

   • Our support team will give you a new sign-in redirect URI.
   • Register this URI in your OIDC provider.
   • Set the aud (Audience) claim to gdc-management-api in the provider’s API/authorization settings. The aud claim identifies the intended recipients of the JWT. Each recipient must have a value in the aud claim. If not, the JWT must be rejected. The aud value can be:
     • An array of case-sensitive strings (StringOrURI values).
     • A single case-sensitive string (StringOrURI value) if there’s only one audience.

After the initial setup, your organization will have one federated provider (the one you’ve been using) and a separate one for super admin authentication. You will then have access to APIs for OIDC management, allowing you to manage federated providers independently.

MOIDC Configuration

The management API has its own URL (admin.cloud.gooddata.com), common across all organizations. The management API is secured using the super admin identity provider and Bearer (token) authentication for the HTTP authentication scheme. With a valid Bearer token, you can access the management API by adding this Authorization header to every request you make:

Authorization: Bearer <TOKEN>

Example:

curl -X GET 'https://admin.cloud.gooddata.com/api/v1/moidc/oidcs' \
-H "X-GDC-Organization-Id: example-org" \
-H "Authorization: Bearer 3xampl3T0k3n"

Register an OIDC Provider

To register a new OIDC provider, send a POST request to the /api/v1/moidc/oidcs API endpoint with the following payload:

{
  "data": {
    "id": "string",
    "attributes": {
      "attributesRequestMethod": "string", // (GET/POST)
      "attributesUrl": "string",
      "authorizeUrl": "string",
      "clientId": "string",
      "clientSecret": "string",
      "jwksUri": "string",
      "oidcIssuer": "string",
      "tokenUrl": "string",
      "idpIdentifiers": ["string"]
    }
  }
}

Response:

{
  "data": {
    "id": "string",
    "attributes": {
      "attributesRequestMethod": "string", // (GET/POST)
      "attributesUrl": "string",
      "authorizeScopes": ["string"],
      "authorizeUrl": "string",
      "clientId": "string",
      "jwksUri": "string",
      "oidcIssuer": "string",
      "tokenUrl": "string",
      "idpIdentifiers": ["string"]
    },
    "links": {
      "self": "http://example.com"
    }
  }
}

Example:

{
  "data": {
    "id": "auth0Provider1",
    "attributes": {
      "attributesRequestMethod": "GET",
      "attributesUrl": "https://auth.example.com/userInfo",
      "authorizeUrl": "https://auth.example.com/authorize",
      "clientId": "1example23456789",
      "jwksUri": "https://auth.example.com/.well-known/jwks.json",
      "oidcIssuer": "https://auth.example.com",
      "tokenUrl": "https://example.com/token",
      "idpIdentifiers": ["gooddata.com"]
    }
  }
}

List OIDC Providers

To get a list of all OIDC providers for your organization, send a GET request to the /api/v1/moidc/oidcs API endpoint.

Example Response:

{
  "data": [
    {
      "id": "string",
      "attributes": {
        "attributesRequestMethod": "string", // (GET/POST)
        "attributesUrl": "string",
        "authorizeScopes": ["string"],
        "authorizeUrl": "string",
        "clientId": "string",
        "jwksUri": "string",
        "oidcIssuer": "string",
        "tokenUrl": "string",
        "idpIdentifiers": ["string"]
      },
      "links": {
        "self": "http://example.com"
      }
    },
    {
      "id": "string",
      "attributes": {
        "attributesRequestMethod": "string", // (GET/POST)
        "attributesUrl": "string",
        "authorizeScopes": ["string"],
        "authorizeUrl": "string",
        "clientId": "string",
        "jwksUri": "string",
        "oidcIssuer": "string",
        "tokenUrl": "string",
        "idpIdentifiers": ["string"]
      },
      "links": {
        "self": "http://example.com"
      }
    }
  ]
}

Get a Specific OIDC Provider

To see the details of a specific OIDC provider, send a GET request to the /api/v1/moidc/oidcs/{id} API endpoint.

Example Response:

{
  "data": {
    "id": "string",
    "attributes": {
      "attributesRequestMethod": "string", // (GET/POST)
      "attributesUrl": "string",
      "authorizeScopes": ["string"],
      "authorizeUrl": "string",
      "clientId": "string",
      "jwksUri": "string",
      "oidcIssuer": "string",
      "tokenUrl": "string",
      "idpIdentifiers": ["string"]
    },
    "links": {
      "self": "http://example.com"
    }
  }
}

Edit an OIDC Provider

To change the settings of a specific OIDC provider, send a PUT request to the /api/v1/moidc/oidcs/{id} API endpoint with the following payload:

{
  "data": {
    "id": "string",
    "attributes": {
      "attributesRequestMethod": "string", // (GET/POST)
      "attributesUrl": "string",
      "authorizeScopes": ["string"],
      "authorizeUrl": "string",
      "clientId": "string",
      "clientSecret": "string",
      "jwksUri": "string",
      "oidcIssuer": "string",
      "tokenUrl": "string",
      "idpIdentifiers": ["string"]
    }
  }
}

Delete an OIDC Provider

To delete a specific OIDC provider, send a DELETE request to the /api/v1/moidc/oidcs/{id} API endpoint. Note that at least one OIDC provider must be defined, so the last OIDC provider cannot be deleted. Also, it is not possible to delete the super admin OIDC provider (updating it is available).

Known Limitations

This feature is in early development, so functionality is limited and API specifications may change.

• Each user can authenticate with a different OIDC provider, but you can’t link one user to multiple providers.
• Users must register using an email with a domain unique to their identity provider. Also, this domain must be registered as an identifier for that provider. This is because we use the email suffix to route users to the correct provider for authentication.
• Currently, Azure Entra ID (formerly Azure AD) is not supported with the MOIDC feature.
• For complete data removal after deleting a user from GoodData, you must request our support team to fully delete user data.

If you need these functionalities, please wait for the full implementation.