A dedicated product access role for internal customers in Jira Service Management

[Justin Huang]

Hi @Kamen 

> First, invite a customer as an internal account and then add the internal account to an organization - sounds like double work.

there is a team that working on this, you can find more details from this ticket 

> Shouldn't these "portal-only" and "internal" accounts be merged into a single management entity

there are different use cases to use one or the other account for "customer" here is a post talk about that

[Kamen]

Thanks Justin,

In that case, is there a best practice for the other way around - migrating internal customer accounts to portal-only accounts?

If this would be possible, then the second article you shared will be certainly helpful. 

[Justin Huang]

Hi @Kamen 

we don't have a way to migrating internal customer to portal-only customer

You can remove the internal customer from your userbase, then add them back as portal-only customer.

but by doing this, they will lost access to their pervious requests/tickets.

They will also no longer able to access other products on your site, like Jira Software, Confluence etc.

[James Gray]

This rolled out to my site today and fixed such a large issue. Great job!

[Robert]

Hi

The change has been rolled out to our site today. And it caused an issue, as looks like the segregation of users can not be configured (or I missed something?).

So now every Jira user automatically received permission to ALL JSM projects, thanks to the new role. I tested, and yes, if I add this role to a user, it grants access to every project. Now, internal users see all external customer facing projects and portals, and can open issues too. I hope this can configure somewhere, othervise it is a huge security concern, and has big data protection issues!

At the end, we should keep the old way to be able to limit users to see only a project where they should see things.

[Dave]

@Robert 

I hope not.

I have access to two User Profiles one is Admin the other my own day to day use. I have limited users over all just 10.

My own user profile has access to a lot of projects, one that I know I don't have access to allows me to see some of the admin features , but it would not let me see the tickets nor will it allow me to create any tickets. and see information in the frames.

Some of the messages I'm getting.

Oops, something went wrong!
You must have the browse project permission to view this project

You cannot create issues in this project.

This project isn't available
It may have been deleted or your permissions may have changed

I just got a work colleague  across the country to try and access a link to a project, they don't have access to and they confirmed they don't have access, as expected.



I hope this helps

Kind Regards 

[Fabian Dengel]

I have now searched through the admin / user management pages of a site that received this update and I cannot seem to find a dedicated setting for granting this Customer role? 

It seems the naming is redundant with the existing "Customer access" and (at least for me) currently a bit confusing. Is this new feature covered via the Product Access -> Customer Access tab?

Thanks in advance for clarifying!

[Deanna Cochener]

If we are using the API to add portal-only accounts, the current endpoint is to post to /customers. This seems a bit confusing with the new naming scheme. Is this still the appropriate way to automate adding external accounts?

[Justin Huang]

Hey @Robert 

"So now every Jira user automatically received permission to ALL JSM projects, thanks to the new role."

The behaviour exists before the change.

Before the change, Jira user received the permission implicitly and admin cannot remove the permission. 

With the change, Jira user received the permission explicitly(via this new role) and admin can now remove the permission by remove the role from them.

"Now, internal users see all external customer facing projects and portals, and can open issues too."

Note this role gives Jira user permission to all OPEN JSM projects as customers. If you want to limit a project's customer access, you can change it in the project's setting -> here is a link to explain more https://support.atlassian.com/jira-service-management-cloud/docs/change-project-customer-permissions/

[Andrei Bacanu]

How can I disable this? 

[Ash Young]

Hi @Andrei Bacanu

Currently there is no way to disable the transition to the new "Customer" role in JSM.

I'm interested in understanding why you're looking to disable this new role?

Thanks,

Ash

[Christian Schneider]

Please add a section to your text describing, how this will affect Atlassian Access and the sync of users from AzureAD. I need to have all AzureAD-users, which are synced via Atlassian Access to be in the new role of "customers".

Thanks.

[Nena Kruljac]

We also need all AzureAD-users, in the new role of "customers", as Chris Schneider wrote.

Old ones are automatically in the "customers" role.

[Andrei Bacanu]

@Ash Young 1. we already had Customer access configured and 2. this might have broken the url for people to get JSM product access as Agents JST-900369

[Chris Tolley]

Hi,

Don't have the time to read all the existing comments so maybe this has been covered but is causing us issues.

Since this new group was added, new Atlassian users on our site are now blocked from accessing our Help Centre. Previously, as long as they came from a valid domain (we use allowed domains for our Help Centre) they could access.

Now, they also need to be part of this group as a requirement and are blocked from accessing our *single* Help Centre. 

Are we missing something here? Is there some extra setting we need to tick now? The communications above clearly said there's nothing more for us to do and access won't be affected, so this is simply not true for us.

Please help!

[Mullin, Joe]

We have the same issue as @Chris Tolley - this change broke our new user onboarding - now our users aren't automatically made customers, so they don't show up in User-Picker lists and don't have access to the Help Center Portal, which is a big setback for getting their access requests set up, equipment provisioned, etc.  We provision accounts via Okta automatically.  Now with this zero-day warning about the change, we're searching how to fix this.  How do we make new users of a domain have the Customer role enabled automatically?

[Bharath Kumar Kappala]

Hi @Ash Young

We have a unique situation with the same topic which you discussed above and we are migrating from DC to Cloud this month. We have enterprise subscription for cloud. Could we have a meeting setup with you to discuss about this scenario and possibly find a solution for our problem. Its really hard for me describe the issue that we have here. If you are available for a meeting we can schedule one a discuss further, or please let us know how we can get in touch with a Atlassian Product Manager who works on JSM.

Thanks

Bharath

[Ash Young]

Hi Chris Schneider

You're able to use "Approved domains" to provision the "Customer" role to users you sync from your Azure AD.

You can find more details about how to use "Approved domains" here

[Ash Young]

Hi @Chris Tolley 

Can i confirm you're using "Approved domains" to provision uses with the "Customer" role?

You can find details about "Approved domains" here

[Ash Young]

Hi @Bharath Kumar Kappala

Could you send me an email at: ayoung3 (at) atlassian.com

Lets set up a time to speak.

[Ash Young]

Hi @Mullin, Joe 

I'd point you towards the "Approved domains" feature and check you've configured that users from your domain are provisioned the "Customer" role when accessing JSM.

You can find more information here

[Justin Huang]

@Mullin, Joe 

> provision accounts via Okta automatically

If you're using Okta and SCIM to provision new employees, you can also assign the `Customer` role to that synced group. 

[Justin Huang]

@Chris Schneider  @Nena Kruljac 

If you're using Atlassian Access and SCIM a group, you can assign the `Customer` role to that synced group. 

[Chris Tolley]

Hi @Justin Huang by approved domains I meant this process which I suppose is called restricted domains.

The approved domains process you linked here is not used by us, because we have a specific process in place where users should not be able to freely sign up to our site. We need users instead to raise a ticket via JSM for full licensed access to our site, rather than just being able to join via allowed domains.

Are you saying that allowed domains is the right approach here for this new Customer role? Following this logic, do we need the list of allowed domains to match our restricted domains via my link atop this comment? Doesn't this just mean we're having to put the same domains in two places, when we already have approved domains via "restricted domains"?

EDIT/UPDATE: Today we've tried granting the Customer role through allowed domains to "any domain" and this allowed anyone (tested with a personal email account) to access our portal. So that seems to overrule any restricted domains set in JSM portal settings. So the only way I logically see this working is if we list all approved domains (we have over 40) in the approved domains section to copy the domains listed in restricted domains. Doesn't make much sense to me!

[Antoine _Klee Group_]

Is there a way to give new site users an access to this role directly? Other than an API call to the group/users ?

My users are created through an API.