Alert EnterpriseWiki

Okta Single Sign-On

Okta·AE_Okta_SSO_ConfigurationGuide

IAMactiveOkta (cloud — versionless SaaS)
Transports
rest
Direction
inbound
Authentication
SAML 2.0 (AE as SP, Okta as IdP)
Last updated
2025-08-22

Overview

The Okta SSO connector configures AlertEnterprise Guardian to federate authentication to Okta via SAML 2.0. AE Guardian acts as the SAML Service Provider (SP); Okta acts as the Identity Provider (IdP) with its own identity store (users + groups created in Okta or synced from upstream sources via Okta AD Agent / SCIM).

For new-hire identity sync — distinct from SSO authentication — pair this connector with the full okta connector (which uses Okta's REST API for cardholder/identity provisioning + reconciliation) or with sail-point-rest when SailPoint owns the identity lifecycle.

Setup pattern mirrors adfs-sso: AE provides metadata XML; Okta admin creates a new SAML 2.0 Application in the Okta admin console, imports the AE metadata, configures attribute statements (email → Name ID, optional tenant claim). Users must be assigned to the Okta application AND exist in AE Guardian's database before they can log in.

Architecture

Composed from this connector's actors + edges. Trust zones are color-coded; trust crossings render as thicker lines.

Composing diagram — running ELK layout4 actors · 3 edges

Authentication

1 method supported

SAML 2.0 (AE as SP, Okta as IdP)
saml

AE Guardian acts as the SAML Service Provider; Okta acts as the Identity Provider. AE provides metadata XML; the Okta admin creates a SAML 2.0 application in Okta admin console, imports AE metadata, and assigns users / groups to the application. On authentication, Okta posts a SAML response to AE's ACS endpoint with the user's email as Name ID.

Prerequisites

Everything that must be in place for this connector to work, with the owner who's responsible.

Okta tenant with SAML 2.0 application configured for AE

customer

An operational Okta tenant. The Okta admin creates a SAML 2.0 application, imports AE-provided metadata XML, and assigns users/groups to it.

User records pre-synced into AE Guardian database

ae

Same constraint as adfs-sso — users authenticated by Okta must already exist in AE Guardian's database. Typically achieved by running the okta provisioning connector first.

Known limitations

Documented constraints to set customer expectations before deployment.

Authentication only — no provisioning or reconciliation

informational

This connector configures SSO. For identity data sync, pair with the okta connector.

IAM specifics

Protocol support
OIDC
yes
SAML
yes
SCIM
yes
JIT provisioning
configurable
Group sync mode
not-supported
Source of record
No
MFA model

MFA enforced by Okta via Sign-On Policies. AE Guardian inherits MFA enforcement from Okta — no AE-side configuration required.

Default attribute mapping

Email-formatted Name ID + optional tenant claim. Customers can extend the attribute statement in the Okta application configuration.

Source materials
  • src/connectors/okta-sso/source.pdf Full configuration guide — 17 pages, updated 2025-08-22
Verifying access
Desktop only

The AE Mobile Wiki needs a bigger screen.

The diagrams, comparisons, and animated flows aren't built for phones. Open this link on your laptop or desktop browser and you'll see the full reference.

wiki.alertenterprise.app

Same Google sign-in as the AE App Hub — you'll be in once you open it on a larger screen.