Managing external users/contractors in the cloud
Background
When moving from Server/Data Center to Cloud you need to rethink how access to external (non-company) users are managed. For Server/DC, these users are completely managed by the company, including user life cycle, passport requirements, security controls, and account email. In Cloud, this may differ depending on how they are configured. This document will identify the use cases that you need to be aware of to make an informed decision on how to address external user accounts.
Understanding the different types of accounts
In Cloud, there are two types of accounts that users can have: an Atlassian account and a Jira Service Management portal-only customer account. For the purposes of this document, we will be focusing on Atlassian accounts for external users as the assumption is that they will require Jira and Confluence access, which is only possible with Atlassian accounts.
What is an Atlassian account?
Your Atlassian account is your online Atlassian identity that exists independently of the Atlassian products you use. The account includes attributes like your email address and display name. When an admin sets up permissions or tags you as the owner of specific data, they use your Atlassian account. These accounts can be managed or unmanaged.
A unique email is required for Atlassian accounts.
With an Atlassian account, you use one account for all Atlassian products, such as Jira Work Management, Jira Software, Jira Service Management, Confluence, Bitbucket, Opsgenie, Statuspage, and Trello. You don't need to manage separate accounts for each of these products.
What is an Atlassian managed account?
After an organization admin verifies a domain and claims its users, all the Atlassian accounts with email addresses from that domain become managed accounts. As an organization admin, you can edit the details of a managed account and apply security and access control over your company’s use of Atlassian products.
What is an Atlassian unmanaged account?
An unmanaged account remains owned by the user of the Atlassian account. The account’s email domain has not been verified by an organization admin. These users can update the details of their account and set their own password policy and two-step verification. They fall outside of any security and access controls that an organization admin configures.
JSM portal-only customer accounts
A portal-only customer account for Jira Service Management isn't an Atlassian account and is managed differently (see here for details). You'll only have a customer account if you're logging into another company's Jira Service Management as a customer.
You will need Jira Software Administrator permission to create the 5 custom fields listed below. Refer to Atlassian product documentation on how to create a custom field and add them to the appropriate screens.
Scenario
You have an instance of Jira and Confluence Cloud and want to invite an external user/contractor to collaborate on work. This contractor will require access to one or multiple spaces and/or projects.
Best practice: Use groups to limit the access contractors have to only the data they need to do business.
Option 1: Create a user in your IDP that has an email from one of your verified domains RECOMMENDED
These accounts can be created similar to how they were on Server. Your organization should have established rules around naming conventions for external users — ensure that these naming conventions extend out to the mailboxes.
The unique mail attribute is what users will use to log into Atlassian Cloud and where notifications will be sent to.
The mailbox does not need to be valid if users have SCIM-provisioned access to an Atlassian site.
Users can be managed according to existing company policies (e.g. an account expiration date can ensure that accounts are disabled and no longer active after the end of the contract.) User access controls are also easily audited as they remain the same for other Atlassian accounts if you're using SCIM provisioning.
Depending on your company’s requirements, these users can be configured for SSO and follow pre-existing policies defined by your organization's IDP. You can also set their authentication policy to bypass SSO and instead require specific password complexity and/or 2FA. These policies are managed on a per-user basis and cannot be group based, so depending on your scale, this may not be feasible. Authentication policies that enforce SSO or 2FA will consume an Access license.
How can these accounts receive email notifications to their external email addresses?
As these accounts will be using your verified domain’s email and not their work emails (e.g. an email from their company and not from one of your verified domains), you will need to determine if and how these users will be notified of updates to content. There is no good at-scale solution but options you can explore include:
- Adding a mail alias/forward to on your internal mail server
- Using Automation for Jira/Confluence to send emails to their work email address based on specific triggers.
Option 2: Invite an unmanaged account
Users from non-verified domains can be invited to your site. This can be done with manual invites and requires the user to validate their email address. If they exist in your IDP, you can also use SCIM provisioning to provide product-level access.
SCIM-provisioned unmanaged account
SCIM-provisioned users who are outside of your verified domain will NOT follow any authentication policies set by your IDP.
- Removing a SCIM-provisioned user from an access group will remove their access to the product.
- Disabling a SCIM-provisioned user will not disable their Atlassian account; however it will remove the user from groups provisioned by SCIM. If the user is granted product access via these groups, they will lose access, but they will still have Atlassian site access.
What does site access provide?
- If you have Jira Service Management, then any user with site access can potentially become a help seeker/customer of a Jira Service Management project.
- Users with site access can request access to any products on your site via the request access function: Approve or deny product access requests.
The password complexity and security requirements are left up to the unmanaged user to define and follow. As these are not currently enforceable, they may not meet your organization’s policies.
We have delivered a feature that enables an org admin to configure to require 2FA for external users.
Unmanaged accounts and email addresses
Unmanaged users have control over changing their email addresses. This means you can invite an unmanaged user at a Company A, and they could update that email address to another one without you knowing. Since the account is still the same, the user will continue having access to your site with their new email account.
This only works for non-SCIM-provisioned unmanaged users. When SCIM-provisioned accounts that are unmanaged update their emails, they will be removed from groups provisioned by SCIM. If SCIM groups grant product access, they will lose access.
Here are some example scenarios:
Non-SCIM-provisioned: I invite contractor Bill from Bankly bank to my instance by sending an invite to
bill@bankly.com. Bankly has not verified its domain with Atlassian, so Bankly accounts are considered unmanaged. Bill validates the invite in his email and accesses the client’s site. Bill goes to https://id.atlassian.com/manage-profile/email and updates his email to bill@gmail.com. Bill logs into gmail and validates this email change. The account bill@gmail.com has access to your organization’s site still, but as an org admin, you don’t know who bill@gmail.com is.SCIM-provisioned: Bill from Bankly bank exists in my identity provider. My organization does not manage and did not verify the
bankly.com domain in Atlassian. From my IDP, I add bill@bankly.com to the group Jira-users which gives him access to my Jira site. Bill goes to https://id.atlassian.com/manage-profile/email and updates his email to bill@gmail.com. Bill logs into gmail and validates this email change. The SCIM-provisioned groups associated with bill@bankly.com are not associated with the new bill@gmail.com account. bill@gmail.com does not have access to my organization’s Jira.Option 3: Invite a managed account outside your domain
When you invite users from your non-verified domains, they can be managed or unmanaged users. As an org admin, you do not have the ability to identify which accounts are which. You will need to reach out to the Atlassian administrators at the external company to understand their status and validate their security controls.
We have delivered a feature that enables an org admin to configure to require 2FA for external users.
Option 4: Invite guest (Confluence only)
External collaboration is a Confluence feature that lets your team collaborate with people that are external in some way, such as clients or contractors. It’s a secure way to open your Confluence instance to anyone you need to work with. And the way you do this is you invite them as guests.
Guests have limited access to your instance. Unlike regular users who have a broad level of access by default, guests only have access to the spaces to which they have been specifically assigned access.
Guests also have limited access to user information for your regular internal users.
Comparison table
The below table assumes the account is for an external user/contractor.
Atlassian Server account Server comparison | Option 1: Atlassian Cloud managed account RECOMMENDED | Option 2: Atlassian Cloud unmanaged account | Option 3: Atlassian Cloud externally managed account | |
|---|---|---|---|---|
User onboarding | ||||
Mailbox required | ||||
Can update your own email address | ||||
Password control | ||||
2FA requirement | ||||
Can receive notifications via email (if mailbox created) | ||||
Account can be lifecycled with IDP | ||||
Can be SCIM-provisioned (if user’s email exists in IDP) | ||||
Can use local groups to manage access | ||||
Can use SCIM-synced groups to manage access | ||||
Counts towards your Atlassian Access subscription | ||||
Counts towards your product access subscription |
FAQs
Was this content helpful?
Connect, share, or get additional help
Atlassian Community