Cleaner user lists in Atlassian on-prem apps with Crowd 4.4? Yes please!

[#1]

Do you:

1. Use Crowd?
2. Have multiple Atlassian applications connected to Crowd?
3. Have different sets of users with access to each application?

If you're a YES on all three, then a feature released in Crowd 4.4.0 "Sync users based on their access rights" may be a big help.

The team I'm a part of runs quite a large Atlassian ecosystem ( the intro on another post - https://community.atlassian.com/t5/Jira-articles/Maximizing-business-value-from-your-log-files-insights-in-to-app/ba-p/1126471 - covers some of the size and scale).  Our Crowd environment is connected to numerous AD/LDAP/AzureAD/etc environments and then Jira Software/JSD, Confluence, Bitbucket and Bamboo are all connected to Crowd, but not every application has the same user base, JSD needs a large user set as customers, not every JSW/Confluence user needs to work on code, and not every person working on code uses Bamboo for CI/CD, so Bitbucket and Bamboo have subsets users.

Up until 4.4.0, the logic was that if a user existed in a Crowd directory mapped to a Crowd application, then that user would be synced to Jira/Confluence/Bitbucket/Bamboo - even if the user did not have permission to login to the application ( https://confluence.atlassian.com/crowd/specifying-which-groups-can-access-an-application-25788430.html ). The result of this is that every application had the same set of users that were not needed - in some of our cases, over 100,000 excess users. 

The concerns/drawbacks of this were numerous - some examples:

• The user picker in Jira shows all users in the database, even if they don't have access to the application, so Project Admins were adding users to roles but those users could never login, let alone have a JSW license
• The user admin pages were full of irrelevant users (and with Bitbucket and https://jira.atlassian.com/browse/BSERV-7571 this was quite problematic)
• From a security/risk point of view, having unnecessary PII stored is never ideal (GDPR fines anyone?)
• Keeping the database tables as lean as possible is always ideal to maximise performance. While we never had any significant performance issues, we did see a helpful reduction in sync time between the applications and Crowd.

To enable this option, go to a Crowd application (if you're using Crowd 4.4.0 or newer) and you should see a new heading under the "Directories & groups" tab called "Access-based synchronization" (ABS)

• By default, it should be set to "All users and groups" as this is the default behaviour for all previous versions of Crowd, but there are two options.
  
  • All groups, but only users with access rights
    • If a user can authenticate to the application (based on their directory source and the "Who can authenticate" setting for that directory), then they will be exposed to the application. If they cannot authenticate, the application will not know the user exists. This option will not impact what groups are exposed to the applications for users who can authenticate. This is the option we implemented for all applications.
  • Only users and groups with access rights
    • This option will apply the same logic as above for users, but also changes the group logic. With this option enabled groups will only sync if they are specified in the "Who can authenticate" groups selection list. We do not use this option as we have thousands of groups that we want the applications to see, and while not every group is used in every application - it's an impossible task to manage which groups are/aren't exposed.
      If you're using nested groups, then from memory I believe the following applies - so please be careful:
      • You have Group1 and Group2
      • Group2 is nested in Group1
      • UserA is in Group2
      • Your Crowd application says only Group1 can authenticate
      • UserA would be exposed to the application as the group expansion happens on the Crowd side
      • Group2 would not be exposed to the application
      • The application would not see UserA as a member of Group1 as the application doesn't see Group2 to calculate the effective membership

https://confluence.atlassian.com/crowd/crowd-4-4-release-notes-1087517293.html for the 4.4 release notes

Adjusting the ABS options above could cause a SIGNIFICANT change in your application. Please ensure you test any changes in a non-production environment first!

Have you tried ABS yet? If so, let us know how it went for you!

CCM