Migrating to Confluence Cloud - Okta Groups

[Christian Diaz]

I haven't gotten any clarity or insight on this from Atlassian support, so wanted to ask here and see what others have done. 

Basically, when we setup our Okta integration on Confluence Server years ago, limitations of Confluence and/or Okta forced us to deviate from 1:1 AD/Okta groups to Confluence local groups. 

Example:

XYZ Confluence Users is assigned in Okta to the Confluence application and maps to the internal Confluence group xyz-confluence-users. 

XYZ Confluence Administrators is the same, but mapped to xyz-confluence-users and xyz-confluence-adminstrators in Confluence. This was because Confluence Service doesn't support SCIM or push groups, so groups could only be assigned at the assignment level and therefore users can only be assigned to a SINGLE AD group. So we had to stack permissions like this.  This has worked fine for years, but now that we're forced to the cloud with Atlassian Access, it's super messy.

From our test migration, we now have ALL of the local groups in Confluence Cloud (great!) but also, the actual AD groups are there from Access and of course, because of the naming conventions required by Confluence, can't link to the local groups. So now we have in our groups: 

* XYZ Confluence Users

* XYZ Confluence Administrators

* xyz-confluence-users

* xyz-confluence-administrators 

The local groups (xyz-confluence-*) have the expected membership because it was all moved with the Migration Assistant, but they of course aren't syncing with the IdP groups from Atlassian Access. So now we have a combination of orphaned local groups that came along for the migration, and the actual AD groups synced from Okta that don't actually map to anything. 

With no ability to bulk change site/page permissions (though I could script something with the API, it's going to be a LOT to have it loop through 450+ spaces), how are others dealing with this post-migration? 

[Kieren _SmolSoftware_]

Hi @Christian Diaz

This is a common problem with admins wanting to sync users into the default Atlassian groups.

There are two ways to get around this:

1. Create a new default group for the groups you want to "takeover". e.g. create a group in admin.atlassian.com called new-confluence-users-xyz-default. Make new-confluence-users-xyz-default the default group for the Confluence User role. Remove xyz-confluence-users as the default group (but keep the product access on that group). Once xyz-confluence-users is no longer a default group, your IDP will be able to sync to it. There is one issue with this solution; any users not added via the IDP will not be able to get access to xyz-confluence-users, they'll go into new-confluence-users-xyz-default. This means extra work for your admins to ensure those non-IDP users can access the right products/spaces/projects.

2. There is an upcoming app that could help with this that I'm building, essentially we're solving ACCESS-604. It's about to be released in a free closed beta (around mid January 2024). If you're interested, contact us via our website smolsoftware.com to be a part of the beta. I'll also update this post when the app is launched publicly in February 2024. 

-Kieren
Co-Founder @ Smol Software | Ex-Atlassian