SSO Policy blocks users in domain accessing other instances

[Nicole Shepherd]

We have Atlassian Access set up to work with Confluence Cloud. Originally our domain was tied to the IdP (Azure AD) and we had SSO enforced. All of this was set up under the guidance of Atlassian Support.

Unfortunately we quickly discovered that consultants in our company domain who needed to access customer sites (like Jira) were getting blocked by the SSO policy. These are users who don't use the Confluence app my team manages. The fix has been to manually add them to the internal directory/nonbillable policy. 

In addition, brand new users who needed to legitimately request access to Confluence were also blocked.

Went to Atlassian for a fix, but I've been stuck in an extremely frustrating back and forth with the support engineer. They told me to move the domain to the internal directory. Did that and while initially it seemed to fix the SSO blocker issue, I've since received a number of tickets that some users continue to receive the SSO error. 

I have no idea which part of my setup is wrong (especially since THEY assisted) and what to fix. The user experience is terrible - I don't want my end users to be hitting this SSO error when they are simply trying to access their customer Jira. I also need users to be able to request Confluence access that doesn't require jumping through a bunch of hoops.

Anyone else hit this? How did you fix it?

[Ed Letifov _TechTime - New Zealand_]

Hello, @Nicole Shepherd 

Sounds like a very basic misconfiguration. I may be wrong, but please review:

Access to other sites has nothing to do with SSO policy. SSO policy is about access to Atlassian Cloud in general, to everything, e.g., to this very Community.

The error you are referring to most likely comes from your IdP.

In Azure AD – you have to configure an enterprise app for Atlassian Cloud. This app can either be made available to all users in your Azure AD (= everyone can sign-in into Atlassian Cloud) or to a select users or groups. If a user is not assigned to this app – Azure AD will block them, effectively saying "you are not allowed to access Atlassian Cloud".

Unfortunately, if you are using User Provisioning as well with the same app in Azure AD, the groups assigned will be the only groups synchronised to Atlassian Cloud.

So based on your information a possible misconfiguration is that the group that supposed to give access to Confluence is the one assigned to the app in Azure AD. This should allow you to add a user to Confluence group in Azure, get this provisioned and the user magically gets access to Confluence in Atlassian Cloud AND can login via SSO.

This leaves "other" users outside of the scope.

What you need to do is to separate concerns:

• have two apps in Azure AD for Atlassian Cloud, one only responsible for SSO, the other only responsible for User Provisioning.
• configure the SSO one either to "everyone" or to some all encompassing group e.g. access-atlassian-cloud
• configure the User Provisioning one to your confluence-related group only e.g. access-confluence OR if desired both to the confluence-related group AND the all group

So, everyone get access to Cloud, but only select few get access to Cloud and Confluence

The separation of concerns could be achieved with one app too, but there is more to it than  just resolving this SSO error. See this post on Atlassian Community that summarises my recommendations I usually give about integrating Azure AD with Atlassian Access:

https://community.atlassian.com/t5/Atlassian-Access-questions/Integrate-Azure-AD-with-Atlassian-Cloud/qaq-p/1852575#M3417

[Nicole Shepherd]

@Ed Letifov _TechTime - New Zealand_ Thanks so much for the quick response! I will review the information provided and see what updates need to be made/confer with my Azure resource.

We do have Azure AD set up so when we add a user to that group, it automatically populates the SSO policy in Cloud plus a special group that gives them access to the Confluence products. So the SSO policy members and that Confluence group are the same set of users. 

The nonbillable policy is what we had to create for "everyone else" who isn't using Confluence. And we don't want those users consuming an Access license. None of the users in the Azure AD group belong to it.

So that's a little more information if that changes what you recommended above to try. 

[Ed Letifov _TechTime - New Zealand_]

@Nicole Shepherd to clarify – if you follow recommendation as per my answer, you will be paying for these "others" in Atlassian Access bill.

The main problem with Access policies is that you have to enumerate individual users whenever you want to apply a non-default policy.

Similarly, I find the "solution" involving local directory convoluted and since it requires you to invite all "other" users manually or let them signup (see https://support.atlassian.com/provisioning-users/docs/what-are-directories/ ) – I think it is exactly the opposite of what anyone would want.

I bet paying for these users on the Access bill, while automatically provisioning/de-provisioning and controlling them from Azure AD, and getting all security benefits of them being managed is worth it.

By the way if you need help to clean up your managed users in bulk, we can assist with the use of our UserManagement for Jira app that has a new feature that allows it to connect to Atlassian Access to deactivate users in bulk based on their last login timestamp into Cloud as a whole.

And to put the above into context – we are an Atlassian Gold Solution Partner with Cloud Specialisation in Aotearoa – New Zealand.