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