Resources + Q&A from "What's new in Atlassian Access" webinar

Hi Community!

Thank you to all those who joined our What’s new in Atlassian Access webinar last week! We received so many great questions about existing functionality and newly released features of Access. I’ll cover the questions asked during the webinar and share some relevant resources on what was covered.

The questions below are categorized by these topics:

  • Authentication policies / Authentication settings / SAML SSO
  • Automatic product discovery / Shadow IT
  • External users / External accounts
  • Access and Jira, Confluence, JSM, Trello, Bitbucket, etc.
  • User management / User provisioning / SCIM
  • Domains / Sub-domains
  • Other (incl. API, BYOK, CASB, auditing)
  • Migrations / Cloud migrations
  • Billing / Pricing

If you missed the webinar, the recording is available on-demand for you to watch at your own pace.

Thanks!


Top Atlassian Access resources to bookmark

Resources to dive into new features covered in the webinar


Authentication policies / Authentication settings / SAML SSO

  1. Can you assign authentication policies based on user groups from identity provider? No, groups cannot be used to assign users to authentication policies. But, we will be looking to improve how to improve the efficiency of assigning users to authentication policies. We are tracking the interest in this feature through ACCESS-1041.
  2. How do I know if my identity provider is supported? AD FS, Azure AD, Auth0, Google, Idaptive, Okta, OneLogin, and Ping are supported identity providers. If you have an identity provider that is not listed, it can still be connected with Atlassian Access since we follow the standard SAML protocol for SSO. See our documentation for more information.
  3. Can we try out Access to play around with authentication policies and security features? Yes, of course! You can try Atlassian Access free for 30 days. It is critical to verify your organization’s domain to fully take advantage of all the Access features available, including authentication policies. Here is our documentation on steps to set it up.
  4. Are one time password (OTP) sent to users who authenticate via Access? Access allows you to enforce two-step verification on your managed accounts. The users of your managed accounts can install a login verification app (such as Google AuthenticatorAuthy, or Duo) on their phone or choose to get the 6-digit code via text (OTP). If your users choose to go with OTP, then they will be required to enter the OTP when they authenticate into their Atlassian Accounts.
  5. Is it possible for Atlassian Access to enforce SSO / verify managed users against an identity provider, but not necessarily provision them with access to any products? The use case is an internal user who only needs anonymous / read-only access to a public space without consuming a paid license for that Confluence site. Yes, SAML SSO can be configured independently of SCIM user provisioning. They work great together, but are also independent features. Keep in mind that provisioning the user will not make them a paid license as long as they aren’t also using an Atlassian cloud product. So, if that user in your example has no product access and is only viewing a public Confluence page, provisioning them won’t consume a paid seat.
  6. How is this going to help if the org admin enforces SSO and their users are not aware of it? If you are enabling SSO on your users, we currently notify users of the change. We also strongly recommend you handle internal change management and messaging before enacting security policy changes.

  7. What happens when a user is added to multiple policies? A user can only be in one authentication policy at a time. See our documentation for more information.
  8. Can we set password strength as strong or weak by default? Default password strength is set to weak. However, with SAML SSO enabled, the Atlassian password policy no longer applies.
  9. If I need to move a user from one policy to another, it's currently difficult to find the user when you have thousands of users. Is there a way to quickly search for the user and move them to a different policy? You only need to add the user to the new authentication policy and they will automatically be removed from the old one. You can search by name or bulk-add users to a new policy by uploading a CSV file with email addresses.
  10. How can Atlassian Access provide migration paths from G Suite to Office 365 for SAML SSO? You can configure SAML SSO with O365 from scratch and users will be redirected to Azure AD instead of Google. A subscription to Atlassian Access is required to use SAML SSO.
  11. Can you align authentication policies to certain permission scripts / project spaces within Jira or Confluence or do they control global access per application? Authentication policies are global in the sense that they exist only at the organization level. There is currently no functionality to automatically align them with Jira projects or Confluence spaces.
  12. When I add users to the authentication policy to exclude security features, I notice that 2FA is not automatically disabled for those users and sometimes it is. I would prefer 2FA to be automatically disabled when the user has been added to my "Exclude" policy. How can I do this? 2FA is not automatically disabled by the authentication policy. The authentication policy only dictates if 2FA is mandatory/enforced or not. The user can choose to set 2FA on their own, even if it's not mandatory.
  13. Is it possible to add users to an authentication policy based on a regex automatically instead of a default policy? Unfortunately, not at this time. The only way to add users to policies are: (1) manually, by typing their name or (2) in bulk by uploading a CSV file with their email addresses.
  14. Will it ever be possible to enforce users to authenticate through our identity provider regardless of domain? No, you will not be able to control the authentication method of accounts you don’t manage. But, our team is working on security controls for external users. It is listed on our public cloud roadmap and you can follow this ticket to track its progress.

Automatic product discovery / Shadow IT

  1. Can org admins be automatically added as org admins to any product sites created? All the sites our users created were not approved and by accident. Some of them had left the company. It would be nice to immediately have access to the other sites so we can manage them without needing to reach out to someone. If a domain is claimed, products accessed by users on that domain will be included in your organization. Org admins automatically become product admins of all products contained within an organization. If you discover new product instances your users have created and want to manage them, claiming domains and adding them to your org will give you all admin permissions.

  2. How do I remove shadow products for users who are no longer with the company and have deactivated accounts? If there is still an org admin for the shadow IT product instances, you can contact them through the Discovered Products interface and they can cancel the site’s subscription. If there are no remaining org admins for these product instances, you can contact Atlassian support or reactivate the removed user’s email account, log in as the user, and remove the shadow product instance(s) using their account.

  3. What instructions do I give users to remove products they accidentally created? Is there a step-by-step guide? You can remove products that were accidentally created when you are made a site admin (or org admin) of the product, which the current org admin(s) of the product would be able to do. Once you have a site or org admin role, you can cancel the site's subscription.

  4. Can you prevent managed users from setting up separate instances of products? Can this be done with group permissions? Today, the feature does not yet prevent managed users from setting up their own product instances separately. Group permissions will apply to current product instances for the Atlassian org where the product instances reside, but do not apply to other orgs' product instances (in the case of these user-created products). Prevention and proactive control is an area on our roadmap.

  5. Can you add warnings to admins when a product is not managed and they are adding users with our domain address to indicate that user is subject to domain owner policies for Access? Also, when an org admin is from a domain that is owned, can you provide a message and approval from the domain owner? Yes, we are exploring how to surface this.

External users / External accounts

  1. Is it possible to automatically de-provision external accounts? e.g., deactivate entirely or toggle “site-access” off entirely for our sites? Accounts can only be deactivated by orgs that manage the account. When you deactivate or delete an external account that is synced to Atlassian through your identity provider, the accounts will be removed from the IdP groups and hence will lose product access granted through this method. These accounts will retain “site access”. “Site access” can only be removed on a per user basis from the site’s user management -> users -> <user detail’s page>.

  2. Do external users provisioned in Access take up an Access license? No. Only managed accounts count towards Access bill.

  3. When will the external user security controls be released? Our team is working on it! It is listed on our public cloud roadmap and you can follow this ticket to track its progress.

  4. Can external users automatically be deactivated or access removed if they didn’t log in for a specific time? Not automatically, but you can export a CSV of all your users and see their last login time then decide to deactivate or remove them.

  5. When managing external users, can you manage external customers to a JSM portal? Yes, you can provision external users for the purpose of giving them access to a JSM portal. For example, you could provision users from an IdP into Atlassian Cloud and configure your JSM portal to be accessible to anyone in your org.

  6. What if external users are already signed up for SSO with their company? How can we provision them through SCIM? If you have configured SCIM in your organization and your synced groups contain external users, we will sync these external user group memberships to Atlassian and these users will inherit the product access from these groups. This does not interact with SSO setting for the user accounts. These users will still login to the Atlassian accounts through their company’s SSO before accessing products in your organization.

  7. I want to set a different policy for external user that is more strict than internal users. If I set a user group as “External” and assign all external users to that group, will the policy for that user group only? Authentication policies only apply to managed accounts. External accounts cannot be added to authentication policies. Our team is working on security controls for external users. It is listed on our public cloud roadmap and you can follow this ticket to track its progress.

  8. I am an Atlassian partner and have my own account that I use with all of our cloud clients. Should I recommend they set up a new policy for external users like me? Authentication policies only apply to managed accounts. External accounts cannot be added to authentication policies. Our team is working on security controls for external users. It is listed on our public cloud roadmap and you can follow this ticket to track its progress.

  9. For automatic de-provisioning for external accounts, can we disable site access in addition to product access? It seems like they are able to access things like service desks set to “anybody with an account.” If you are syncing those users from an external identity provider and have deactivated or deleted the user in that identity provider, the user will be deactivated in Atlassian Access. If the user is deactivated, they should no longer be able to log in to their account, including access to the support desk. If you remove product access from a user without deactivating their account, then yes, they can continue to access a service desk.

  10. Can we clone/mirror access of external user to a new account (both external user)? You can do this by adding the new accounts to all the groups the old account.

  11. Can I enforce MFA for users managed by other domains? There is currently no capability in Access to enforce authentication policies on users outside of your organization or on domains managed by other organizations. However, this is a feature that we are exploring - no promises on timing, but we know it’s something people need. Feel free to add feedback on this in jira.atlassian.com.

Access and Jira, Confluence, JSM, Trello, Bitbucket, etc.

  1. If using just Jira Cloud Premium and Confluence, what benefit is there using Atlassian Access? Cloud Premium plans pair really well with Atlassian Access! If you’re currently on or considering a Cloud Premium plan, it’s likely your organization is growing and you will need to find ways to scale and secure your company data. With Atlassian Access, you add an enhanced security layer by connecting an identity provider to enforce SAML single sign-on on your managed users. You can also leverage that identity provider to provision users through SCIM to help you scale user lifecycle management.

  2. Can the security MFA be applied to service desk customers when logging in? MFA can only be enforced on your managed accounts. If your service desk’s customers are not your organization’s managed accounts, you cannot enforce MFA for them.

  3. Does Access work with Trello? Yes! After claiming a domain, org admins can see a list of managed accounts and which ones have Trello product access. With an Atlassian Access subscription (assuming users are not put into a non-billable policy), you can enforce authentication policies on all managed users, including those with Trello access.

  4. A lot of people have Trello accounts, whether they need it or not. How can an organization manage user count? We do not want to necessarily pay for those users who are only using Trello. This is an area that we are actively working on. If you would like to be a design partner and tell us more about your use case and how you are looking to control Trello user count and their workspaces, follow this ticket. For the time being, you can move Trello-only users into a non-billable Access policy, which would also remove them from policy enforcement with Access.

  5. What is in the works when it comes to administering Trello under Atlassian admin? We are actively investigating Trello administration within admin.atlassian.com so that there is no need to deactivate the user’s Atlassian account in order to manage Trello product access. Follow this ticket if you’d like to track progress on this work. We are actively looking for admins to be our design partners on Trello administration!

  6. Does Atlassian Access support Bitbucket cloud? Can I manage Bitbucket users with Access? Yes! You can see the which specific features of Atlassian Access are available for Bitbucket users on this page.
  7. When can we provision users on Bitbucket? Any plan to centralize user management for Bitbucket users and groups? Unfortunately, no timeline on this yet. We are investigating scope and are working on Trello ahead of Bitbucket at this time. We will be sure to communicate an update. Note that de-provisioning will work because when an account is deactivated in the identity provider, their global Atlassian account will also be deactivated and the user will lose access to all cloud products at once.

  8. Is Atlassian Access support for Jira Align in the works? If this is something you want for your organization, vote for it in this ticket and follow for progress.

User management / User provisioning / SCIM

  1. Does it make sense to use Atlassian Access if users and groups are provisioned and managed by my identity provider? Definitely! Atlassian Access enables you to connect your identity provider to Atlassian cloud products, such as Jira, Confluence, etc., so you can automate user provisioning and de-provisioning, enforce users to log in with SAML SSO, etc.

  2. Talk more about how Atlassian Access auto de-provisions users. When you connect your identity provider to cloud products with Atlassian Access, you can automate user lifecycle management by leveraging the SCIM protocol. When a user joins, leaves, or moves between teams on the identity provider, it is automatically synced with their Atlassian cloud product permissions. You can learn more here.

  3. With Atlassian Access, is it possible to synchronize groups from Azure to Jira cloud and keep the users belonging to these groups constantly synchronized? Yes, with Atlassian Access, setting up user provisioning via SCIM will provision group and users from Azure AD into any Jira instances contained within your organization. As long as you don’t disable your SCIM integration, users and groups will be kept synchronized with your identity provider. See our documentation for more information

  4. I’d like to bring in additional Active Directory attributes, such as phone number, office location, manager, etc. Is this on the roadmap? This feature is currently not on our roadmap. At the moment, you can provision the following fields: display name, email address, organization, job title, time zone, department, and preferred language.

  5. The directory available to admins to manage users has very limited features. Are there plans to have activity timestamps visible and sortable? It would also be helpful to be able to bulk deactivate (especially in the case with old Trello free accounts). The managed accounts page has last active timestamps within the individual account view, but it’s not sortable at this time. Bulk deactivation is available in the UI, but for larger bulk operations and custom sorting we recommend using the admin api.

  6. Can we restrict specific products from ever being provisioned to a domain user? Currently, there is no way to prevent all product instances of a certain type from being created by or joined by a managed user in a domain, since products set up by a user would belong in a separate logical Atlassian organization from a centrally managed IT organization. However, improved controls over managed users are on the roadmap. If you would like to speak to our team about your specific needs, please follow this public ticket.

  7. Can we add a specific site user under Access control? Yes, if you claim that user’s domain. If you claim a domain, you will capture all users on that domain as managed accounts. If you want to apply an Access security feature to specific users, you can add them to an individual authentication policy.

  8. I understand I can have multiple sites under a single organization on Cloud Enterprise. Is there a difference in managing users across the various sites in Atlassian Access with multiple sites? Atlassian Access is available as part of your Cloud Enterprise subscription. So there will be no difference in how you manage users between the 2 subscriptions.

Domains / Sub-domains

  1. I assume my identity provider domain is the same as my mail domain when it comes to domain verification. I use several mail domains, including sub-domains - how can this be addressed during domain verification? As an Atlassian cloud organization, you can claim multiple domains and/or sub-domains you manage. You can learn more on our Product Guide and Support Documentation.

  2. When an org admin claims a domain and user accounts are now managed by the organization, are users notified through the product starting now or do they receive an email? As of early May 2021, our team released an update that removed the email that gets sent to users. Since it is still a legal requirement for us to communicate that their account is now managed by their organization, we now show this message inside the product within their profile settings instead of an email.

  3. I do not want to manage all users at the same time. How can I verify my domain without impacting all my users? Domain verification is a mandatory step of setting up Atlassian Access. With authentication policies, you can now select groups of users that you want to apply policies on and then place the rest of the users in a non-billable policy without Access functionality. However, you would still manage all the claimed users from the verified email domain.

  4. If an existing account is updated to use an email address under a managed domain, is there any way to change the account back to the original email address (a non-managed domain-based email address)? We recently changed this because of issues customers were encountering in their configurations when they switched an account’s email domain. However, we’re also getting feedback that this change is causing new problems. Please add feedback here if this is something you need.

Other (incl. API, BYOK, CASB, auditing)

  1. How do you surface user email as part of the payload from an API call? User email is included in the payload of a call to fetch organization users. See our API documentation.

  2. Could we have an API call that searches for an existing user by email address, rather than having to parse the entire directory? You can search for a user by email address in the admin.atlassian.com managed accounts list. In the API, the only way to do that is fetch all users then match against the email field.

  3. When will BYOK be supported? Our team is investigating BYOK encryption and how we bring that to life. This is listed in our public cloud roadmap for you to track progress.

  4. Is there documentation on CASB and Azure MCAS? Here is the product guide on how Atlassian Access works with CASB integrations. We currently only support McAfee MVISION Cloud. If there is a CASB partner you’re keen on leveraging for Atlassian cloud products, we highly encourage you to communicate this to your partner so we can work on it together.

  5. Are there any plans for additional user auditing and reporting features to help admins and security teams with governance and compliance? Yes, we plan on continuing to add additional audit log coverage over time. This is listed in our public cloud roadmap. In the next few quarters, expect to see additional Jira and Confluence user events focused on reading, creating, modifying, and deleting issues and pages to be added to the audit log.

Migrations / Cloud migrations

  1. What concerns are there with cloud migrations from server? We have a Migrations Center filled with resources to help address your concerns. We’ve also rounded up the top concerns from our server customers who are considering migrating here, with specific questions on Atlassian Access , user management, and how to migrate users for customers using Active Directory or an existing LDAP. If you want to familiarize yourself with the cloud migrations process, you can download our Intro to Migrations Ebook here.

  2. Talk through the use case of a divestiture, where a group of users will be migrated to a new instance and org and need to update their email address from unmanaged to managed. How would that work? As an org admin, you can update the email address of the accounts that you manage. Only the user of an unmanaged account can update the email address of that account from managed to unmanaged. You read all about updating the email address of an Atlassian Account here.

Billing / Pricing

  1. Are we billed by all synced users or only the users that have permission or are active? You are billed for all users under the claimed domain that are on a cloud subscription (e.g., Bitbucket, Trello, Jira, Confluence, etc.). You can create a non-billable policy if you want certain cohorts of users/teams to not be billed for Atlassian Access or have Access features and functionalities.
  2. Is there a suggested approach to deal with billable users who had previously registered Trello with a company email but never used the product? Yes, you can go into managed accounts to see which of your users are Trello only and have not been active in a long time and deactivate them. If you have many such users, you can automate the process by scripting against the cloud admin API and filtering for users with an old last active date, then making API calls to deactivate users in that set.

  3. If I adopt Jira Service Management as a helpdesk solution, will I need to pay for Atlassian Access for all end users to log issues if I want them to log in using their Microsoft O365 company credentials? No, Atlassian Access is only billable for helpdesk agents, not customers. If those helpdesk customers do not have access to another billable Atlassian product (Jira, Trello, Confluence, etc.), enforcing SSO for those users is free through Atlassian Access.

2 comments

G subramanyam
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 29, 2021

Hi @Sandy I'm new to Atlassian Access and your post gave me insights. Thank you for the details and links.

Like Sandy likes this
Sandy
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 29, 2021

Hi @G subramanyam glad you find it helpful! Which ones helped you the most during your setup as you learn about Access?

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events