Okta
Okta·AE_HSc_OktaConnectorGuide
Overview
The Okta connector integrates AlertEnterprise with Okta, the most-deployed enterprise identity provider in financial-services. The connector handles user lifecycle (create + update) and access-group assignment (change user access groups) outbound to Okta, plus bidirectional reconciliation of users and access groups (full and incremental).
Topology: AlertEnterprise's Alert Connector Framework (ACF) drives the Alert Okta Connector, which calls Okta's REST API directly over HTTPS. There is no intermediate agent — the Okta connector talks directly to the customer's Okta tenant at https://{yourOktaDomain}/api/v1/....
Authentication uses Okta operator credentials (User Name + Password) bound to one of the privileged roles: pam_admin, resource_admin, or security_admin. The User API must be enabled on the Okta tenant.
This connector is paired with — but distinct from — the okta-sso SSO Configuration entry. The standard Okta connector handles user lifecycle and group reconciliation; the SSO Configuration covers SAML/OIDC federation between Okta and the AlertEnterprise application itself.
Architecture
Composed from this connector's actors + edges. Trust zones are color-coded; trust crossings render as thicker lines.
Authentication
1 method supported
The Okta REST API requires a valid operator account with one of the following
roles: pam_admin, resource_admin, or security_admin. Credentials are passed
with each HTTPS request to the Okta tenant. The Okta tenant URL takes the form
https://{yourOktaDomain}/api/v1/users.
Endpoints
3 endpoints exercised by the connector
| Method | Path | Description | Category |
|---|---|---|---|
| GET | /api/v1/users | List + read users for reconciliation. | query |
| POST | /api/v1/users | Create a user in the Okta tenant. | provisioning |
| PUT | /api/v1/users/{userId} | Update a user in the Okta tenant. | provisioning |
Prerequisites
Everything that must be in place for this connector to work, with the owner who's responsible.
Okta User API enabled on the tenant
customerThe Okta tenant must have the User API enabled at https://{yourOktaDomain}/api/v1/users.
Disabled / restricted-IP tenants will reject the connector's calls.
HTTPS-enabled Okta tenant
customerThe Okta REST API must be served over HTTPS. Plaintext HTTP is not supported by the connector.
Okta operator account with privileged role
customerThe connector's operator account must hold one of: pam_admin, resource_admin,
or security_admin. Insufficient roles will produce permission errors at the
Okta API layer.
Known limitations
Documented constraints to set customer expectations before deployment.
No delete-user support
importantThe connector documents Create and Update for user accounts but does NOT document a Delete operation. Operationally, user deactivation is typically handled by group-membership changes or by Okta's lifecycle states; full delete requires manual administrator action.
SSO federation requires separate configuration
informationalThe standard Okta connector handles user lifecycle and group reconciliation but
does NOT configure SAML/OIDC SSO between Okta and AlertEnterprise. SSO setup is
covered by the separate okta-sso SSO Configuration guide.
Data fields
3 fields mapped between AE Guardian and the vendor system.
| AE field | Vendor field | Description | Direction | Required |
|---|---|---|---|---|
| User | Okta User | User accounts in Okta map to AE User entities. Connector creates and updates users. | bidirectional | yes |
| Access Group | Okta Group | Okta Groups (access groups). Connector changes a user's group memberships and reconciles group definitions + memberships back into AE. | bidirectional | yes |
| User Profile Attributes | Okta user profile subschema | Okta supports custom user profile schemas (default + custom subschemas). The connector reads and writes user profile attributes per the documented schema. | bidirectional | no |
IAM specifics
- OIDC
- yes
- SAML
- yes
- SCIM
- yes · 2.0
- JIT provisioning
- configurable
- Group sync mode
- flat
- Source of record
- Yes
Native Okta MFA policy — enforced server-side by Okta independent of the AE connector. The connector authenticates as a privileged operator and inherits Okta's policy posture.
Okta default user schema (login, email, firstName, lastName, etc.) plus configurable custom subschemas per the developer.okta.com reference.
- src/connectors/okta/source.pdf — p5 — Chapter 1, Supported Version
- src/connectors/okta/source.pdf — p5 — Provisioning Capabilities
- src/connectors/okta/source.pdf — p5-6 — Reconciliation Capabilities
- src/connectors/okta/source.pdf — p7 — Chapter 2, Connector Architecture
- src/connectors/okta/source.pdf — p18 — Chapter 5, Security