Ensure Okta SSO policy is enforced for claimed accounts in verified domain

Trudy P Claspill

Let us say that:

1. A domain has been verified
2. It is set to claim accounts automatically
3. An Authentication Policy is configured to enforce SAML SSO through Okta
4. An IdP has been set up for Okta
5. The IdP has been linked to the Okta Authentication Policy
6. The client will SCIM provision users as needed to grant app access.

Is this sufficient to ensure that any Atlassian Cloud Account created independently by a user using the verified domain will be required to authenticate through Okta? The scenario presented by the client is:

Somebody creates a google group with an email address within the verified domain. Can they now go to Atlassian Cloud and create an account with that email address? Would the user be assigned to the default Local Directory policy that doesn't require SSO? Or would the account be associated with the Okta Authentication Policy that requires SAML SSO?

 

This is not my area of expertise, so I want to make sure nothing is missing that would be required. I read about also linking domains to the IdP, but I was not sure if that was also required in this situation. The reference was in a workaround here, and was in reference to JIT user provisioning, so I'm not sure it is applicable.

https://jira.atlassian.com/browse/ID-6802

Arkadiusz Wroblewski

Hello @Trudy P 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.