Bypass Okta (SSO) authentication for local or service accounts

[Quentin Roberts]

Currently in the process of setting up Okta (SSO) with Atlassian Access for our Jira and Confluence (Cloud) tenants. 

We have a number of local or service accounts that are users in our Atlassian tenant however these accounts are not in Okta therefore we need to configure a separate authentication workflow for these accounts so that they authenticate against Atlassian instead of Okta.

I have read and looked into Atlassian Authentication Policies and I am able to set up a policy for the local, non-SSO users, as well as a policy for IdP/Okta SSO users.

Is my below understanding correct?

If I create an authentication policy for Okta SSO users, these users will be forced to login via SSO if SSO is enforced as long as these users email addresses/usernames have the same domain as the SSO integration (ex: acme.org)

If I create an authentication policy for local / service account users, which are user accounts that reside only in Atlassian, and not in Okta, and if I add these users, regardless of their username / email address domain (ex: acme.org) to this authentication policy, will they bypass the SSO authentication workflow?

If I link acme.org as my Identity Provider (Okta) in Atlassian, will this affect how the authentication policies work? Or will the authentication policy have priority over the Identity Provider being linked to acme.org and therefore I can control the authentication flow from the authentication policies?

Basically I want to ensure that even though I have the Identity Provider with Okta linked to acme.org in Atlassian, that I can still bypass the SSO requirement for accounts that have the domain acme.org in their username/email via Atlassian Authentication Policies so that they login directly to Atlassian instead of Okta.

[Dave Meyer]

Hi @Quentin Roberts ,

You have it correct. When you verify a domain ("acme.org") all Atlassian accounts with an email address on that domain become Managed accounts (this is true regardless of whether there's a corresponding account in Okta...you verify ownership of your domain before we know anything about your identity provider.)

Authentication policies allow you to set up SSO with an IdP for a subset of your managed accounts, but place other accounts in an authentication policy that does not enforce SSO. Which is exactly what you want in this case.

Cheers,

Dave

[Quentin Roberts]

Thanks for the quick response @Dave Meyer , much appreciated.

When I am able to get a maintenance window to test out the Okta SSO rollout I will attempt this and reply here if I run into any issues.