Skip to content

A project powered by SpecterOps - Creators of BloodHound

Okta collector for OpenHound

Slack SpecterOps on Reddit Sponsored by SpecterOps

@SpecterOps on Twitter Connect on LinkedIn Connect on Mastodon


About

OpenHound is a standardized framework for building and running OpenGraph collectors and converters. It is built in Python and powered by the Data Load Tool (DLT) library, giving you a consistent workflow to collect, process, and convert data from any source into BloodHound-compatible graphs.

The openhound-okta extension collects Okta resources and transforms these into usable nodes and edges for BloodHound.

For SAML catalog integrations, see the OIN route evidence and resolver contract. The collector prefers explicit deployed routes and otherwise fails closed unless a reviewed catalog resolver has the complete settings it requires.

Trusted SAML issuer identity

Inbound trusted SAML issuer object IDs are scoped by the collecting Okta tenant domain and the issuer's byte-exact entity ID. Multiple inbound identity providers in one Okta tenant that trust the same issuer therefore share one SAML_Issuer node, while identical entity IDs observed in different Okta tenants remain separate. The entity ID remains available as the semantic value for cross-collector correlation.

The shared-issuer ID change is additive in BloodHound. Existing IdP-keyed issuer nodes and trust edges are not removed immediately by an upload; they age out under the instance's normal retention behavior. Operators testing this change may purge their BloodHound instance when a clean graph is needed.

Python Version

Getting Started

Follow the OpenHound docs to get started:

OAuth app authentication behavior

When the collector uses Okta OAuth app credentials, it shares one bearer token across endpoint clients and refreshes that token before it expires. Long-running collections can therefore continue across the Okta access-token lifetime without failing active resource pagination. If a transient proactive refresh fails while the current token is still valid, the collector temporarily keeps using that token and suppresses repeated refresh attempts for a short cooldown. If Okta rejects a bearer token with HTTP 401, the collector retries once for stale, invalid, or unknown token responses while preserving the current token for known non-token authorization failures. Classic SSWS API token authentication remains static.

Rate-limit behavior

The collector coordinates requests by Okta API endpoint family. It limits concurrent requests, observes X-Rate-Limit-Remaining and X-Rate-Limit-Reset on successful responses, and paces later requests before a bucket is exhausted. HTTP 429 responses retry the same request and pagination cursor until a bounded elapsed-time budget is reached. Transport failures and HTTP 5xx responses retain DLT's retry coverage.

Fan-out resources use explicit page sizes where Okta documents safe maxima. Expanded group collection requests 200 rows per page, application-user collection requests 500 rows per page, application-group assignment collection requests 200 rows per page, group-push mapping collection requests 1,000 rows per page, and identity-provider user collection requests 200 rows per page. Application-group assignments are collected from each application's public assignment endpoint and retain Okta's assignment timestamp, priority, and profile field names without publishing assignment profile values to the graph. Rows stream to DLT; an exhausted required request fails the collection so DLT does not publish an incomplete replacement. If the initial expanded group page repeatedly times out, the collector retries that first page with successively halved limits before failing. With the default configuration, that sequence is 200, 100, then 50.

The defaults can be adjusted with DLT source configuration environment variables:

Environment variable Default Purpose
SOURCES__SOURCE__OKTA__APPLICATION_USERS_PAGE_SIZE 500 Application users per page, from 1 through 500
SOURCES__SOURCE__OKTA__GROUPS_PAGE_SIZE 200 Expanded groups per page, from 1 through 200
SOURCES__SOURCE__OKTA__APPLICATION_GROUP_ASSIGNMENTS_PAGE_SIZE 200 Application-group assignments per page, from 20 through 200
SOURCES__SOURCE__OKTA__GROUP_PUSH_MAPPINGS_PAGE_SIZE 1000 Group push mappings per page, from 1 through 1,000
SOURCES__SOURCE__OKTA__IDENTITY_PROVIDER_USERS_PAGE_SIZE 200 Identity-provider users per page, from 1 through 200
SOURCES__SOURCE__OKTA__ENDPOINT_CONCURRENCY 2 Maximum simultaneous requests per endpoint family
SOURCES__SOURCE__OKTA__RATE_LIMIT_MAX_ELAPSED_SECONDS 900 Maximum elapsed retry window for an individual 429 request
SOURCES__SOURCE__OKTA__RATE_LIMIT_REMAINING_RESERVE 1 Requests held in reserve when pacing against a rate-limit window

About

No description, website, or topics provided.

Resources

Code of conduct

Contributing

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Used by

Contributors

Languages