Help with Integrating SSO and SCIM with Okta

[Paul Gerber]

I am looking for community support around how SSO integration works between Atlassian Guard and Okta.  We have the integration working, but have come across a number of challenges.  Our team "thinks" they understand the implications of adjusting settings in Okta, but over time I am not convinced that we do. 

Some specifics.  

We implemented Jira Service Management as a fresh new implementation.  Prior to doing this, we integrated SSO and SCIM using Okta as our IDP.  

In parallel a project was in flight, to migrate on premise Confluence and Jira instances, to the cloud.  As part of that migration, a sandbox migration was executed, carrying over identities from our on premise active directory.  

One problem this created, is that the identities in the on premise active directory that were used in the on premise Confluence and Jira instances, were not the same as the identities in Okta.  So we ended up with a BUNCH of basically "duplicate" identities that we had to "work through" for users.  

In working with Atlassian Support (which I must say has been a great experience, our tech/engineer with Atlassian Support has been fantastic), we learned some things. 

The biggest thing is that, we thought we could change the username that an individual user is using in Okta, to sign into Atlassian Cloud Apps.  This is done by navigating to the user in Okta, clicking on the pencil next to the app for which we want to change the username, and then changing the username and email address.  

We "thought" that would change the username that is used (by default for Atlassian it's primary email address) to whatever we set it to.  This way, after the change, when that user signs into Atlassian with SSO, it uses what we override it to for the user to sign in.  

What we think we learned from Atlassian Support, is that it doesn't matter if we change that with an override in Okta.  It uses primary email regardless.  

The interesting thing is that changing that override in Okta, does indeed change the identity in Atlassian, that the user is "connected" to.  So effectively, that override in Okta, changes things from a SCIM perspective, but not from an SSO perspective.

So what I am hoping to get from the community is insights.  Does anyone know definitively that this is the case?  Has anyone experienced it?  What have you done to maybe solve for it?  Do you have any ideas?  

My concern is that if we have changed a username using that override in Okta, it appears that the connected account in Atlassian is the one to which you changed the override.  However, it seems like based on what we have learned, that even though that is the identity that is "connected", it still uses primary email for the SSO, but you wouldn't know that without looking at a HAR file from developer tools.  

Then, if we start going in and deleting duplicate accounts, thinking we are in good shape, eventually we get a "policy mismatch" error from Atlassian because the duplicate identity is not in the right policy or doesn't exist.  

We have changed many of these and I'm concerned that we may have a bunch of accounts breaking when we clean up duplicate accounts.  

[Christos Markoulatos]

Hi @Paul Gerber welcome,

What i believe is happening in your case is the following:

• Primary email is the unique identifier for Atlassian accounts. Both SAML SSO and SCIM provisioning rely on it. If SAML NameID and SCIM email mappings differ, you’ll create duplicate accounts and login issues. Atlassian explicitly recommends mapping the same attribute (usually user.email) for both SAML and SCIM. [confluence...assian.com], [support.at...assian.com]
• Okta username overrides do NOT affect SSO login. SSO always uses the primary email from the Atlassian account for authentication. Changing the username in Okta only impacts SCIM provisioning (account linking and updates), not the SAML login flow. This matches what you observed and what Atlassian Support confirms. [community....assian.com]
• Duplicate accounts during migration happen when on-prem AD identities differ from Okta identities. Atlassian advises verifying domains and claiming accounts before enabling SCIM, or enabling SCIM after migration cleanup to avoid duplicates. [support.at...assian.com]
• Policy mismatch errors (e.g., authentication-policy-strategy-mismatch) occur when SSO is configured but not enforced in the authentication policy. Fix by editing the policy in Atlassian Admin and enabling “Enforce single sign-on.” [support.okta.com], [community....assian.com]

Changing the username override in Okta does not change what SSO uses; it only changes SCIM-linked identity. So if you delete duplicates assuming the override controls SSO, you risk breaking login and triggering policy errors.

Hope this helps!