Check whether you need Atlassian Guard and a cloud IdP

You can achieve a similar user management setup to the one you currently have in server. However, you’ll most likely need the following additional products if you’re using anything more than a Jira or Confluence internal directory:

• Cloud identity provider

• Subscription to Atlassian Guard Standard (formerly known as Atlassian Access)

This is because you can’t connect an external directory directly to Atlassian Cloud, you need a cloud identity provider in-between. Connecting one requires a subscription to Atlassian Guard Standard in most cases.

This is how it all connects:

Exceptions are our custom integrations (Google Workspace, Azure AD for nested groups) that provide some user provisioning and single sign-on capabilities without Atlassian Guard Standard.

Compare your current user management setup

We’ve summarized the most common user directory and authentication setup in Server or Data Center and explained what you need to achieve a similar result in cloud:

• Internal directory only

• Internal directory with LDAP authentication

• External user directory or Atlassian Crowd

• SAML authentication

• OpenID authentication

• Google Workspace user provisioning and authentication

Internal directory only

This setup is primarily used for small instances, where there is no need for external user management. It only uses Jira or Confluence’s internal user directory, not an external directory.

How it worked in Server / Data Center

All user details are created, managed, and stored in your product’s internal directory.

• Users log in with the username and password stored in the internal directory for that product.

• Admins add and remove users in the product manually.

• Admins create groups to manage product access in the product manually.

How it will work after migration to Cloud

You can achieve a similar setup in Atlassian Cloud.

• Users log to their Atlassian Account with their email and password.

• Admins add and remove users at admin.atlassian.com.

• Admins create groups to manage product access at admin.atlassian.com.

Requires Atlassian Guard Standard or a cloud IdP?

No, you don't need Atlassian Guard Standard or a cloud IdP.

Internal directory with LDAP authentication

This setup is used when you only want to authenticate users against a central directory.

How it worked in Server / Data Center

Each Server or Data Center product is connected to the external LDAP directory, and that directory is only used to authenticate user passwords on login.

• Users log in with the username and password stored in the LDAP directory.

• Admins add and remove users in the product manually.

• Admins create groups to manage product access in the product manually.

How it will work after migration to Cloud

An organization admin could configure SAML single sign-on so authentication is managed centrally.

• Users log in via an identity provider (SAML single sign-on)

• Admins add and remove users at admin.atlassian.com.

• Admins create groups to manage product access at admin.atlassian.com.

Requires Atlassian Guard Standard or a cloud IdP?

Yes. You will need Atlassian Guard Standard and your own identity provider.

External user directory or Atlassian Crowd

This setup is used when you want to manage user details and product access in a central directory.

How it worked in Server / Data Center

Each Server or Data Center product is connected to the external LDAP or Crowd directory, and that directory is synchronized to populate user details and group memberships. There are numerous variations of this approach.

• Users log in with the username and password stored in the LDAP or Crowd directory.

• Admins add and remove users in the external LDAP or Crowd directory.

• Admins create groups to manage product access in the external LDAP or Crowd directory.

How it will work after migration to Cloud

An organization admin could configure SAML single sign-on so authentication is managed centrally, and SCIM user provisioning to create accounts and manage group memberships.

• Users log in via an identity provider (SAML single sign-on)

• Admins add and remove users in the identity provider.

• Admins create groups to manage process access in the identity provider.

Note that the identity provider directory may be populated from an LDAP directory if supported by the provider.

Requires Atlassian Guard Standard or a cloud IdP?

Yes. You will need Atlassian Guard Standard and your own identity provider. SCIM user provisioning is only supported for selected identity providers.

SAML authentication

This setup is used when you want to authenticate users against an identity provider using SAML single sign-on.

How it worked in Server / Data Center

An identity provider or Crowd Data Center is configured for SAML single sign-on authentication in your Data Center product. Generally, either the product is also connected to an external LDAP or Crowd directory to populate users and group memberships, or Just-In-Time (JIT) provisioning is enabled.

• Users log in via an identity provider (SAML single sign-on)

• Admins add and remove users in the external LDAP directory, Crowd, or identity provider.

• Admins create groups to manage product access in the external LDAP directory, Crowd, or identity provider.

How it will work after migration to Cloud

An organization admin could configure SAML single sign-on so authentication is managed centrally, and SCIM user provisioning to create accounts and manage group memberships.

• Users log in via an identity provider (SAML single sign-on)

• Admins add and remove users in the identity provider.

• Admins create groups to manage product access in the identity provider.

The identity provider directory could be populated from an LDAP directory if supported by the provider.

Requires Atlassian Guard Standard or a cloud IdP?

Yes. You will need Atlassian Guard Standard and your own identity provider. SCIM user provisioning is only supported for selected identity providers.

OpenID Connect authentication

This setup is used when you want to authenticate users against an identity provider using OpenID Connect single sign-on.

How it worked in Server / Data Center

An identity provider is configured for OpenID Connect single sign-on authentication in your Data Center product. Generally, either the product is also connected to an external LDAP or Crowd directory to populate users and group memberships, or Just-In-Time (JIT) provisioning is enabled.

• Users log in via an identity provider (OpenID Connect single sign-on)

• Admins add and remove users in the external LDAP or Crowd directory.

• Admins create groups to manage product access in the external LDAP or Crowd directory.

How it will work after migration to Cloud

OpenID Connect is not currently supported as an authentication method. You need to use an identity provider that supports SAML 2.0.

Google Workspace user provisioning and authentication

This setup is used when you want to authenticate users using Google Workspace (formerly G Suite).

How it worked in Server / Data Center

Server and Data Center products don’t provide the ability to connect to Google Workspace. There were some third-party integrations available.

How it will work after migration to Cloud

You can sync your Google Workspace domains and users under those domains to Atlassian Cloud. This allows all users on your email domain to log in to Atlassian products with their Google account. Users are added to a default group on first login. Learn how to connect to Google Workspace

• Users can choose to log in using their Google account.

• Admins add and remove users in the Google Workspace admin console.

• Admins create groups to manage product access at admin.atlassian.com.

Requires Atlassian Guard Standard?

No, you don't need Atlassian Guard Standard to sync all users from Google Workspace to a single group called 'All users from Google Workspace'. However, if you want to be able to sync group memberships or require people to log in with Google, you will need Atlassian Guard Standard.

Related pages

Get started with migrating users to Atlassian Cloud