Who it is for
- IT and IAM owners connecting Okta to Atlassian Cloud for the first time.
- Teams with Okta single sign-on already in place but no SCIM, so Atlassian accounts outlive the people who left.
- Admins facing an audit who need written proof that a leaver in Okta loses Atlassian access.
What you get
- Atlassian Guard set up: your Guard Standard subscription or Enterprise plan confirmed, domains verified, an identity provider directory for Okta, and a backup organization admin outside your verified domains so a bad SAML setting cannot lock you out.
- SAML single sign-on through Okta's Atlassian Cloud app, tested on a pilot group under a test authentication policy, then enforced for your managed accounts.
- SCIM provisioning from Okta, with the email attribute matched between the SAML and SCIM settings so nobody ends up with two Atlassian accounts.
- Group mapping: Okta groups pushed to Atlassian and mapped to app access, with access assigned through groups and name clashes with existing Atlassian groups settled before the first push.
- A deprovisioning test: one account unassigned in Okta, its Atlassian account deactivated, and the result written down for your auditor.
- An admin handoff: a runbook for joiners, movers, and leavers, a walkthrough with your admins, and the SCIM key renewal date on your calendar.
How it works
- Prepare (1 week). We confirm your Guard tier and Okta Lifecycle Management, verify domains (DNS changes can take up to 72 hours), create the backup admin, and compare your Okta groups with your Atlassian groups.
- Connect (1 week). We configure single sign-on and SCIM in the Atlassian Cloud app, push groups, and test with a pilot group under a test authentication policy.
- Enforce and hand off (1 week). We enforce single sign-on for managed accounts, run the deprovisioning test, and walk your admins through the runbook.
What we need from you
- An Atlassian organization admin and an Okta admin available for working sessions during setup.
- Someone who can add a DNS TXT record for each domain you want to verify, or upload a file to your website.
- Atlassian Guard Standard or an Enterprise plan, and Okta Lifecycle Management on your Okta tenant.
- A list of the Okta groups you plan to use, and one account we can deprovision for the test.
Questions
Do we need Atlassian Guard to connect Okta?
Yes. SAML single sign-on and SCIM provisioning both need Atlassian Guard Standard, which Enterprise plans include at no extra cost. On the Okta side, SCIM provisioning needs Okta Lifecycle Management.
Can turning on single sign-on lock our admins out?
It can if a SAML setting is wrong. Before we configure SAML, we create an organization admin account with an email from a domain you have not verified, as Atlassian recommends, so someone can always sign in without SAML. We also test on a pilot group before enforcing single sign-on for everyone.
Why does the SCIM key matter after setup?
Atlassian SCIM API keys now expire one year after they are created or regenerated. When a key expires, users stop provisioning and deprovisioning between Okta and Atlassian until someone generates a new one. The renewal date goes in your runbook.
What is outside the fixed scope?
Connecting more than one identity provider (Guard Standard allows one; Enterprise plans allow several), moving off Okta's older Jira Cloud and Confluence Cloud apps, and inventorying external users, service accounts, and API tokens. Those belong to our full Okta SSO and SCIM service, and we scope them separately.