AtomationDocsOkta setup overviewOkta integration docs overview
Use this page to choose the right Atomation Okta setup guide. API access powers assessment scans; SAML SSO controls workspace sign-in; SCIM handles lifecycle and role groups.
Choose the right Okta guide
Atomation's Okta setup now has dedicated docs for each connection type. Start with the guide that matches the job you are doing.
Required for assessment scans. Use this guide to configure the Okta API Services app Atomation uses to read posture evidence from each connected Okta org. Automated setup assigns Super Administrator to the permanent app and grants 31 assessment reads plusokta.appGrants.manage. Routine scans request only the reads; Atomation reserves the org-level management scope for a future reviewed workflow targeting the configured connector app. Setup must revoke the temporary Okta API token (SSWS) created by a Super Administrator.
Optional workspace sign-in. Use this guide when your team should authenticate to Atomation through Okta instead of local email plus MFA.
Optional user lifecycle and group membership. Use this guide to create, update, deactivate, and map users through SCIM 2.0.
Reference for Atomation workspace roles. Use it before mapping Okta groups to Atomation roles through SCIM group push or group linking.
How the Okta pieces fit
API access, SAML, SCIM, and roles solve different setup problems. Keeping them separate avoids mixing scan access with user login or provisioning.
| Setup area | What it does | Where to go |
|---|---|---|
| Assessment data connection | Creates one Okta API Services app per scanned Okta org to collect assessment evidence without modifying the org. | Okta API access guide |
| Workspace sign-in | Lets users sign in to Atomation through Okta SAML 2.0 for the primary identity org. | Okta SAML SSO guide |
| User lifecycle | Creates, updates, deactivates, and groups users through SCIM 2.0 provisioning. | Okta SCIM provisioning guide |
| Role mapping | Maps Okta groups to Atomation workspace roles after you know the intended access model. | Roles and permissions reference |
Recommended setup order
Connect the assessment data plane
For the first scan, start with Okta API access. This is the required scan connection and stays separate from workspace login. If you have an .oktapreview.com org, connect and scan it before production to validate the setup, findings, framework mappings, and report workflow.
Preview orgs count toward connected-org allowances and retain only the most recent completed scan and generated report. Download a Preview report before rescanning if you need to keep the earlier result.
Add SAML SSO when you want Okta workspace login
Use the SAML SSO guide for the primary identity org. Do not use the API access setup as a substitute for SAML login.
Add SCIM when you want lifecycle automation
Use the SCIM provisioning guide to manage user lifecycle and groups. Review Atomation roles before linking Okta groups.
Repeat API access for additional scan-only orgs
Multi-org customers configure a separate API Services app for each scanned Okta org. SAML and SCIM remain tied to the workspace's selected primary identity org.
OIN and customer setup boundary
For SAML and SCIM review or configuration, use the dedicated SAML SSO and SCIM provisioning guides. The Okta API access guide is the customer assessment data connection and is intentionally documented separately.
Current separation: API access is for assessment evidence. SAML SSO is for workspace authentication. SCIM is for user lifecycle and group-to-role mapping. Roles are documented in the roles and permissions reference.
Support
- Email: [email protected]
- Include your Atomation tenant subdomain, the setup area you are working on, the step that failed, a timestamp, and any Okta event or correlation ID.
- For assessment scans, use Okta API access.
- For workspace login, use Okta SAML SSO.
- For provisioning and groups, use Okta SCIM provisioning and the roles reference.