Okta
Port's Okta integration allows you to model Okta identity and access management resources in your software catalog and ingest data into them.
Overview
This integration allows you to:
- Map and organize your desired Okta resources and their metadata in Port (see supported resources below).
- Watch for Okta object changes (create/update/delete) in real-time, and automatically apply the changes to your entities in Port.
- Track user and group relationships for better access management visibility.
Supported resources
The resources that can be ingested from Okta into Port are listed below. It is possible to reference any field that appears in the API responses linked below in the mapping configuration.
Prerequisites
Create an Okta API token
- Log in to your Okta admin console.
- Navigate to Security > API > Tokens.
- Click Create Token.
- Provide a name for your token (e.g., "Port Integration").
- Click Create Token.
- Copy the generated token and save it securely.
Store your API token securely and never share it. The token provides access to your Okta data.
Okta Domain
Your Okta domain is the subdomain of your Okta organization URL. For example, if your Okta URL is https://dev-123456.okta.com, your domain would be dev-123456.okta.com.
Setup
Choose one of the following installation methods:
Not sure which method is right for your use case? Check the available installation methods.
- Hosted by Port (Recommended)
- Self-hosted
- CI
-
Go to the Okta data source page in your portal.
-
Under
Select your installation method, chooseHosted by Port. -
configure the
custom settingsandadvanced configurationas you wish (see below for details).
Custom settings
Each integration has its own tool-specific configuration that you provide during setup:
Advanced configuration
In Port, you can configure the following settings for the integration:
-
Live event support:This integration supports live events, allowing real-time updates to your software catalog without waiting for the next scheduled sync.
Supported live event triggers (click to expand)
User:
- user.lifecycle.create
- user.lifecycle.activate
- user.lifecycle.deactivate
- user.lifecycle.suspend
- user.lifecycle.unsuspend
- user.lifecycle.delete
- user.account.update_profile
Group:
- group.lifecycle.create
- group.lifecycle.delete
- group.lifecycle.update
Group Membership:
- group.user_membership.add
- group.user_membership.remove
-
Actions processing enabled:
When enabled, Port will automatically process actions for this integration. -
Create default resources:
When enabled, Port will automatically create default blueprints and mapping configurations for this integration.
Port secrets
Some integration settings require sensitive pieces of data, such as tokens. For these settings, Port secrets will be used, ensuring that your sensitive data is encrypted and secure.
When filling in such a setting, its value will be obscured (shown as ••••••••).
For each such setting, Port will automatically create a secret in your organization.
To see all secrets in your organization, follow these steps.
Port source IP addresses
When using this installation method, Port will make outbound calls to your 3rd-party applications from static IP addresses. You may need to add these addresses to your allowlist, in order to allow Port to interact with the integrated service:
- Europe (EU):
54.73.167.226,63.33.143.237,54.76.185.219 - United States (US):
3.234.37.33,54.225.172.136,3.225.234.99
Using this installation method means that the integration will be able to update Port in real time using webhooks.
Prerequisites
-
A Kubernetes cluster - the integration's container chart will be deployed to this cluster.
-
kubectlandhelmmust be installed on your machine. YourkubectlCLI must be connected to the Kubernetes cluster where you plan to install the integration.
-
Go to the Okta data source page in your portal.
-
Select the
Real-time and always onmethod. -
A
helmcommand will be displayed, with default values already filled out (e.g. your Port client ID, client secret, etc). Copy the command, replace the placeholders with your values, then run it in your terminal to install the integration.
BaseUrl & webhook configuration
To enable real-time updates of the data in your software catalog, you need to define the liveEvents.baseUrl parameter.
This parameter should be set to the URL of your Okta integration instance, which needs to have the option to setup webhooks via HTTP requests/receive HTTP requests, so ensure the network is configured accordingly.
- If Okta and the integration are in the same cluster/network: Use an internal URL (e.g., a Kubernetes service DNS name).
For Kubernetes deployments, create a service to expose the integration pod and use the service URL asliveEvents.baseUrl. If both the source system and integration are in the same cluster, an internal ClusterIP service is sufficient. - If Okta is external to the integration's network: The integration must be exposed via an ingress, load balancer, or public URL that Okta can reach.
If liveEvents.baseUrl is not provided, the integration will continue to function correctly. In such a configuration, to retrieve the latest information from the target system, the scheduledResyncInterval parameter has to be set, or a manual resync will need to be triggered through Port's UI.
To test webhooks or live event delivery to your local environment, expose your local pod or service to the internet using ngrok (e.g. ngrok http http://localhost:8000)
Scalable mode for large integrations
If you are deploying the integration at scale and want to decouple the resync process from the live events process (recommended for large or high-throughput environments), you can enable scalable mode by adding the following flags to your Helm install command:
--set workload.kind="CronJob" \
--set workload.cron.resyncTimeoutMinutes=60 \
--set scheduledResyncInterval="'*/60 * * * *'" \
--set liveEvents.worker.enabled=true
All Ocean integrations expose a health check endpoint at /docs.
For example, if your integration is accessible at https://your-integration-host:8000, you can access the health check at https://your-integration-host:8000/docs.
For details about the available parameters for the installation, see the table below.
This table summarizes the parameters used for the installation.
Note the parameters specific to this integration, they are last in the table.
| Parameter | Description | Required |
|---|---|---|
port.clientId | Your Port client id, used to identify your account | ✅ |
port.clientSecret | Your Port client secret, used to identify your account | ✅ |
port.baseUrl | Your Port API URL - https://api.getport.io for EU, https://api.us.getport.io for US | ✅ |
initializePortResources | Default: true. When true, the integration will create default blueprints and configuration mapping | ❌ |
sendRawDataExamples | Default: true. Enable sending raw data examples from the third party API to Port for testing and managing the integration mapping | ❌ |
integration.identifier | The integration's identifier, used to reference the integration when using Port's API | ✅ |
integration.type | The integration type, used to denote the integrated tool/platform | ✅ |
integration.eventListener.type | The method used to listen to events from the 3rd party tool (POLLING or KAFKA) | ✅ |
integration.secrets.oktaApiToken | The Okta API token used to authenticate Port to Okta | ✅ |
integration.config.oktaDomain | Your Okta domain (e.g., dev-123456.okta.com) | ✅ |
integration.secrets.oktaWebhookSecret | Optional secret used to verify incoming webhook requests | ❌ |
Recommended resource sizes
To ensure optimal performance and avoid out-of-memory (OOM) errors, we recommend the following resources for this integration:
- CPU Limit:
800m - CPU Request:
100m - Memory Limit:
1Gi - Memory Request:
1Gi
Set resource values
helm install my-integration port-labs/port-ocean \
# ... other parameters
--set ocean.resources.limits.cpu=800m \
--set ocean.resources.limits.memory=1Gi \
--set ocean.resources.requests.cpu=100m \
--set ocean.resources.requests.memory=1Gi
This workflow/pipeline will run the Okta integration once and then exit, this is useful for scheduled ingestion of data.
If you want the integration to update Port in real time you should use the Self-hosted installation option.
- GitHub
- Jenkins
- Azure Devops
- GitLab
- Docker
Make sure to configure the following GitHub Secrets:
| Parameter | Description | Required |
|---|---|---|
OCEAN__PORT__CLIENT_ID | Your Port client id | ✅ |
OCEAN__PORT__CLIENT_SECRET | Your Port client secret | ✅ |
OCEAN__PORT__BASE_URL | Your Port API URL - https://api.getport.io for EU, https://api.us.getport.io for US | ✅ |
OCEAN__INTEGRATION__CONFIG__OKTA_DOMAIN | Your Okta domain. For example dev-123456.okta.com | ✅ |
OCEAN__INTEGRATION__SECRETS__OKTA_API_TOKEN | The Okta API token. Generate it from Okta Admin Console under Security > API > Tokens | ✅ |
OCEAN__INTEGRATION__IDENTIFIER | Change the identifier to describe your integration; if not set, a default identifier will be used | ❌ |
OCEAN__INITIALIZE_PORT_RESOURCES | Default true. When set to false, the integration will not create default blueprints and mapping | ❌ |
OCEAN__SEND_RAW_DATA_EXAMPLES | Default true. When set to false, raw data examples will not be sent to Port | ❌ |
Here is an example for okta-integration.yml workflow file:
name: Okta Exporter Workflow
on:
workflow_dispatch:
schedule:
- cron: '0 */1 * * *' # Determines the scheduled interval for this workflow. This example runs every hour.
jobs:
run-integration:
runs-on: ubuntu-latest
timeout-minutes: 30 # Set a time limit for the job
steps:
- uses: port-labs/ocean-sail@v1
with:
type: 'okta'
port_client_id: ${{ secrets.OCEAN__PORT__CLIENT_ID }}
port_client_secret: ${{ secrets.OCEAN__PORT__CLIENT_SECRET }}
port_base_url: https://api.getport.io
config: |
okta_domain: ${{ secrets.OCEAN__INTEGRATION__CONFIG__OKTA_DOMAIN }}
okta_api_token: ${{ secrets.OCEAN__INTEGRATION__SECRETS__OKTA_API_TOKEN }}
Your Jenkins agent should be able to run docker commands.
Make sure to configure the following Jenkins Credentials
of Secret Text type:
| Parameter | Description | Required |
|---|---|---|
OCEAN__PORT__CLIENT_ID | Your Port client id | ✅ |
OCEAN__PORT__CLIENT_SECRET | Your Port client secret | ✅ |
OCEAN__PORT__BASE_URL | Your Port API URL - https://api.getport.io for EU, https://api.us.getport.io for US | ✅ |
OCEAN__INTEGRATION__CONFIG__OKTA_DOMAIN | Your Okta domain. For example dev-123456.okta.com | ✅ |
OCEAN__INTEGRATION__SECRETS__OKTA_API_TOKEN | The Okta API token. Generate it from Okta Admin Console under Security > API > Tokens | ✅ |
OCEAN__INTEGRATION__IDENTIFIER | Change the identifier to describe your integration; if not set, a default identifier will be used | ❌ |
OCEAN__INITIALIZE_PORT_RESOURCES | Default true. When set to false, the integration will not create default blueprints and mapping | ❌ |
OCEAN__SEND_RAW_DATA_EXAMPLES | Default true. When set to false, raw data examples will not be sent to Port | ❌ |
Here is an example for Jenkinsfile groovy pipeline file:
pipeline {
agent any
stages {
stage('Run Okta Integration') {
steps {
script {
withCredentials([
string(credentialsId: 'OCEAN__PORT__CLIENT_ID', variable: 'OCEAN__PORT__CLIENT_ID'),
string(credentialsId: 'OCEAN__PORT__CLIENT_SECRET', variable: 'OCEAN__PORT__CLIENT_SECRET'),
string(credentialsId: 'OCEAN__INTEGRATION__CONFIG__OKTA_DOMAIN', variable: 'OCEAN__INTEGRATION__CONFIG__OKTA_DOMAIN'),
string(credentialsId: 'OCEAN__INTEGRATION__SECRETS__OKTA_API_TOKEN', variable: 'OCEAN__INTEGRATION__SECRETS__OKTA_API_TOKEN'),
]) {
sh('''
# Set Docker image and run the container
integration_type="okta"
version="latest"
image_name="ghcr.io/port-labs/port-ocean-${integration_type}:${version}"
docker run -i --rm --platform=linux/amd64 \
-e OCEAN__EVENT_LISTENER='{"type":"ONCE"}' \
-e OCEAN__INITIALIZE_PORT_RESOURCES=true \
-e OCEAN__SEND_RAW_DATA_EXAMPLES=true \
-e OCEAN__INTEGRATION__CONFIG__OKTA_DOMAIN=$OCEAN__INTEGRATION__CONFIG__OKTA_DOMAIN \
-e OCEAN__INTEGRATION__SECRETS__OKTA_API_TOKEN=$OCEAN__INTEGRATION__SECRETS__OKTA_API_TOKEN \
-e OCEAN__PORT__CLIENT_ID=$OCEAN__PORT__CLIENT_ID \
-e OCEAN__PORT__CLIENT_SECRET=$OCEAN__PORT__CLIENT_SECRET \
-e OCEAN__PORT__BASE_URL='https://api.getport.io' \
$image_name
exit $?
''')
}
}
}
}
}
}
Your Azure DevOps agent should be able to run docker commands.
Make sure to configure the following Azure DevOps Variables as secret variables:
| Parameter | Description | Required |
|---|---|---|
OCEAN__PORT__CLIENT_ID | Your Port client id | ✅ |
OCEAN__PORT__CLIENT_SECRET | Your Port client secret | ✅ |
OCEAN__PORT__BASE_URL | Your Port API URL - https://api.getport.io for EU, https://api.us.getport.io for US | ✅ |
OCEAN__INTEGRATION__CONFIG__OKTA_DOMAIN | Your Okta domain. For example dev-123456.okta.com | ✅ |
OCEAN__INTEGRATION__SECRETS__OKTA_API_TOKEN | The Okta API token. Generate it from Okta Admin Console under Security > API > Tokens | ✅ |
OCEAN__INTEGRATION__IDENTIFIER | Change the identifier to describe your integration; if not set, a default identifier will be used | ❌ |
OCEAN__INITIALIZE_PORT_RESOURCES | Default true. When set to false, the integration will not create default blueprints and mapping | ❌ |
OCEAN__SEND_RAW_DATA_EXAMPLES | Default true. When set to false, raw data examples will not be sent to Port | ❌ |
Here is an example for okta-integration.yml pipeline file:
trigger:
- main
pool:
vmImage: "ubuntu-latest"
variables:
- group: port-ocean-credentials
steps:
- script: |
# Set Docker image and run the container
integration_type="okta"
version="latest"
image_name="ghcr.io/port-labs/port-ocean-$integration_type:$version"
docker run -i --rm \
-e OCEAN__EVENT_LISTENER='{"type":"ONCE"}' \
-e OCEAN__INITIALIZE_PORT_RESOURCES=true \
-e OCEAN__SEND_RAW_DATA_EXAMPLES=true \
-e OCEAN__INTEGRATION__CONFIG__OKTA_DOMAIN=$(OCEAN__INTEGRATION__CONFIG__OKTA_DOMAIN) \
-e OCEAN__INTEGRATION__SECRETS__OKTA_API_TOKEN=$(OCEAN__INTEGRATION__SECRETS__OKTA_API_TOKEN) \
-e OCEAN__PORT__CLIENT_ID=$(OCEAN__PORT__CLIENT_ID) \
-e OCEAN__PORT__CLIENT_SECRET=$(OCEAN__PORT__CLIENT_SECRET) \
-e OCEAN__PORT__BASE_URL='https://api.getport.io' \
$image_name
exit $?
displayName: 'Ingest Data into Port'
Make sure to configure the following GitLab variables:
| Parameter | Description | Required |
|---|---|---|
OCEAN__PORT__CLIENT_ID | Your Port client id | ✅ |
OCEAN__PORT__CLIENT_SECRET | Your Port client secret | ✅ |
OCEAN__PORT__BASE_URL | Your Port API URL - https://api.getport.io for EU, https://api.us.getport.io for US | ✅ |
OCEAN__INTEGRATION__CONFIG__OKTA_DOMAIN | Your Okta domain. For example dev-123456.okta.com | ✅ |
OCEAN__INTEGRATION__SECRETS__OKTA_API_TOKEN | The Okta API token. Generate it from Okta Admin Console under Security > API > Tokens | ✅ |
OCEAN__INTEGRATION__IDENTIFIER | Change the identifier to describe your integration; if not set, a default identifier will be used | ❌ |
OCEAN__INITIALIZE_PORT_RESOURCES | Default true. When set to false, the integration will not create default blueprints and mapping | ❌ |
OCEAN__SEND_RAW_DATA_EXAMPLES | Default true. When set to false, raw data examples will not be sent to Port | ❌ |
Here is an example for .gitlab-ci.yml pipeline file:
default:
image: docker:24.0.5
services:
- docker:24.0.5-dind
before_script:
- docker info
variables:
INTEGRATION_TYPE: okta
VERSION: latest
stages:
- ingest
ingest_data:
stage: ingest
variables:
IMAGE_NAME: ghcr.io/port-labs/port-ocean-$INTEGRATION_TYPE:$VERSION
script:
- |
docker run -i --rm --platform=linux/amd64 \
-e OCEAN__EVENT_LISTENER='{"type":"ONCE"}' \
-e OCEAN__INITIALIZE_PORT_RESOURCES=true \
-e OCEAN__SEND_RAW_DATA_EXAMPLES=true \
-e OCEAN__INTEGRATION__CONFIG__OKTA_DOMAIN=$OCEAN__INTEGRATION__CONFIG__OKTA_DOMAIN \
-e OCEAN__INTEGRATION__SECRETS__OKTA_API_TOKEN=$OCEAN__INTEGRATION__SECRETS__OKTA_API_TOKEN \
-e OCEAN__PORT__CLIENT_ID=$OCEAN__PORT__CLIENT_ID \
-e OCEAN__PORT__CLIENT_SECRET=$OCEAN__PORT__CLIENT_SECRET \
-e OCEAN__PORT__BASE_URL='https://api.getport.io' \
$IMAGE_NAME
rules: # Run only when changes are made to the main branch
- if: '$CI_COMMIT_BRANCH == "main"'
- when: manual
To run the integration using Docker for a one-time sync:
Remember to replace the placeholders for YOUR_PORT_CLIENT_ID, YOUR_PORT_CLIENT_SECRET, YOUR_OKTA_DOMAIN, and YOUR_OKTA_API_TOKEN.
| Parameter | Description | Required |
|---|---|---|
OCEAN__PORT__CLIENT_ID | Your Port client id | ✅ |
OCEAN__PORT__CLIENT_SECRET | Your Port client secret | ✅ |
OCEAN__PORT__BASE_URL | Your Port API URL - https://api.getport.io for EU, https://api.us.getport.io for US | ✅ |
OCEAN__INTEGRATION__CONFIG__OKTA_DOMAIN | Your Okta domain. For example dev-123456.okta.com | ✅ |
OCEAN__INTEGRATION__SECRETS__OKTA_API_TOKEN | The Okta API token. Generate it from Okta Admin Console under Security > API > Tokens | ✅ |
OCEAN__INTEGRATION__IDENTIFIER | Change the identifier to describe your integration; if not set, a default identifier will be used | ❌ |
OCEAN__INITIALIZE_PORT_RESOURCES | Default true. When set to false, the integration will not create default blueprints and mapping | ❌ |
OCEAN__SEND_RAW_DATA_EXAMPLES | Default true. When set to false, raw data examples will not be sent to Port | ❌ |
docker run -i --rm --platform=linux/amd64 \
-e OCEAN__EVENT_LISTENER='{"type":"ONCE"}' \
-e OCEAN__INITIALIZE_PORT_RESOURCES=true \
-e OCEAN__SEND_RAW_DATA_EXAMPLES=true \
-e OCEAN__INTEGRATION__CONFIG__OKTA_DOMAIN="YOUR_OKTA_DOMAIN" \
-e OCEAN__INTEGRATION__SECRETS__OKTA_API_TOKEN="YOUR_OKTA_API_TOKEN" \
-e OCEAN__PORT__CLIENT_ID="YOUR_PORT_CLIENT_ID" \
-e OCEAN__PORT__CLIENT_SECRET="YOUR_PORT_CLIENT_SECRET" \
-e OCEAN__PORT__BASE_URL="https://api.getport.io" \
ghcr.io/port-labs/port-ocean-okta:latest
The port_region, port.baseUrl, portBaseUrl, port_base_url and OCEAN__PORT__BASE_URL parameters select which Port API instance to use:
- EU (app.port.io) →
https://api.getport.io - US (app.us.port.io) →
https://api.us.getport.io
For advanced configuration such as proxies or self-signed certificates, click here.
For advanced configuration such as proxies or self-signed certificates, click here.
Configuration
Port integrations use a YAML mapping block to ingest data from the third-party api into Port.
The mapping makes use of the JQ JSON processor to select, modify, concatenate, transform and perform other operations on existing fields and values from the integration API.
Default mapping configuration
This is the default mapping configuration for this integration:
Default mapping configuration (click to expand)
resources:
- kind: okta-user
selector:
query: 'true'
include_groups: true
include_applications: true
fields: "id,status,created,activated,lastLogin,lastUpdated,profile:(login,firstName,lastName,displayName,email,title,department,employeeNumber,mobilePhone,primaryPhone,streetAddress,city,state,zipCode,countryCode)"
port:
entity:
mappings:
identifier: .id
title: .profile.displayName // .profile.firstName + " " + .profile.lastName // .profile.login
blueprint: '"okta-user"'
properties:
login: .profile.login
email: .profile.email
firstName: .profile.firstName
lastName: .profile.lastName
displayName: .profile.displayName
title: .profile.title
department: .profile.department
employeeNumber: .profile.employeeNumber
mobilePhone: .profile.mobilePhone
primaryPhone: .profile.primaryPhone
streetAddress: .profile.streetAddress
city: .profile.city
state: .profile.state
zipCode: .profile.zipCode
countryCode: .profile.countryCode
status: .status
created: .created
activated: .activated
lastLogin: .lastLogin
lastUpdated: .lastUpdated
relations:
groups: .groups[]?.id
- kind: okta-group
selector:
query: 'true'
port:
entity:
mappings:
identifier: .id
title: .profile.name
blueprint: '"okta-group"'
properties:
name: .profile.name
description: .profile.description
type: .type
created: .created
lastUpdated: .lastUpdated
relations:
members: .users[]?.id
Examples
To view and test the integration's mapping against examples of the third-party API responses, use the jq playground in your data sources page. Find the integration in the list of data sources and click on it to open the playground.
Additional examples of blueprints and the relevant integration configurations:
User
User blueprint (click to expand)
{
"identifier": "okta-user",
"title": "Okta User",
"icon": "Okta",
"schema": {
"properties": {
"login": {
"title": "Login",
"type": "string"
},
"email": {
"title": "Email",
"type": "string",
"format": "email"
},
"firstName": {
"title": "First Name",
"type": "string"
},
"lastName": {
"title": "Last Name",
"type": "string"
},
"displayName": {
"title": "Display Name",
"type": "string"
},
"title": {
"title": "Job Title",
"type": "string"
},
"department": {
"title": "Department",
"type": "string"
},
"employeeNumber": {
"title": "Employee Number",
"type": "string"
},
"mobilePhone": {
"title": "Mobile Phone",
"type": "string"
},
"primaryPhone": {
"title": "Primary Phone",
"type": "string"
},
"streetAddress": {
"title": "Street Address",
"type": "string"
},
"city": {
"title": "City",
"type": "string"
},
"state": {
"title": "State",
"type": "string"
},
"zipCode": {
"title": "ZIP Code",
"type": "string"
},
"countryCode": {
"title": "Country Code",
"type": "string"
},
"status": {
"title": "Status",
"type": "string",
"enum": ["ACTIVE", "INACTIVE", "PASSWORD_EXPIRED", "LOCKED_OUT", "SUSPENDED", "DEPROVISIONED"]
},
"created": {
"title": "Created Date",
"type": "string",
"format": "date-time"
},
"activated": {
"title": "Activated Date",
"type": "string",
"format": "date-time"
},
"lastLogin": {
"title": "Last Login",
"type": "string",
"format": "date-time"
},
"lastUpdated": {
"title": "Last Updated",
"type": "string",
"format": "date-time"
}
},
"required": ["login", "email"]
},
"calculationProperties": {},
"relations": {
"groups": {
"title": "Groups",
"target": "okta-group",
"required": false,
"many": true
}
}
}
Mapping configuration (click to expand)
createMissingRelatedEntities: true
deleteDependentEntities: true
resources:
- kind: okta-user
selector:
query: "true"
include_groups: true
include_applications: true
port:
entity:
mappings:
identifier: .id
title: .profile.displayName // .profile.firstName + " " + .profile.lastName // .profile.login
blueprint: '"okta-user"'
properties:
login: .profile.login
email: .profile.email
firstName: .profile.firstName
lastName: .profile.lastName
displayName: .profile.displayName
title: .profile.title
department: .profile.department
employeeNumber: .profile.employeeNumber
mobilePhone: .profile.mobilePhone
primaryPhone: .profile.primaryPhone
streetAddress: .profile.streetAddress
city: .profile.city
state: .profile.state
zipCode: .profile.zipCode
countryCode: .profile.countryCode
status: .status
created: .created
activated: .activated
lastLogin: .lastLogin
lastUpdated: .lastUpdated
relations:
groups: .groups[]?.id
Group
Group blueprint (click to expand)
{
"identifier": "okta-group",
"title": "Okta Group",
"icon": "Okta",
"schema": {
"properties": {
"name": {
"title": "Name",
"type": "string"
},
"description": {
"title": "Description",
"type": "string"
},
"type": {
"title": "Type",
"type": "string",
"enum": ["BUILT_IN", "OKTA_GROUP", "APP_GROUP"]
},
"created": {
"title": "Created Date",
"type": "string",
"format": "date-time"
},
"lastUpdated": {
"title": "Last Updated",
"type": "string",
"format": "date-time"
}
},
"required": ["name"]
},
"calculationProperties": {},
"relations": {
"members": {
"title": "Members",
"target": "okta-user",
"required": false,
"many": true
}
}
}
Mapping configuration (click to expand)
createMissingRelatedEntities: true
deleteDependentEntities: true
resources:
- kind: okta-group
selector:
query: 'true'
port:
entity:
mappings:
identifier: .id
title: .profile.name
blueprint: '"okta-group"'
properties:
name: .profile.name
description: .profile.description
type: .type
created: .created
lastUpdated: .lastUpdated
relations:
members: .users[]?.id
Webhook configuration
The Okta integration supports real-time updates through webhooks. When using the self-hosted installation method, the integration will automatically:
- Create an Event Hook in your Okta organization
- Configure the webhook to send user and group change events
- Process incoming webhook events to update Port entities in real-time
Webhook events
The integration listens for the following Okta events:
user.lifecycle.createuser.lifecycle.activateuser.lifecycle.deactivateuser.lifecycle.suspenduser.lifecycle.unsuspenduser.lifecycle.deleteuser.account.update_profilegroup.user_membership.addgroup.user_membership.removegroup.lifecycle.creategroup.lifecycle.deletegroup.lifecycle.update
Limitations
- The integration currently supports users and groups only
- Custom Okta attributes are not automatically mapped but can be added to the configuration
- Webhook verification is optional but recommended for production environments
Troubleshooting
Common Issues
- Authentication Errors: Verify your Okta API token has the correct permissions and is not expired
- Domain Issues: Ensure your Okta domain is correctly formatted (e.g.,
dev-123456.okta.com) - Webhook Failures: Check that your self-hosted integration is accessible from the internet for webhook delivery
- Rate Limiting: Okta has API rate limits; the integration handles this automatically with retries