What is Atlassian Access?
Atlassian Access provides enhanced security and governance for Atlassian cloud products across your organization. This can come to life in multiple ways, such as enforcing single sign on or two step verification, automating user provisioning and deprovisioning, applying different authentication policies, getting insight into organization activity and more. We'll explain what each of these features are and how to set it up for your organization.
How much does Atlassian Access cost?
Atlassian Access is an additional subscription applied across your Atlassian cloud products.
Each billing cycle (monthly or annually), you are only charged for the number of unique users provisioned to a product supported by Atlassian Access regardless of how many products any one person is using. For example, if Sally has access to Jira Software, Confluence, and Bitbucket, you’ll only pay for her once each billing cycle.
For Jira Service Management, you are only charged for the unique agents licensed on the product. Users who only create requests via the Jira Service Management portal aren't licensed, so you will not be charged for them.
Atlassian Access Features
Domain verification
The first thing we'll cover is domain verification and it stems off of the concept of an Atlassian organization. An Atlasian organization gives org admins the ability to see all of their cloud sites and users in one central location. There’s a process called a domain claim where Org admins can verify their ownership of their organization’s domain.
For example, let’s take an organization called Acme global with the domain acme.com. Once the domain is verified, Acme's organization admins can manage every Atlassian cloud user with an Acme email address. You can also claim multiple domains for your organization, and this is free.
admin.atlasian.com is the central hub for all things admin in Atlasian cloud. Not all admin features require Atlasian Access, but all Atlasian Access features can be found here.
Claiming a domain
Claiming a domain unlocks the ability to manage accounts as an admin by verifying their ownership. You don’t need to have Access to claim a domain, however it is necessary to claim a domain in order to take advantage of most Access features.
This is the interface from which you can claim a domain for the first time or claim additional domains. Atlassian offers two methods – there's DNS through a TXT record, where you go to your DNS host and add a simple string to your text record that can take up to 72 hours to update depending on your DNS host. This is the domain verification method Atlassian recommends.
There's also HTTPS where you download a file and you host this at the root of your domain.
For both of these, Atlassian has a verification job running continuously, to verify that you continue to own the domain. If at any point the DNS record changes or the file is moved away from the root of your server. the verification job will fail and your domain status will go down to unverified.
After verifying your domain, you can optionally claim accounts. This will convert those users to managed accounts.
User Lifecycle Management
Instead of spending hours a week manually adding and editing user permissions and access to each product, connecting an identity identity provider will let you assign product access based on groups to automate provisioning and deprovisioning.
For example, marketing may need access to Confluence and Jira. And the engineering team may need access to Confluence, Jira, and Bitbucket.
By automating user provisioning and deprovisioning, you can feel confident that whenever someone joins or leaves that specific team, their Atlassian Cloud access is always up to date with your organization's identity provider. So you don't have to add and remove access per product per user.
Atlassian access supports Okta, Azure AD, Google Workspace and Onelogin. Organizations that have custom directories can leverage the Access APIs to build their own custom connector.
Setting up automatic user provisioning
To set up automatic user provisioning with Okta, refer to this Atlassian guide that has step-by-step instructions.
Single Sign On
Not only will SSO help secure your company's data, It’s also a very seamless and easy way for your users to log in to Atlasian cloud.
Similarly to user provisioning, setting up SAML SSO involves generating tokens and copying them back and forth between your identity provider and Atlassian, albeit with a couple additional steps.
So SCIM and SAML work great on their own, but even better together. You can provision users from an IDP into your Atlasian organization and then hand off SSO to the same identity provider.
This lets you centralize all your user creation, login and security in one place. If your users are using Google workspace, you can also use Atlassian access to enforce login with Google.
If your identity provider is listed here, then use the identity provider instructions to set up SAML single sign-on.
Security Features
If you don't have an identity provider today, you can still apply security features through Access.
To apply security features, head to the authentication policies page. You can add multiple policies, but we're going to go into the default policy for all users.
Within here, you can use single sign on for SAML, but if not, your other options are still available, you can require two factor authentication.
You can set a password policy, which mandates how strong your passwords should be, as well as their expiration date. You can also set idle session duration timeouts so that your user accounts are automatically logged out after a set period of time of idling.
Authentication Policies
Organizations typically have different teams or applications that deal with varying levels of data sensitivity. Atlassian Access provides the ability to set multiple authentication policies to allow for the right level of security for each.
For example, the marketing team which has access to Confluence and Jira only needs to have SSO. Whereas, the engineering team requires 2-Step Verification in addition to SSO since they also have access to Bitbucket, which might have more sensitive information.
You can also set up a test single sign on policy with a few users to make sure you've configured SAML single sign on settings correctly before rolling it out to the entire organization.
Setting up authentication policies
To set up and configure authentication policies for your organization, refer to these instructions.
Organization Insights
Next up is the reporting available in Access with organization insights. This is available within the Security tab.
This helps you better track user adoption of Atlassian cloud products and evaluate user security to help inform decisions.
For example, if you see that there's a lower user adoption than anticipated for a product, you can work with that specific team to see if you can increase adoption or get rid of it.
You can filter products as well as select the time bounds that you want to see. You can also see active users by product broken out here and export those lists of users.
There’s also an organization audit log available to view a comprehensive log of admin activity.
This can help with proactive monitoring of suspicious activity behavior by other admins or retroactive investigation to identify the root cause of an incident that may have occurred.
You can also access this data via the organization REST API.
Automatic product discovery
Automatic product discovery helps to keep you updated on shadow IT usage of Atlassian cloud products.
When you enable this, Atlassian will periodically send an email digest that lets you know what sort of instances your users or people in your organization might have been setting up without your knowledge.
This lets you gain visibility into cloud products that are created by your managed users, without the org admin's knowledge. You can also review each shadow IT product and reach out to those users to remediate the concern, whether that's removing the product or creating a specific one for that user to accommodate for it.
API Token controls
Similar to how users can create products on their own, users can also create and use their own API tokens with Atlassian cloud products.
If users generate API tokens that are old and forgotten, this increases vulnerability of your organization.
With Atlassian access’ API token controls, admins can manage API tokens created by users and can revoke use of API tokens if necessary.
