What is Atlassian Access?
Let’s start at the beginning, what is Atlassian Access, why is it important to know and understand it, and why is it being talked about so much? We are going to try to solve all the doubts related to this Atlassian product, as well as help you really understand how it works, by sharing our best tips.
Atlassian Access is an organisation-wide subscription that allows you to connect any Atlassian Cloud product to your identity provider. What does this really mean?
It allows you to enable authentication and monitoring capabilities across all domains in your organisation.
- Enable SAML single sign-on.
- Enable automated user provisioning.
- Enable mandatory two-step verification.
- Enables revocation of unauthorised API tokens.
With this in mind, it doesn’t matter how many Atlassian products you have (Jira, Confluence, Bitbucket…) as access to all of them can be controlled from your identity provider.
However, it is important to know that Atlassian Access has many peculiarities that you need to know and understand in order to configure it correctly.
General configuration
It is very important that when you decide to start with the configuration of Atlassian Access you do it with the right people: there must be an active directory manager, with sufficient permissions to make changes and knowledge to do so. There should be a Jira administrator who coordinates with this person at all times. This is teamwork, it is the only thing that will ensure success (smile).
The steps to follow for the configuration of Atlassian Access, in a simplified way would be the following:
- Verify domain: Before configuring Atlassian Access in the environment it is necessary to verify the domain. You can verify as many domains as necessary.
- Claim accounts: Claiming existing accounts in Atlassian from the verified domain will convert them into managed accounts. You do not need to do this step at the same time as verifying the domain but it will be necessary in order to use Atlassian Access. From this point on all accounts that have access to any Atlassian product start to be billable for Atlassian Access. This does not mean that they are billable for the corresponding product if they were not before.
- Install Atlassian Access: Please note that from this moment the 30 days of the free trial will start counting. From that moment on they will start charging for the product, for all those synchronized users with access to any Atlassian product.
- Directory creation: Once Atlassian Access is installed we have to create a new Directory. The directory will initially have no users or groups.
- Synchronisation with Active Directory: This configuration will be done in parallel between the active directory and Jira. It is necessary that the person in charge of the active directory introduces the API keys that we will have extracted from Jira. At this point, the users will become provisioned users. The initial synchronisation may take several minutes. Depending on the volume of users. When finished, you will see the users in Atlassian Access.
- SSO Configuration: If you want to have a single sign-on, then you need to configure it in Active Directory. Depending on the most appropriate configuration in each case. And you will also have to configure it in Atlassian Access.
- Authentication policies: You can have multiple authentication policies to define which users log in with SSO and which don’t as well as setting a policy that some users are not billable.
If you want to ensure success while carrying them out, then you should consider the following recommendations:
Verify domain:
How long does it take to verify a domain?
When you go to verify the domain, you are given 3 options:
HTTPS -> It takes between 24h and 72h to verify the domain.
DNS -> It takes between 24h and 72h to verify the domain.
GSUIT, which is Google’s directory -> the domain verification is done instantly and the provisioning of users as well.
Are users notified in any way?
A banner will be placed in the application notifying all users. So it is preferable to give prior notice that this configuration is being done, before users start asking what is going on in the instance.
Claiming accounts:
How can we know which users are licensed (billable) before claiming AD accounts?
Once the domain has been verified, it gives us the option to Claim accounts and before completing this step, it gives us the opportunity to download an Excel file to see all the users of the domain and to which application they have access. We can do this part without actually claiming users. Without even having Atlassian Access you can verify the domain and claim the accounts as this is not an Atlassian Access exclusive feature.
What are managed accounts?
Managed accounts are all those Atlassian accounts that are part of your verified domain.
What’s the benefit of having managed accounts if you don’t install Atlassian Access?
It allows you to verify the domain for all users and adjust the instance settings so that only users in that domain can access the portal or Jira for example.
What happens to the managed accounts if I decide to remove the domain claim? Managed accounts would no longer be managed by the organisation and would be normal users but would not be deleted, modified or lose access to Jira, Confluence…
What are billable users for Atlassian access?
Atlassian will charge you for each user account that has been claimed that has access to one of Atlassian’s products (Jira, Confluence, Bitbucket, Trello…) and is not in a Non-Billable policy. Only in Cloud products, if users have accounts in server or data center products (Jira, Confluence, Bitbucket…) they do not count as billable. The Atlassian Access license is separate from the product license (Jira, Confluence, Bitbucket, Trello…).
Install Atlassian Access:
What’s built into Atlassian Access that can’t be done natively? Why install it?
Verifying domain and account claiming is NOT an Atlassian Access-only enhancement. You need Atlassian Access if you want to use SSO and provision (sync) users from identity providers (AD). This table lists what is available for managed accounts in any organisation:
Synchronisation with Active Directory:
What are provisioned users?
Are the users that I sync with AD and also allow me to have SSO and two-step verification.
Will the synchronised users have access to Jira automatically?
It depends on what you have configured in Product Access. If you have the option to automatically give access to new users, yes. If a group is synchronised and that group has access to Jira then all users in that group will also have a Jira licence.
What happens to provisioned users/groups (synchronised with the AD automatically or manually) if you decide to stop using Atlassian access and remove the subscription?
Users do not lose their accounts or access to Atlassian products ( Jira, Confluence, Bitbucket, Trello..) nor are they deactivated and remain managed accounts for the organisation which means that only an admin of the organisation can deactivate and modify them (only from the interface in this scenario) but they would not be able to sync and use SSO if Atlassian Access is removed. Managed accounts are NOT a unique enhancement to Atlassian Access but being able to use SSO and sync is. Provisioned groups and users remain intact. However, your links between Atlassian and the identity provider will be broken and the identity provider will no longer maintain the accounts.
What happens if you move or remove a user from a provisioned group from AD?
In that case the Atlassian account will be automatically deactivated. The user data (Issues, comments, assignments etc) is kept.
Can several different Azure ADs be synchronised against a single Atlassian Access? In principle and for now, an Atlassian organisation can only connect to a single external identity provider for SAML single sign-on per organisation. This means that if multiple domains are verified and claimed in an organisation, all managed accounts will perform SAML single sign-on through the single identity provider configured. The reason for this is that Atlassian Access controls enterprise-wide access for all users in the claimed domain and not specifically site access.
Is it possible to synchronise two different ADs against a single Atlassian Access?
For example, Azure AD + Gsuite. Right now it’s not possible, although it’s on Atlassian’s Roadmap going forward, most likely for Enterprise only. What they recommend is to remove one configuration and put the new one in its place. Disconnect one and connect the other. They do confirm that users would not lose their Atlassian registrations and would not have their logins removed.
SSO configuration:
Can non-billable users use SSO?
If they are non-billable users it means that they are in a non-billable policy that cannot have SSO enabled or do not have access to any product (Jira, Confluence, Bitbucket, Trello…), the latter could access the site via SSO as long as they are in a policy with SSO enabled.
How to enable two-step authentication? It has to be done in the identity provider. In the case of Azure Ad, assuming that 2FA is enabled in Azure at a general level, you have to create a Conditional Access in each Enterprise Application and that is where you can configure that part.
Authentication policies:
You can have multiple authentication policies to define which users are logged in with SSO and which are not as well as set a policy so that users who are inside are not billable. You can move members between policies.
There are several policy use cases that can be configured.
Billable policies: any policy you create will be by default billable. You can create as many as you want but there will always be a “default” policy that you cannot delete.
- Billable policies can be enabled with the enhancements that are not allowed for non-billable policies (SSO, two-step verification).
- If you want to remove this policy, you will have to change another billable policy to “default”.
- This policy cannot be removed unless you make another policy the default.
- It is the default for new users synchronised with the AD automatically or manually.
Non-billable policy: any policy can be configured as “non-billable”, but only 1 can exist.
In this policy you can add users to count as non-billable and not add to the Atlassian Access subscription.
- Cannot use SSO
- You cannot require two-step verification
- Cannot add users that have been synced to the AD automatically or manually
- Cannot be a default policy
Other frequently asked questions
- How do I delete a managed user? From the interface under User Managment > Managed accounts and it is done manually. If an org admin manually deletes a user, it has a grace period of 14 days and appears with the text “for deletion”. If a user is deleted in the AD it is deactivated but a user is never deleted by provisioning (synced to the AD automatically or manually) and has no grace period in that scenario.
- How to get Atlassian Access SEN? Exactly the same as the rest of Atlassian products, from the https://my.atlassian.com/ page. The problem is that it is not so intuitive to see which instance it corresponds to, because the name is a code and not the name of the instance as usual. Usually just below the instance subscription (Atlassian Cloud) will appear its corresponding Atlassian Access. You will need this SEN every time you need to report a ticket to Atlassian support about Access.
* Please note that this information is subject to change, as Cloud products are continually evolving.
María Ferreño December 27th, 2022
