nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to manage Customers in combination Atlassian Access

Stéphane Veraart

We are working on JSM Cloud Premium and we're planning on using Atlassian Access. I am running into some challenges getting clear exactly how this will work.

Atlassian mentions portal-only customers do not need a paid account, yet on the page for the pricing and licensing documentation it is referred to as in that the customers need an Atlassian account. Our (internal) end-user customers don't have an Atlassian account. So this will not work.

Alternatively there is the option of non-paying user policy within Atlassian Access using Azure AD still. This removes the SSO and MFA options, but it isn't clear if these users will authenticate against Azure AD (same user name/password) or not?

Importing users or any other synchronous/asynchronous option doesn't seem to work either because the Atlassian API for (SCIM) user provisioning has been deprecated since 2019.

Does anyone have any experience or recommendations when dealing with Azure AD portal-only customers?

Screenshot 2022-01-31 at 13.43.33.png

Accepted answers

All comments

Angélica Luz

Hello @Stéphane Veraart,

Thank you for reaching out to the Atlassian Community!

When it comes to customer accounts, they can have or not have an Atlassian account and they are not counted towards the licenses.

It’s only necessary to pay for users that are added to the default access group that gives access to the products.

Screen Shot 2022-02-01 at 16.57.43.png

For example, if there is an internal user and they are not part of any default group (it can be for Service Management, Software, Confluence), you won’t have to pay for their licenses because they don’t have access to the product.

This type of internal user is also considered a customer because if they don’t have access to any product, they will be redirected to the customer portal when they log in.

Summarizing:

People added to the Customers’ page directly in a Service project are considered Customers.

People invited as internal users (from User management), but that are not part of any default access group and only have “Has access on site” are also a customer.

On the screenshot below is an example of an internal user being a customer. Note that, none of the products are enabled for them, only the “Has access on site”.

Screen Shot 2022-02-01 at 16.37.23.png

Now, regarding Atlassian access, SSO, and the Customer portal.

The customer portal, currently, doesn't work with SSO. Customer accounts are stored locally and it's not possible to sync their accounts with an identity provider.

SSO only works for Atlassian accounts, so in case you need customers to log in using SSO and enforce security policies, they must have an Atlassian account (internal user without application access as I explained above) and use the same URL as internal users to login (xxxxxxx.atlassian.net instead of xxxxxxx.atlassian.net/servicedesk/customer/portals).

SSO integration with JIRA Service Desk

If you have any other questions regarding this matter, please let us know.

Kind regards,
Angélica

Stéphane Veraart

Hi Angelica,

Thanks for your reply. I understand the principles, I think.

JSM is planning to be used as an internal support management tool - in line with the Enterprise Service Management (ESM) strategy of Atlassian for JSM - for the IT, Finance and Operations teams.

The client uses Azure AD with user IDs, passwords and a password policy containing 1600 users of which 50-100 will be JSM agents.

However, how does a company or IT team manage the below in practice?

The customer portal, currently, doesn't work with SSO. Customer accounts are stored locally and it's not possible to sync their accounts with an identity provider.

Not having SSO by itself is acceptable, yet managing 1500 Customer accounts locally in the application is a bit of a stretch in terms of manageability and also not compliant with password and other security policies.

How would you suggest managing Customers users in this context?

With regards to the linked article:

Problem Definition

Currently it is not possible to integrate sso with JIRA Service Desk, it would be better if can provide this functionality so that customer does not need to sign in to the customer service portal in order to raise a request.

Workaround

If the customer (portal-only user) has an email address verified with Atlassian Access, site-admin can migrate the account to Atlassian account so that the customer can login with SSO.
Once migrated, ensure that the site access is enabled and ensure that there is no application access. This will ensure that there are no license consumed and have the users treated as a customer.

I think I understand this workaround, however I still have a few questions:

- How can the users be migrated?

- Will these users count as paid users for Access or not?

Sorry for all the questions but I am just try to make this work for our client.

Angélica Luz

Hi @Stéphane Veraart,

The customers' accounts are local, so when you verify a domain and claim the accounts, internal licensed users and users with an Atlassian account will be managed under the Organization where you claimed the domain.

Customers, even being from the same domain, if they don’t have an Atlassian account, will be managed on a separate menu directly on User management and it’s not possible to apply security policies for them as well.

Include password policy configuration for portal only customers.

How can the users be migrated?

Customer accounts can be migrated on Cog icon > User management > Jira Service Management.

Screen Shot 2022-02-02 at 16.55.25.png

Before migrating their accounts, I would suggest disabling the product access, so once they are migrated, they won’t be added to any default group. This setting won’t affect any existing user, it will just prevent the migrated customers to be automatically added to the groups.

Screen Shot 2022-02-02 at 16.57.31.png

Will these users count as paid users for Access or not?

No, internal accounts that are not part of any default group (with product access) won’t be billed.

Using my screenshot above as an example, the group that gives agent permission to users is jira-servicedesk-users. So, if 3 users are added to the default group jira-servicedesk-users and 200 other users that are not part of any default group, it will be necessary to pay just for 3 users.

We found a documentation that better explains how Atlassian access is billed:

Manage your bill for Atlassian Access

Will I pay for my Jira Service Management users?

Portal only customers will not be counted towards your Atlassian Access bill. If your portal only customers have an Atlassian account, any Atlassian Access features will be enabled for their account, however they'll not be a billable user for Atlassian Access unless they also have product access to another Atlassian Access supported product. Only Jira Service Management agents will be counted towards your Atlassian Access bill.

Stéphane Veraart

Hi Angelica,

Thanks for the information and insights into how things work. I am still struggling with the idea of having users local. We are dealing with a conglomerate of companies that may or may not have the same domain or other domains. Also we have different locations all around the world.

There will be only 1 team (2-3 people) managing all the customer users from around the world. They have Azure AD as a central place to manage all these users and accounts now, so having to manage them in another application would become a bit cumbersome for them.

Questions like resetting passwords, accounts being locked out and/or other account related questions would come to this team instead of the IT team managing the rest of the accounts in Azure AD

When migrating the users, I think the above mentioned challenges apply as well. I also am curious of how the passwords will be migrated, if they are even?

Are there any other options of managing customer accounts not being in the internal directory?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management