Skip to content

Setting up Okta

This guide walks you through configuring Okta as your identity provider for DeepIntShield Enterprise. After completing this setup, your users will be able to sign in to DeepIntShield using their Okta credentials, with roles and team memberships automatically synchronized.

  • An Okta organization with admin access
  • DeepIntShield Enterprise deployed and accessible
  • The redirect URI for your DeepIntShield instance (e.g., https://your-deepintshield-domain.com/login)

  1. Log in to the Okta Admin Console
  2. Navigate to Applications → Applications
  3. Click Create App Integration
Okta Applications page
  1. In the dialog, select:
    • Sign-in method: OIDC - OpenID Connect
    • Application type: Web Application
Create new app integration dialog
  1. Click Next to continue

Configure the following settings for your application:

General Settings:

  • App integration name: DeepIntShield Enterprise
  • Logo (optional): Upload your DeepIntShield logo image so the application is easy to recognize

Grant type:

  • Enable Authorization Code
  • Enable Refresh Token

Sign-in redirect URIs:

  • Add your DeepIntShield login callback URL: https://your-deepintshield-domain.com/login

Sign-out redirect URIs (Optional):

  • Add your DeepIntShield base URL: https://your-deepintshield-domain.com

Assignments:

  • Choose Skip group assignment for now (we’ll configure this later)
  1. Click Save to create the application

  2. After saving, note down the following from the General tab:

    • Client ID
    • Client Secret (click to reveal)

Step 3: Configure Authorization Server (optional)

Section titled “Step 3: Configure Authorization Server (optional)”

DeepIntShield uses Okta’s Authorization Server to issue tokens. You have three options:

  1. Use /oauth2/default with role claims (recommended) - Complete Steps 4-7 to configure custom role claims on the default authorization server. This enables automatic RBAC synchronization.

  2. Use /oauth2/default without role claims - Skip Steps 4-7. The first user to sign in automatically receives the Admin role and can manage RBAC for all subsequent users through the DeepIntShield dashboard.

  3. Skip Step 3 entirely - Authorization is not configured through Okta. You’ll need an alternative authentication mechanism.

  1. Navigate to Security → API

  2. Click on Authorization Servers

  3. Note the Issuer URI for your authorization server (e.g., https://your-domain.okta.com/oauth2/default)


To map Okta users to DeepIntShield roles, you need to create a custom attribute.

  1. Navigate to Directory → Profile Editor

  2. Click on your application’s user profile (e.g., DeepIntShield Enterprise User)

  3. Click Add Attribute

  4. Configure the attribute:

FieldValue
Data typestring
Display namedeepintshieldRole
Variable namedeepintshieldRole
EnumCheck “Define enumerated list of values”
Attribute membersAdmin → admin, Viewer → viewer
Attribute typePersonal
  1. Click Save

Configure the authorization server to include the role in the access token.

  1. Navigate to Security → API → Authorization Servers
  2. Click on your authorization server (e.g., default)
  3. Go to the Claims tab
  4. Click Add Claim

Configure the claim:

FieldValue
Namerole
Include in token typeAccess Token, Always
Value typeExpression
Valueuser.deepintshieldRole
Include inAny scope
  1. Click Create

Step 6: Configure Groups for Team and Role Synchronization

Section titled “Step 6: Configure Groups for Team and Role Synchronization”

DeepIntShield can automatically sync Okta groups for two purposes:

  • Team synchronization - Groups are synced as DeepIntShield teams
  • Role mapping - Groups can be mapped to DeepIntShield roles (Admin or Viewer) using Group-to-Role Mappings in the DeepIntShield UI
  1. Navigate to Directory → Groups

  2. Click Add group

  3. Create groups that correspond to your teams or roles (e.g., deepintshield-staging-admins, deepintshield-staging-viewers)

You have two options for configuring the groups claim. Choose the one that best fits your Okta plan and requirements.

Option A: Using App-Level Groups Claim (All Okta Plans)

Section titled “Option A: Using App-Level Groups Claim (All Okta Plans)”

This approach configures the groups claim directly in your application’s settings and works with all Okta plans, including free tiers.

  1. Navigate to your application’s Sign On tab

  2. Scroll down to the OpenID Connect ID Token section

  3. Click Edit to modify the settings

  4. Configure the Groups claim filter:

    • Groups claim type: Filter
    • Groups claim filter: Set a claim name (e.g., groups) and filter condition (e.g., “Starts with” deepintshield-staging)
  5. Click Save

Option B: Using Authorization Server Groups Claim

Section titled “Option B: Using Authorization Server Groups Claim”

This approach adds the groups claim through your authorization server, providing more flexibility for complex configurations.

  1. Navigate to Security → API → Authorization Servers
  2. Select your authorization server (e.g., default)
  3. Go to the Claims tab
  4. Click Add Claim

Configure the groups claim:

FieldValue
Namegroups
Include in token typeID Token, Always
Value typeGroups
FilterMatches regex: .* (or specify a prefix like deepintshield-.*)
Include inAny scope
  1. Click Create

You can also configure an additional groups claim in the application’s Sign On settings:

  1. Navigate to your application’s Sign On tab

  2. Under OpenID Connect ID Token, configure:

    • Groups claim type: Expression
    • Groups claim expression: Arrays.flatten(Groups.startsWith("OKTA", "deepintshield", 100))

  1. Navigate to your application’s Assignments tab

  2. Click Assign → Assign to People or Assign to Groups

  3. For each user, set deepintshieldRole to admin or viewer for the access level they need.

  4. Click Save and Go Back


Now configure DeepIntShield to use Okta as the identity provider.

  1. Navigate to SSO & SCIM Sync in your DeepIntShield dashboard
  2. Select Okta as the SCIM Provider
  3. Enter the following configuration:
FieldValue
Client IDYour Okta application Client ID
Issuer URLIssuer URL
AudienceYour API audience (e.g., api://default or custom)
Client SecretYour Okta application Client Secret (optional, for token revocation)
  1. Toggle Enabled to activate the provider
  2. Click Save Configuration

If you configured groups in Okta (Step 6), you can map Okta group names directly to DeepIntShield roles. This is an alternative to using custom role claims (Steps 4-5) and works with all Okta plans.

  1. In the User Provisioning configuration, scroll down to Group-to-Role Mappings
  2. Click Add Mapping
  3. Enter the Group Claim Name exactly as it appears in your Okta groups (e.g., deepintshield-staging-admins)
  4. Select the corresponding Role (Admin or Viewer)
  5. Repeat for each group you want to map
Group Claim NameRole
deepintshield-staging-adminsAdmin
deepintshield-staging-viewersViewer
  1. Click Save Configuration
FieldRequiredDescription
issuerUrlYesOkta authorization server URL (e.g., https://your-domain.okta.com/oauth2/default)
clientIdYesApplication Client ID from Okta
clientSecretNoApplication Client Secret (enables token revocation)
audienceYesAPI audience identifier from your authorization server
userIdFieldNoJWT claim for user ID (default: uid)
rolesFieldNoJWT claim for roles (default: roles)
teamIdsFieldNoJWT claim for group/team IDs (default: groups)

  1. Open your DeepIntShield dashboard in a new browser or incognito window
  2. You should be redirected to Okta for authentication
  3. Log in with an assigned user
  4. After successful authentication, you’ll be redirected back to DeepIntShield
  5. Verify the user appears in the DeepIntShield users list with the correct role

  • Verify the SCIM provider is enabled in DeepIntShield
  • Check that the DeepIntShield server was restarted after configuration
  • Ensure the Issuer URL is correct and accessible
  • Verify the audience field matches your Okta authorization server’s audience
  • Check if you’re using a custom authorization server and update the issuer URL accordingly
  • Ensure the role claim is configured in your authorization server
  • Verify users have the deepintshieldRole attribute set
  • Check that the claim is included in the access token (use Okta’s Token Preview feature)
  • Verify the groups claim is configured in your authorization server
  • Ensure users are assigned to the relevant groups
  • Check that groups are assigned to the application
  • Ensure the Refresh Token grant type is enabled for your application
  • Verify the offline_access scope is included in your authorization requests