nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

SAML SSO for Jira,Confluence,Bitbucket

Matt Wilson_grxhwo

I'm getting requests to introduce SSO to our environment.

Quick background...

We've got Jira, Confluence, Bitbucket (also Crucible, but we're phasing that out). Jira and bitbucket use Active Directory, Confluence actually uses Jira for authentication (as do our Jenkins servers).

We have SAML SSO corporately, but not for the Atlassian tools.

Is it better to go with Crowd for SSO, or am I better off looking at the individual plugins available for each tool and connect to my corporate SSO?

Can crowd connect to my corporate SSO? I not too concerned about introducing another SSO source, but I know I'll get questions about why we aren't using the corporate site.

Crowd appeals to me because I'd like to manage all my users in one place rather than the two I'm doing now.

Any ideas on what the best direction is?

Accepted answers

All comments

Tinker Fadoua

@Matt Wilson

You can use Crowd with AD. There will be no issues.

The reason I always like to have Crowd not only because it is easy to configure with Atlassian Tools but because in case I have to grant access to external users to Jira, Confluence,... I won't have to add them to AD (which I was always told it is not a good practice to add external users to the company's AD.

Best,

Fadoua

Christian Reichert (resolution)

Hi @Matt Wilson

Full disclosure, I work for resolution, a marketplace vendor. We publish the no.1 SAML/SOO Apps for the Atlassian Data-Center & Server Suite of products.

If your corporate SSO Platform can be the single source of truth for all (or most) User accounts (and maybe even groups), then I would probably go with individual plugins.
Then you can give your Users a real Single Sign-On experience with across most of your enterprise. With something like Crowd, they would usually still need to log in at least once.

Also, while "individual" plugins may sound like a lot of overhead, the reality is there are at least three vendors (like us) who have the same plugin across all Atlassian products, including Crucible. It means the UI & configuration are the same across all products, so once you have done it once, it'll only take a few minutes more to do the same config on the other products.

Cost-wise it's probably similar if you compare Crowd or a 3rd party plugin - you'll have the license fee on the plugins, but on Crowd, you have a license, maintenance, server & you need to manage/upgrade the application.

The latter part (saving myself an extra application to maintain) is the main reason why I personally only deployed Crowd whenever there was a significant benefit from having it.

There SAML Plugins & Crowd plugins for Jenkins - I have no experience with either. So I can't give you a recommendation there.

If you like to see how a setup for our plugin looks with Microsoft AD FS, which you likely have as an IdP, here are some links:

I hope that helped a bit. Happy to answer more questions if you like.

Cheers,
Chris

Matt Wilson_grxhwo

Thanks for the info...

That is the compelling argument for going with the plugins. I know the higher-ups would love to see us using our corporate solution (since its actually a product we sell). Not adding another server would be nice as well...

The downside of the plugins is that I'm still managing 1000+ users in now even more tools (i.e. I'd now have to manage Jenkins and Confluence directly in those as well).

Matt Wilson_grxhwo

thanks for replying..

Are you using Crowd server or Data Center? All our Atlassian tools are server, but I'm not so sure I understand what one provides over the other. My initial reading leads me to believe I need data center, but the yearly cost is significantly higher...

Tinker Fadoua

@Matt Wilson

I use all my Atlassian Tools in Server version.

Data Center will be interesting if you will be adopting it for all your instances so that you never have any downtime(you have zero downtime even when you are upgrading your instances). But yes the costs are way higher than Server.

I will suggest to stick to Server if that's what you have. Think about the cons and pros if you decide to add Crowd to your stack. It will also help you with SSO which to me is a great feature as my users get frustrated from having to login to each application when they all are on the same network.

Best,

Fadoua

Ed Letifov _TechTime - New Zealand_

Hello, @Matt Wilson

Unless you install a SAML SSO app for Crowd and then individual "connector" apps into each Server application to connect to that, I am not sure why Crowd is even in the picture, since by itself it will not provide you with SSO capability between the Atlassian applications and your corporate SSO on Server editions.

It will give you SSO across Atlassian applications, sure (as in: login with user/password into one, switch to the other, don't have to login again) and it will hook you up to an Active Directory or LDAP in the backend (i.e. give you "same login") but won't give you SAML SSO to your own SAML IdP.

The only way to achieve SAML SSO on Server is by installing individual SAML SSO apps.

Ours is EasySSO and besides SAML it offers flexibility with NTLM, Kerberos, X.509 and HTTP Headers authenticators for multiple integration scenarios.

To ease your user management troubles - look at our UserManagement line of apps. It won't really ease the pain of adding/removing groups from individual users, but will take care of inactive ones with Scheduled User Actions and help with any bulk operations via Bulk User Actions.

Christian Reichert (resolution)

Hi!

It depends a little bit on what you mean with "managing" 1000+ Users in each Application exactly.

For example if you IdP (corporate SSO Solution) knows about group memberships and can send them in the SAML responses, then you can automate User creation & Update as well as group assignment & removal completely.

Possibly using User deactivation - but our Plugins already have built-in functions that allow you to disable Users that have not logged in for a certain amount of time. (And the IdP blocks them from login as soon as a User gets disabled / deleted on the IdP).

So it depends more on some of the details which will be a great solution for you.

I appreciate that you may not always be able to share details of your use case in a public forum. So if you prefer to discuss some more details in private, you can always schedule a free Screenshare Session via https://resolution.de/go/calendly

Cheers,
Chris

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

server

jira

cloud

bitbucket

jira-server

sso