Prepare for Atlassian Access

Atlassian Access is an organization-wide subscription that connects Atlassian cloud products to your identity provider. It provides enterprise-grade authentication and additional security options and oversight across your company domains.

If you want to provide single sign-on, or provision users from an external directory you need Atlassian Access. Learn whether your organization will need Atlassian Access

If you intend to use Atlassian Access there are several things that need to happen before you migrate your users and groups:

• Set up an identity provider, if you don’t already have one.

• Check for duplicate group names.

• Check for nested groups.

• Identify and check existing cloud accounts.

• Decide how you will provision users.

• Estimate Atlassian Access subscription costs.

• Set up Atlassian Access in your cloud organization.

You may need to consult with other teams or departments to complete some of these steps if you are not able to administer your identity provider and external directory yourself. You should factor this in to your overall migration plan.

Set up an identity provider

Atlassian Access requires you to connect a third-party identity provider. You can use the identity provider of your choice, but some capabilities are only available with selected identity providers. Learn which identity providers we support

If you don’t already have an identity provider, here’s some things to consider when choosing one:

• SAML 2.0 compatible
  To enable single sign-on your identity provider needs to implement SAML 2.0. We don’t currently support OpenID Connect for single sign-on in Atlassian Cloud.

• Supported for SCIM provisioning
  To provision and manage users from your identity provider, you’ll need to use an identity provider we support for SCIM provisioning.

• Flattens nested groups
  If your existing external directory contains nested groups, you may want to choose an identity provider that can flatten your groups, which will prevent issues with product access and permissions after migration. Learn how to prepare nested groups for cloud migration

If you don’t have an identity provider, Atlassian offers a partnership with Okta for a free account. Learn how to create an Okta account for your organization

Check for duplicate group names

Users and groups are centrally managed in Atlassian Cloud. This means members of groups with the same names will become members of a single group with that name when you migrate. This can introduce problems if these groups have different members in Jira and Confluence before migration.

Let’s look at an example. Acme has a group called team-leads that has different members in Jira and Confluence. After migration, these people will all be members of the same team-leads group and will get the same product access and permissions for both Jira and Confluence.

This can have an impact on what people can see and do, and also on your bill, as you may be granting product access to more people than you expected.

You should resolve any group name conflicts before migrating, regardless of whether you plan to use Atlassian Access or not. The time and effort to audit your groups and recreate (or rename) may be significant as you can’t rename groups directly in Jira or Confluence. We recommend you factor this into your migration plan.

Learn more about how groups and permissions are migrated

Check for nested groups

Atlassian Cloud does not support nested groups. When you migrate, only direct members of a group will be added to that group in cloud. This means some people may lose critical group memberships after migration.

Before you migrate you will need to identify if you have any nested groups (where a group is a member of another group), and then decide on your flattening approach. How you do this will depend on your identity provider.

Learn how to prepare nested groups for Cloud migration

Identify and check existing cloud accounts

It’s possible that people in your organization already have Atlassian Accounts. This is usually because they already have access to Atlassian cloud products, including products that aren’t managed by your team. Don’t assume that no-one will have an existing account just because your organization hasn’t approved any Cloud subscriptions.

We recommend you verify your domains and claim user accounts for your domains now, so that you can check the list of managed accounts and clean up any duplicates or inconsistencies.

Learn how to verify a domain to manage accounts

You want to check whether:

• The email address for the claimed account matches the email address in your Server or Data Center site, and in your identity provider (if you have one). If they don’t match they may need to change.

• The Atlassian Access bill estimate matches the number of users you expect to have access to cloud products.

Update email addresses that don’t match

We use email addresses in the migrations process as a way to identify people. You’ll need to make sure that the email addresses match in each user’s Server or Data Center product account, Atlassian Account, and the identity provider primary email (and other relevant email attributes).

If email addresses don't match, you may end up with duplicate Atlassian Accounts. This means the account someone logs in with might not be the same as the account that is associated with their content and permissions. This can be difficult to resolve, so it’s best to make any changes to email addresses before migrating.

You can also use the migration assistants to identify invalid and duplicated email addresses, and fix them automatically during migration. Learn how to assess and prepare users for migration

Decide how you want to provision users

There are several ways you can give new users access to products. These include:

• Approved domains. When you approve a domain, a user can be automatically granted default product access when they attempt to log in, as long as the email address in their Atlassian account matches the approved domain. Learn how to specify how users get site access

• SAML just-in-time provisioning. When you link a domain to your identity provider directory and enforce SAML single sign-on, we can automatically create an account and grant default product access to a new user when they log in with single sign-on. This method doesn’t provide granular control for groups or permissions. Learn about just-in-time provisioning with SAML

• SCIM user provisioning. For larger organizations, it’s more common to use SCIM user provisioning to sync users and group memberships from an identity provider. Learn about SCIM user provisioning

The process for setting up SCIM user provisioning will depend on the products you’re migrating and the data migration method you’re using. You should check our recommendations and make a plan for your migration. Learn our recommendations for SCIM provisioning with Atlassian Access

Estimate Atlassian Access subscription costs and determine whether you need a nonbillable policy

Atlassian Access is an organization-wide subscription that uses a different billing model from other Atlassian cloud products. Atlassian Access is billed per organization. This means you only pay once for each managed account in your organization.

We recommend you check how many user accounts already exist in your Cloud organization, then assess how many will be migrated, so that you can estimate the cost of your subscription.

If you have users that shouldn’t be included in your Atlassian Access bill, you can add them to a nonbillable authentication policy. These users won’t be covered by the security requirements defined in your authentication policies, such as enforcing single sign-on or requiring two-step verification. Learn more about authentication policies

If you don’t want new users who are manually invited, or sign themselves up, to count towards your Atlassian Access subscription, you can choose to make the default policy nonbillable. Learn how to configure a nonbillable default policy

Set up Atlassian Access in your cloud organization

There are a number of Atlassian Access features that you should set up in your cloud organization before you migrate your users and groups.

Verify your domain and claim accounts

If you’ve not already done so, you’ll need to verify your domain and claim user accounts for that domain. You can claim all accounts or just a subset of user accounts on that domain. This is essential to unlock Atlassian Access features.

Learn how to verify a domain to manage accounts

Configure your nonbillable policy

If you decided that you need a nonbillable policy, you can set this up now, before migrating your users and content.

Learn more about authentication policies