User Management Goals

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

Can I use other authentication technologies for my User Directories - such as Google Apps, OAuth, Kerberos or SAML?

Out of the box, these technologies are not supported (with the exception of Google Apps in Atlassian Cloud - see the Atlassian Cloud section below for more information). The Atlassian Marketplace may have third party add-ons to add these authentication mechanisms in your applications.

There may also be other add-ons (outside of the Marketplace) that extend the capabilities of Atlassian Applications.

Back to Top

What are my options in Atlassian Cloud?

Google Apps can be used to provide users and groups to Atlassian Cloud. See the "Set Up Google Apps for your Site" page in our Documentation for more information about configuring Google Apps with your Cloud site. You can use Google Directory Sync to synchronise your LDAP directory to Google Apps, and then use the Cloud Connector to sync those users to your Cloud Site.

Please note that Google Directory Sync is both provided and supported by Google.

Back to Top

Common Scenarios

The following list a few common scenarios of layout for user management. Each example has at least one Atlassian application, along with an LDAP directory containing the business users and groups.

  • An application that is "delegating" to another application relies on that application for its user management. For example, a Confluence that uses JIRA for user management is said to be delegating to JIRA. 
  • A downstream application is one that is affected by changes in the application it's delegating to. If Confluence is delegating to JIRA, Confluence is the downstream application - changes in JIRA may affect Confluence.
Scenario Recommended use case Pros Cons

Direct connection from each Application to LDAP

Small-to-medium organisations with a large number of Atlassian applications
  • Independent configuration of user and group scope per application
  • No single point of failure in applications. LDAP is unlikely to be a point of failure in smaller-to-medium organisations.
  • Maintaining the configuration for multiple applications can be time consuming
  • In larger organisations, multiple syncs against the same LDAP directory may cause performance concerns. This can be mitigated with replication and load balancing at the LDAP directory

Applications delegating to JIRA which connects to LDAP

All organisations with a small number of applications

 

  • One single location for managing users and groups - either JIRA or in the LDAP directory
  • Easy setup for downstream applications
  • JIRA becomes a single point of failure - if JIRA is unavailable, all applications will be unable to authenticate
  • In large environments, delegation to JIRA may cause extra load on JIRA
  • SSO isn't available when delegating to JIRA

Applications delegating to Crowd, which connects to LDAP

All organisations with a large number of applications (both first and third party), or who require SSO
  • Configuring downstream applications is simple
  • Multiple directories can be combined in Crowd which is effective for multiple sources of users
  • Crowd functionality can be extended with the use of third-party add-ons.
  • Provides SSO to Atlassian applications, and compatible third-party applications
  • Provides a framework for other applications to authenticate
  • Not all third party applications are compatible - development work may be required
  • Configuration can be complex, particularly when working with reverse proxies, SSL, etc
  • Crowd becomes a single point of failure

Back to Top

Last modified on Nov 2, 2018

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.