What is Atlassian Crowd?

Atlassian Crowd is an identity management application for on-premise deployments that centralizes user management across products like Jira, Confluence, or Bitbucket and provides a streamlined navigation experience.

But what are the advantages of having Crowd versus not having it?

• For administrators, the advantage of Crowd is that group memberships and user permissions can be managed from a central space. This is particularly interesting for organizations that have multiple historic instances (for example, 5 Jiras and 3 Confluences) and are running permissions locally, which can be very confusing.
• For users, the navigation between Atlassian applications will have less friction. For example, it’s very common to bump against Confluence’s login page after clicking on a link in a Jira ticket. When both applications are connected to Crowd, that second prompt to login disappears.

Sometimes Crowd can coexist with a true SSO solution. But to understand when that combination makes sense, it’s helpful to have a closer look to how Crowd works and what are its limitations.

1. Crowd as an LDAP server

Like any other Atlassian product in Server and Data Center, Crowd can only connect to external directories via LDAP.

This is a major block if you’re using a modern cloud Identity Provider, like Okta or OneLogin, that you want to connect to via SAML or via the API.

Crowd won’t be able to integrate to any IdP using SAML.

But if your users are on Microsoft Active Directory, Crowd can be used as a central LDAP server connecting Active Directory to Jira and the other Atlassian Applications.

Learn how to configure an LDAP Directory Connector with Crowd

2. Crowd SSO as an integration between Atlassian apps

When Jira and Confluence are integrated with Crowd, a user can click a link to Confluence in a Jira ticket without being prompted to log in again.

While Atlassian talks about it as Crowd SSO, in reality that SSO experience is only internal to Atlassian apps. In fact, since Crowd can only use LDAP to connect to an external directory, it doesn’t support any SSO standards like SAML or OpenAuth/OIDC.

Can Atlassian Crowd be combined with SAML SSO?

Sometimes customers think that if they have Crowd, they don’t need our SAML SSO app for their Jira, Confluence, or Bitbucket. Or that if they buy the SSO app, they will have to stop using Crowd.

That’s not necessarily the case. In fact, we have an add-on for Crowd that ensures that our SAML SSO apps are capable of authenticating with remote directories!

Some complex requirements can be met with a combination of Crowd and a SAML SSO app

Whether it makes sense to combine Crowd with SAML SSO depends largely on the situation of the customer and how important the jobs are that Crowd is doing. For example, some of our customers want to configure Crowd as a source for user synchronization.

There’s a good chance that combining Crowd with SAML SSO is beneficial if the answer to any of the following questions is affirmative:

• Do you have multiple Atlassian applications?
• Do you need to manage group memberships outside of your IdP?
• Do you need to add non-employee users to Atlassian applications and have to do it outside the IdP?

Let’s look at three examples for a better picture.

Use case 1: Replace Crowd with SAML SSO and stay on Active Directory Federation Services

The 0-level use case: migrate away from Crowd to implement a full SSO solution. In this case, Active Directory connectivity via SAML is achieved through AD FS.

So, when can Crowd simply be removed from the equation?

Usually this happens when Crowd does no longer serve an important function and can be replaced effectively by the combination of Active Directory Federation Services and a marketplace app like SAML SSO.

Ingredients:

• The Identity Provider is (or will become) the single source of truth for user identity, including access policies, group memberships and permissions. Administrators will then be able to manage the entire user lifecycle from the Identity Provider without any manual jobs in the local Atlassian directories.
• Besides taking care of authenticating the users, the SAML SSO app carries all the information from the Identity Provider into the Atlassian apps, so it’s always current. This can happen either via SAML attributes or via API-based synchronizations.

These migrations from Crowd can take many forms. Sometimes the IdP doesn’t change, because the customer will keep using ADFS or Azure Active Directory via LDAP. Sometimes the migration may include an upgrade to a modern cloud Identity Provider.

Bottom line: Independently of the circumstances, this kind of migration puts Atlassian applications in the same terms as any other web enterprise software, streamlining user lifecycle management.

Use case 2: Use SAML SSO to Integrate Crowd with Okta (or any other IdP) and streamline group management

When users are managed centrally and permissions locally

Sometimes an organization wants to manage user identities and authentication policies centrally, and delegate application permissions to the application admin.

But coordinating groups and permissions when you have multiple instances of Jira and Confluence with users in the thousands can prove as mission impossible.

In this case, Crowd simplifies work by centralizing the management of group memberships across Atlassian instances.

Ingredients:

• An Identity Provider that only stores user information, like username, email and full name, plus authentication policies like 2FA
• A SAML SSO app for authenticating users from the IdP and creating them upon their first login (JiT provisioning)
• Crowd to manage group memberships and permissions into the Atlassian apps

Take for example a project related to the development of a new cloud application called Lighthouse. Members of this project will have specific permissions:

• to commit code into Bitbucket branches
• to publish release notes and internal documentation in the application’s Confluence space
• and to work on the corresponding user stories in Jira

Without Crowd, administrators must do a lot of repeated work in each application, including:

• creating the Lighthouse group
• pulling members into the group

Bottomline: With Crowd, these actions can be centralized and rationalized. That tends to be very valuable in complex enterprise settings where hundreds of ongoing projects are scattered across 6 instances of Jira and 3 Confluence environments, for example.

Use case 3: Use SAML SSO to configure Crowd Data Center as an IdP with SSO 2.0

Did we say Crowd doesn’t do SAML? Well, that’s almost always true.

Crowd Data Center does use SAML, but only to provide a more consistent login experience with SSO 2.0. However, under SSO 2.0 Crowd still cannot connect to an IdP using SAML.

And when it’s enabled, customers can configure Crowd as an IdP in resolution’s SAML SSO app.

This can turn out to be very helpful when an admin needs to add users but doesn’t have the permission to use the main Identity Provider. For example, some corporations have strict policies for provisioning user accounts for employees that don’t apply to other types of users like contractors, partners, or interns.

Crowd Data Center can then be set up to manage those temporary accounts, which can be a couple of dozens or several hundreds. Users will still have the security and usability benefits of SSO, and administrators won’t have to manage them manually.

Ingredients:

• North of 300 users in Atlassian applications.
• Large numbers of external users including contractors, auditors, or interns
• A main Identity Provider with strict policies for provisioning user accounts enforced by a central Identity team
• Crowd Data Center as an additional Identity provider for the external user accounts
• SAML SSO to authenticate into Atlassian applications from both IdPs

Conclusion: Is Crowd needed in the way you currently manage Jira users?

Organizations that have been using Crowd for years sometimes look at a difficult trade-off.

Staying in Crowd fails to put the company up-to-date with the type of seamless, cloud-based authentication that is expected in the times of remote-first collaboration; but a migration can be painful, particularly if current user management practices leverage the advantages of the centralization that Crowd represents.

But that trade-off is based on false assumptions. Although Crowd can be replaced by a SAML SSO app, it can also coexist with it to maximize the advantages of both products: A robust, centralized directory for all Atlassian products and instances, and fluent user authentications between the Identity Provider and Atlassian apps.

Start your Atlassian jorney towards streamlined user management