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

[Trudy 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 · Accepted solution]

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.

[Trudy Claspill]

Thank you @Arkadiusz Wroblewski 

Follow up questions.

The client wants all users created manually or SCIM provisioned in the verified domains to be assigned to the Okta Authentication Policy. Does the above solution address both creation paths?

I read about using Administration Automation to automatically detect the creation of an account and automatically assign it to a policy. Does linking the domains to the IdP eliminate the need for that Automation. Does use of the Automation eliminate the need to link the domains to the IdP? Are both solutions needed?

[Arkadiusz Wroblewski]

@Trudy Claspill 

I suppose your client have Enterprise Abo ?

[Trudy Claspill]

Yes

[Arkadiusz Wroblewski]

@Trudy Claspill 

Yes, if the verified domain is linked to the Okta identity provider directory, automatic claim is enabled, and the Okta/SAML policy is the default authentication policy for that directory, both paths are covered.

The key is understanding that these are separate layers. Claim settings determine whether new accounts on the verified domain are automatically managed. Linked domains determine which directory those accounts belong to. And the default policy in that directory determines which authentication policy they land in. Atlassian also routes new domains to the local directory by default, and only an IdP directory can enforce SAML SSO, so linking the domain to the Okta directory is what makes the policy stick.

With that in place: SCIM-provisioned users go to the linked IdP directory and its default policy. Self-created users do too but only if automatic claim is enabled for the verified domain.

On the Automation question: linking the domain to the IdP covers this basic use case without Automation. Automation can assign users after a trigger fires, but it doesn't replace the underlying domain-to-directory routing. So both would only be needed if the client wants extra exception handling on top of the normal Okta flow.