Hello @Trudy Claspill
The key missing piece is linking the verified domain to the Okta identity provider directory.
What you’ve listed so far is important, but on its own it does not fully guarantee that a newly created account on that verified domain will be forced into the Okta SSO flow. Atlassian’s documentation is fairly clear on this point: new domains are automatically linked to the local directory, user accounts from a linked domain are added to that directory’s default authentication policy, and the local directory is where users end up when they are invited or sign up on their own.
That means if the verified domain is still linked to the local directory, a user who creates an Atlassian account independently with that domain can still land under the local directory’s default policy. When that happens, the Okta SAML policy is not what controls their login experience.
To make sure those users are actually routed through Okta, Atlassian says the verified domain needs to be linked to the identity provider directory. Their SAML documentation lists this as a prerequisite, and their linked-domain guidance explains that once a domain is linked, Atlassian associates that domain’s user accounts with that directory and places new accounts into the default authentication policy for that directory.
That is also why Atlassian’s JIT documentation calls out the same two requirements together: link the domain to the identity provider directory, and enforce SAML SSO on that directory’s default authentication policy.
So the practical answer to the client will be....
No, automatic claim, SAML configuration, and SCIM by themselves are not the full guarantee.
If you want accounts from that verified domain to be forced through Okta, you also need the verified domain linked to the Okta IdP directory, and the default authentication policy for that IdP directory must enforce SAML SSO.
One other important nuance: SCIM is not the control that determines how independently created accounts are authenticated. SCIM is primarily for lifecycle management and directory sync. Atlassian describes it as handling things like creating, linking, and deactivating managed accounts from the IdP. The part that actually determines where authentication is routed is the domain-to-directory link, together with that directory’s default authentication policy.
It is also worth keeping in mind that this still does not mean Atlassian blocks account creation on a claimed domain altogether. Atlassian has an open suggestion for that capability, and the issue notes that users can still sign up with a valid email address and verify it.
Your instinct was right. Linking the domain to the IdP is the critical missing step.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.