Simplifying Atlassian Crowd Security

Atlassian sells its Crowd software as a way to centralize identity management for your Atlassian applications. Crowd lets you manage users from multiple directories via a single admin console and control application permissions from one place. It gives you Single Sign On, group permissions, one area from which to control your Atlassian security, user aliases, and more.

All very nice to have…but not the main reason why I use Atlassian Crowd. I use Atlassian Crowd because of the way it simplifies having a single “source of truth” to point to when setting up security in Atlassian applications.

The problem: tying directly into Active Directory or other “sources of truth”

Your “source of truth” is what tells your applications who your legitimate users are and what security groups they belong to. In effect, the single source of truth lets you know who has access authorization, and who does not.

Many people choose to use Active Directory (AD), Google authentication or other database as their single source of truth, and then implement this by pointing JIRA, Confluence and other Atlassian apps directly at AD (or Google authentication, or whatever). With this approach, information is pulled directly from the source into the Atlassian app.

The problem with taking this approach comes up when the structure of an Active Directory or other source of truth changes. For example, new groups are created, groups of people are moved from one structure to another within different trees in AD, etc. If you’re pulling that information directly into, say, JIRA, these underlying changes will have an immediate impact on the security of your Atlassian Application, and this will change how you will have to pull the information in. Which means every time the structure of an AD or other source of truth changes, you have to go in and reprogram what’s being pulled into JIRA to prevent your users from losing their access permissions, or, worse, to prevent users from gaining access they shouldn’t have.

When you pull directly from AD, changes to AD create a big headache for your Atlassian administrators. All of the other sources of truth can cause these types of problems, too.

You can avoid this problem by using Atlassian Crowd

Using Crowd lets you extract yourself from these issues. When you use Crowd you can still keep the same source of truth. Only now you’re pulling the information from this source into Crowd instead of directly into your other Atlassian apps, and then letting Crowd act as a filter for that information. I like to think of this as being like “crowd control” (which might be the origin of the application’s name!).

With Crowd you can use multiple Active Directories, not just one, and disburse the information to multiple Atlassian applications. You can also integrate various sources of truth, such as Google authentication, and have Crowd merge and control it all for you. Crowd lets you pull user information from these sources, and then set which applications and groups each user can access. If a user is deactivated in AD, that information will get pulled into Crowd, which will then deactivate that user’s access to your Atlassian tools as well.

The big benefit here comes when something changes in the structure of an Active Directory or other source of truth. Instead of having to go into each application and reprogram things, you can simply let Crowd control the entire situation for you. Regardless of what happens to the structure of your underlying source of truth, your Atlassian apps will still keep humming along just fine. Using Crowd reduces the work, and minimizes the impact that changes in your sources of truth can have on the security of your Atlassian tools.

Keep Crowd simple

The KISS principal of keeping things simple is something to strive for when setting up Atlassian security and using Crowd. Using Crowd—correctly—does just this, and it can drastically cut down on the administrative overhead associated with security and access for your Atlassian applications. Like with anything, if you make it overly complicated, managing it will also be complicated and time consuming.

For example, many people pull in ALL of their security Groups when they connect Crowd to their AD. Instead, I recommend only pulling in a limited subset of security Groups. Use only the Groups you require. Instead of pulling in all 3,000 of your security Groups, pull in ten or twenty. Just by doing something like this alone, you will make the management of security Groups significantly less complicated.

In fact, keeping it simple is something that I recommend for your entire Atlassian environment. That was the underlying theme of my previous article on “How to Avoid Problems with Jira Permissions” as well.

Conclusion

At Coyote Creek we have extensive experience keeping things simple, and “untying the knots” that clients create when they do not keep things simple. If you need help in this area, please do not hesitate to give us a call.

Switching to Crowd—and getting it set up in as simple and straightforward a manner as possible—is well worth it. If you do this right, the payoff can be huge: management of your Atlassian security will be reduced; users will have access to what they need, without having access to what they do not need; and maintaining users and access will become a much faster and simpler process.