Want to restrict Okta SSO for some specific users from a specific domain

[Kamrun Nahar Nisha]

We have integrated our confluence cloud with Okta.

Confluence link: https://onemitutoyodevops.atlassian.net/

We are currently facing some problems. We had verified and added some domains in our confluence. But the problem that we faced was that from the "abc.com" domain we have in total of 50 users. But we want only 10 of them to assign Okta to use our confluence through Okta. 

We invited 10 of them, and as SSO is enforced so they were able to access our confluence from Okta.

But the problem is that the other 40 users are invited to some other organization's confluence like: https://example.atlassian.net, but they are redirecting to our okta login page.

Why this is happening and how to solve it?

Please help with this asap.

[Dave Meyer]

Hi @Kamrun Nahar Nisha ,

You can use authentication politics to put the users that you want in a policy that enforces SSO, and the remaining users in a policy that does not have SSO enabled. https://support.atlassian.com/security-and-access-policies/docs/understand-authentication-policies/

While you can associate your Confluence site to an organization for many other features to work, SSO is applied to the managed accounts in your organization (based on the domain you claimed) regardless of what Atlassian product they are accessing. Since Atlassian has a single login across all our products and properties, SSO is applied by default at the time of login. This generally has a security benefit, because you can ensure that users in your organization log in with SSO, even if they are not using a product that was explicitly sanctioned by the organization.

Regards,

Dave

[Kamrun Nahar Nisha]

Hello,

Could you please confirm whether is there any dependency to follow this process that you shared in the confluence cloud premium plan?

As we are currently in the confluence cloud premium subscription.

[Dave Meyer]

No there isn't. Authentication policies (and SSO) require an Atlassian Access subscription, but the policies are applied irrespective of any products that you are using.

[Kamrun Nahar Nisha]

Hello, 

Thank you for the information.

[Kamrun Nahar Nisha]

Hello,

We found that if we keep any user in an SSO enforce authentication policy then they can access our organization's Confluence with Okta, as Okta and our organization's confluence are integrated, but they can not access other organizations' confluence without our Okta. When they are trying to access other organizations' confluence they are redirected to our Okta login page, and thus they are unable to access other confluence without Okta. They need to login into their Okta account to access other organizations' confluence as well.

So the scenario is, suppose we have a user "kamrun.nahar@mitutoyo.co.jp", and this user is assigned to our organization's Confluence application through Okta, and she is in the SSO enforcement authentication policy in our organization's confluence. So, she will access "onemitutoyodevops.atlassian.net" through Okta. This doesn't create any problem with accessing our organization confluence.

But being a member of SSO enforce authentication policy in our confluence, while this user is trying to access another organization's confluence like "newnisha.atlassian.net", they are redirecting to the Okta login page and they need to login to an Okta account to access another organization's confluence as well.

We know this can be solved by keeping this user out of the SSO enforcement policy, but in this case, the user needs to access our organization's confluence without Okta.

But we don't want manual login (don't want without Okta login) for this user in our confluence "onemitutoyodevops.atlassian.net". But we want the user to access the other organizations' confluence without facing the above problems.

 Please help us with this asap. Thanks in advance.

[Dave Meyer]

Unfortunately what you're describing isn't possible. It's important to understand that users have a single account that they use across all Atlassian cloud tenants (tied to their email address). So they are not logging in to one individual Confluence or another. Once they are logged in to their account, they can move seamlessly between all Atlassian properties. Therefore, it's not possible to enforce SSO when a user is intending to go to one Confluence, versus the other.

This is ultimately more convenient for users, because they will always log in to their account the same way. It's also more secure for organizations  – if a user has an account tied to their corporate email, and they were to leave the company, more organizations want to restrict the ability of that user to use their account under that email, even if it's to access an Atlassian product that isn't owned by their organization.

[Kamrun Nahar Nisha]

Hello, 

Thank you for sharing the information.