A Beginner’s Datasheet to Atlassian Access

Atlassian Access is an organisation-wide subscription that connects your Atlassian Cloud products to your identity provider, allowing you to enable enterprise-grade authentication features, and additional oversight, across your company domains. But getting your head around all the terms and meanings for it can be tricky for first-time users.

That’s why in this blog, we’ll be providing you with a datasheet to use for Access. Below are all the terms and definitions you should know when working with it.

What is Atlassian Access?

It’s a subscription to a number of coupled settings, packaged together as an “Atlassian Access” subscription. It’s not considered to be an application in the same sense as Jira and Confluence. It’s important to understand this distinction early on in order to understand how Access is used.

What does Access do?

It allows Atlassian customers to apply security settings, SSO (single sign-on), and enforce user policies across their Atlassian Cloud products.

What Atlassian products does Access work with?

• Jira Software
• Jira Service Management
• Jira Work Management
• Confluence
• Bitbucket
• Trello
• Statuspage

Note: Access does not work with Data Center or Server products.

What are its features?

• SAML single sign-on (Requires a SAML 2.0 identity provider like Azure AD, Okta, Google Workspace or Identity One)
• User provisioning (SCIM) (requires Azure AD, Okta or Google Workspace)
• Organisation audit log
• API token controls
• Enforced two-step verification
• Session duration management
• Product discovery

When is Access recommended?

• Where centrally managed Atlassian user accounts are required.  Without Access, each user is responsible for the management of their individual account.
• When you want to offer single sign-on and SCIM automated user provisioning. This generally becomes a larger benefit with over 250 users. 
• When users want to connect their Cloud apps to an external identity provider other than Google Workspace.
• When you need to enforce user policies across your Atlassian Cloud apps, like password requirements, two-step verification, etc. Customers often have security policies that need to adhere to a minimum password length.

How is Access set up?

Atlassian Accounts or IDs – To use an Atlassian Cloud product, every user has an Atlassian ID or account, which is unique and typically associated with a corporate domain. For example, “amccallum@amazingaccess.com”.

Domain Verification – By using Access, the customer notifies Atlassian that these accounts will be managed by the customer directly. To do this, customers need to claim and verify the relevant domains via this process.

Note: This will require coordination with the customer IT department. 

Managed Accounts – Once domain verification is completed, all the user accounts adopt these claimed domain(s). In this case, “@amazingaccess.com” can be managed by the customer and fall under “Managed Accounts”. 

Note: The organisation admin can also disable any managed users, removing their access to all Cloud products and any systems that use Atlassian accounts.

Licensing –  The licensing metric for Access is your number of “Billable Accounts”.

Billable Account – Any managed account that has access to Jira Software, Jira Work Management, Confluence, Bitbucket, Jira Service Management (agents only), or Trello. When a user has access to ANY of these products, they’re considered billable, meaning you’ll need to pay an Access user licence for them. If one user has multiple Atlassian products (Jira Software, Confluence, Bitbucket, etc.), you’ll only need to pay one Access licence for them.

Pricing – Like other Cloud products, Access can be purchased on a per-user monthly or user tiers on-basis. See this pricing calculator for help. The exception to this is Atlassian Enterprise Cloud, which includes Access as part of the enterprise subscription package.

Organisations, Sites and Cloud products – In order to use Access, it’s important to understand how Atlassian Cloud products are structured. Access is effectively an enterprise-wide subscription that applies to all the Atlassian sites and products within an organisation.

Note: By organisation, we’re referring to an “Atlassian Organisation”, which is a virtual wrapper containing Atlassian products.  

Within an Atlassian Organisation, a customer could have one or more Cloud sites. Each site can contain a number of Atlassian products. Larger Atlassian enterprise customers may have several Atlassian Organisations within their company.

What customers have to pay for – As mentioned before, Access is essentially coupled services. The licence and what you pay for depends on what you want to do and what Atlassian products employees in a customer’s company are using. Customers only have to pay for users when they apply security settings, via authentication policies.

Managed Accounts – A customer can verify a domain, create managed accounts and view/update accounts of managed users at no cost. The managed accounts become billable users when customers start to apply security settings, which are Access features like authentication policies.

Atlassian Access Trial – Atlassian provides a free 30-day trial for Access. Clearvision (now part of Eficode) can provide a quote for a full subscription that will start after the trial ends. If it’s not purchased after the end of the trial, a customer will be unsubscribed from Atlassian Access.

The following changes will happen:

• Managed users won’t log in using SAML single sign-on. Instead, they’ll log in using their Atlassian account. Some users may need to set a new password for their Atlassian account.
• Two-step verification will no longer be enforced, so managed users can choose to disable that for their Atlassian account.

The organisation and verified domains are unaffected by unsubscribing. The organisation admin’s ability to view and update the Atlassian accounts for their managed users will be unaffected.

Authentication Policies – In Access, Authentication policies allow customers to specify authentication settings for different users. Maybe they have user sets with differing security requirements such as employees, partners and contractors etc.

Available authentication policies in Access:

1. Non-billable – Create a non-billable policy when you don’t want to pay for certain users.
   1. You can only set a non-billable policy as the default policy in the local directory.
   2. You cannot have a non-billable policy if using user provisioning (SCIM)
2. Local directory – Contains members you’re not managing in your identity provider. You invite them, or they sign up themselves.
3. Two-step verification – Require a second step when logging in, or make it optional for members.
4. Password requirements – Track minimum password strength and expiration.
5. Idle session duration – Track how long members can be inactive before logging them out.
6. Members – Shows the number of members in a policy. Add or move members from one policy to another.
7. Single sign-on (SSO) – Track when you enforce login to Atlassian through SAML or Google Workspace SSO. You can only enforce SSO in an identity provider directory.
8. Identity provider directory – Contains members you sync or authenticate through your identity provider. You can add and move members between authentication policies.

Note: Customers can set up multiple authentication policies to a max of 20 per Organisation.

Product Discovery – When customers verify a domain, they can see how many managed accounts are in their Organisation. It’s common for customers to discover unexpected users from another site, another part of the business, or employees who simply set up and use free Trello accounts. If a user’s Atlassian account uses the domain they have verified, it becomes a managed account.

Non-Billable Policy – Customers can apply a non-billable policy should a client wish to exclude users from their Access subscription. However, there are some limits as some Access features do not allow non-billable policies, with only ONE non-billable policy being permitted.

Also, customers won’t be able to;

• Enforce single sign-on for users in the non-billable policy.
• Require two-step verification for users in the non-billable policy.
• Add users you sync from your identity provider (Okta, Azure AD, G Suite) to the policy.

Access Features & Non Billable policies

This table explains how key Access features work in relation to non-billable policies.

* All Atlassian user accounts for the claimed domain (e.g., amazingaccess.com).

Common Customer Questions

• Someone else in our business has claimed our company domain (e.g. acme.com). Can we use Access and Single Sign-on?

• •  NO, as a domain can only be claimed by one Atlassian Access organisation/subscription.
  • The customer would need to liaise with their colleagues to have a single Atlassian Access organisation/subscription for their business.

• Can we have multiple Jira or Confluence instances managed by our Atlassian Access subscription?

•  YES. One Atlassian Access organisation can support multiple Atlassian products, even multiple sites of the same product like Jira or Confluence.

• We have loads of free Trello accounts. Can I exclude them from Atlassian Access?

• •  YES. You can define ONE “non-billable” security policy that excludes any included accounts from the Atlassian Access subscription, policies and SAML single sign-on.

• We use GSuite and Google Accounts to sign in, do I still need Atlassian Access?

• •  NO. You can use GSuite and Google login for free.
  • GSuite accounts and domains are synchronised for free and do not require Atlassian Access.
  • Customers can buy Access for enhanced security and coordination.