Atlassian Access and cloud migrations

Still need help?

The Atlassian Community is here for you.

Ask the community

As you start to plan your migration journey from server to cloud, you may also be thinking about what your current strategy for security and governance means for your organization after you migrate. Use this page to identify your current server setup and what we recommend when you migrate to cloud.

Depending on your current user management setup, we may recommend subscribing to Atlassian Access for enterprise-grade security and centralized administration across all your Atlassian cloud products. Access provides visibility and control into your user activity alongside time-saving and standardization at scale. Customers from Softbank to Lululemon rely on Atlassian Access for secure user login through SAML single sign-on while simplifying administrative tasks with automated user provisioning.

When you sign up for your cloud site, you’ll get access to your organization’s administration at admin.atlassian.com, where you can subscribe to Atlassian Access. Your organization provides one place where you manage all cloud users with your company’s domain(s). Learn more about how organizations work at Atlassian organizations.

Use the following sections to identify your current setup and security needs, review our recommended cloud setup, and determine if Atlassian Access is right for your organization:

Internal directory (with Embedded Crowd)

This server setup applies if you administer users from Jira or Confluence or if you use Crowd with single instances of Jira or Confluence. In this case, Crowd itself isn't connected to any other external directory.


Server setup before migration

Cloud setup after migration

User and group management

Admins add and remove users and manage access with groups from Jira or Confluence.

Admins add and remove users and manage access with groups from

User login

Users log in with local usernames and passwords.

Users log in to their Atlassian account with their email address and password.

Requires Atlassian Access? No, but you may still benefit from the ways Access can keep your organization secure. Refer to Atlassian Access security policies and features for included security features.

With this setup, you can manage your users and groups at the site level after you migrate.

Internal directory with LDAP authentication (i.e. Microsoft AD)

This server setup applies if you administer users from Jira or Confluence but use LDAP to store passwords so that other connected server software can use the identity information.


Server setup before migration

Cloud setup after migration

User and group management

Admins add and remove users and manage access with groups from Jira or Confluence.

Admins add and remove users and manage access with groups from an Atlassian cloud site.

User login

Users have one set of login credentials, which authenticate against their LDAP credentials.

Admins configure SAML single sign-on so they can manage authentication centrally and users can log in with an identity provider. (Requires Access)

Requires Atlassian Access? Yes, if you want to configure SAML single sign-on.

To manage authentication centrally, you can configure SAML single sign-on for your Atlassian organization with your identity provider. If you don’t have an identity provider, Atlassian offers a partnership with Okta for a free account.

External directory

This server setup applies if you sync from Active Directory or an external LDAP directory and other connected server software uses the identity information.


Server setup before migration

Cloud setup after migration

User and group management

Admins store data about users and groups in an LDAP directory. Changes to user and group details in Jira or Confluence get updated in the LDAP directory.

Admins configure user provisioning with a cloud identity provider to sync users and groups to your organization. You can connect your identity provider to an LDAP or Active Directory. (Requires Access)

User login

Users have one set of login credentials, which authenticate against their LDAP credentials.

Admins configure SAML single sign-on so they can manage authentication centrally and users can log in with an identity provider. (Requires Access)

Requires Atlassian Access? Yes, if you want to configure user provisioning and SAML single sign-on.

To achieve similar results in cloud, set up user provisioning between your Atlassian organization and your identity provider. To manage authentication centrally, you can configure SAML single sign-on for your Atlassian organization with your identity provider. If you don’t have an identity provider, Atlassian offers a partnership with Okta for a free account.

External directory with Crowd

This server setup applies if you use Crowd to manage users from multiple directories and control authentication permissions to Atlassian server or Data Center products from one central location.


Server setup before migration

Cloud setup after migration

User and group management

Admins store data about users and groups in Crowd. Changes to user and group details in Jira or Confluence get updated in the Crowd directory.

Admins configure user provisioning for their external directory with a cloud identity provider to sync users and groups to your organization. (Requires Access)

User login

Users have one set of login credentials from Crowd and use these to sign in to all Atlassian server and Data Center products (i.e. Jira, Confluence, and Bitbucket) that are connected to Crowd.

Admins configure SAML single sign-on so they can manage authentication centrally and users can log in with an identity provider. (Requires Access)

Requires Atlassian Access? Yes, if you want to configure user provisioning and SAML single sign-on.

To achieve similar results in cloud, set up user provisioning between your Atlassian organization and your identity provider. To manage authentication centrally, you can configure SAML single sign-on for your Atlassian organization with your identity provider. If you don’t have an identity provider, Atlassian offers a partnership with Okta for a free account.

SAML authentication from identity provider (including G Suite)

This server setup applies if you configure SAML single sign-on for authentication with a cloud identity provider or G Suite, whether you administer users from an internal or external directory. In this setup, you use might use Crowd Data Center and either the server or Data Center versions of the other Atlassian products. For more details about this setup, see Adding SAML integration to your existing user management infrastructure.


Server setup before migration

Cloud setup after migration

User and group management

If using the internal directory, admins add and remove users and manage access with groups from Jira or Confluence.

If using an external directory, admins store data about users and groups in Crowd Data Center or an LDAP directory. Changes to user and group details in the product get updated in the Crowd or LDAP directory.

If using an identity provider, admins configure user provisioning for their external directory with a cloud identity provider to sync users and groups to your organization. (Requires Access)

If using G Suite, admins sync users (from domains verified in G Suite) to a site. Users from selected Google groups sync but not the groups. You can manually create the groups from the site.

User login

Users have one set of login credentials through single sign-on for all Atlassian self-hosted/server and Data Center products (i.e. Jira, Confluence, and Bitbucket).

If using an identity provider, admins configure SAML single sign-on so they can manage authentication centrally and users can log in with an identity provider. (Requires Access)

If using G Suite, users with verified domains can be required to log in with Google (SSO).

Requires Atlassian Access? Yes, if you use an identity provider. No, if you use G Suite, but you may still benefit from the ways Access can keep your organization secure. Refer to Atlassian Access security policies and features for included security features.

To achieve similar results in cloud, set up user provisioning between your Atlassian organization and your identity provider or connect to G Suite. To manage authentication centrally, you can configure SAML single sign-on for your Atlassian organization with your identity provider or connect to G Suite. If you don’t use an identity provider or G Suite, you can manage your users and groups at the site level.

Last modified on Jan 21, 2020

Was this helpful?

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