App data access controls - new feature announced in the roadmap for Q1 2024, what will it be?

Jira Development Jira Cloud
, , , , ,
1

I’m from an Atlassian Partner I was recommended by Atlassian support to raise a topic here and discuss this issue.

Note that this subject prevents one of our largest customers from approving almost any app in the cloud. This is a real barrier to migrating our large customers to the cloud.

Our customer is concerned that apps have “permission scopes” and that they might abuse those permissions (or get compromised by an attacker that will abuse them) and will use the scope to get/update data or change Jira configuration (e.g. changing a permission scheme).

We talked with some App vendors and they told us that they ask for various permission scopes only for the installation, they don’t need it for the ongoing operation of the App.

However, even if they don’t need the declared scope, they still have it. and it can be compromised.

The need is to control dynamically the approved scopes of each app separately. Even if the app gets some initial scope during installation, the customer wants control over that, and would like to have the possibility to remove permission scope from an app after installation is completed.

For example: remove app permission scope to update Jira issues, remove app permission scope to administer Jira, etc.

That’s why we were very intrigued by the new feature announced in the roadmap recently:
App data access controls: Restrict app access to specific Atlassian instances, Confluence Spaces, or Jira Projects. (targeted for 2024 Q1).

This was an especially good announcement for us, since we noticed the following bug in the backlog: JRACLOUD-81601
We also noticed this announcement about the deprecation of the ability to control App permissions in the permission scheme using the “Atalssian-addons-project-access” role.
(see notice from 11 Aug on https://developer.atlassian.com/cloud/jira/platform/changelog/)

Initially we thought to use the “Atalssian-addons-project-access” role in the permission scheme in order to control app permissions. Per the above bug and deprecation notice, we cannot really use that approach. (and even if we do, it’s not specific for each app. It’s one role for all the apps). so the new feature planned for Q1 2024 might save us, or not…

The question for the community: what do you think should be the functionality of above new feature? Do you agree that allowing the Jira admins to change the permission scopes of each app (after installation) is a good idea that can help increase the infosec level and reduce infosec risks?

2

Welcome to the Atlassian developer community @RanLavi,

We’ve already had a couple Request for Comments (RFCs) about the topic, detailing what it means for app developers:

I am also interested to hear what the community thinks; however, the above RFCs make it pretty clear that our current thinking is much narrower than “dynamic permission scopes”; at least, with how apps understand the concepts of “permissions” and “scopes”. Specifically, what gets narrowed are which “containers” apps can access as in Jira projects or Confluence spaces. What’s proposed would not be as granular as the example you gave; an admin would not be able to revoke a specific app permission or scope (for example, the Connect READ or ADMIN scopes).

Hopefully, those links and my comments help you understand the intent better and drive more meaningful conversations about appsec with your customers.

3

Got it @ibuchanan
The RFCs you linked indeed do not satisfy the requirements of our large customers.
They want it to be more granular, e.g. many apps require write data scope, but actually don’t need to write anything (only on behalf of a user), so the customer wants to prevent specific apps from updating Jira issues, on specific projects, using their permission scope.

Also, very importantly, many apps require Jira Admin scope, but actually use it only during installation and later do not need it. The customer wants to prevent those apps to be Jira Admins.

So I understand that the new feature planned for Q1 2024 will not help us for the above needs.

What can be done to satisfy the more granular needs as written above?

4

Hi @RanLavi
I actually like your proposal. App users could be treated more like human users, and by this their access could be managed more transparently.
However there are many corner cases, e.g. when an app receives a webhook to delete or write to a specific page and this access is forbidden. Currently there seems no direct way for an app to surface this to an admin.
Looking forward to more exploration in that area!

5

@RanLavi,

We started rolling out fine-grained scopes:

You originally tagged this topic with Atlassian Connect, so this change would come with a “double cost” of first moving to Forge and hopefully adopting the newer, more fine-grained scopes as you do so. To be clear, this is granular but not dynamic.

The only discussions I’ve had about “dynamic scopes” have been about the other direction: ratcheting upwards. An app might install with the least set of scopes that it needs to run, and could incrementally ask for more scopes as it is configured or used for more things. The advantage of “ratchet up” would be the existing UI is already about adding scopes through an authorization flow. Anything that would give power to revoke scopes would require new UI. All that said, there are no plans or commitments for this. I don’t think our engineering teams don’t see the cost/benefit playing out, given that we have yet to complete granular scopes and app access narrowing. And, once we complete, we need to let those propagate into apps before we can see if they are solving the customer problems.

My intent here is just to make sure existing plans are clear. There’s plenty of room left for exploration and discussion.

6

I see @ibuchanan
Let’s focus: let’s talk about Connect apps, and about dynamic scope only for “Administer the host application”.

Do you think it is a reasonable suggestion that a customer will be allowed to dynamically remove the “Administer the host application” scope of an app after it was installed successfully?

This is the top need of our customer. The app requests Jira admin scope, does its thing in the installation, and then doesn’t need this scope anymore (we checked with the vendor). But the scope remains as granted. This is a HUGE security concern.
The customer is concerned that the vendor infrastructure will be compromised by an attacker, who will use this permission scope to do nasty things in Jira (E.g.: create a new webhook that sends every new issue to an external server).

This is the top risk that causes our large customer (several instances, more than 25K users) to think twice before moving to the cloud.
If Atlassian wants large customers to move to the cloud, then this risk must be mitigated.

What can be done to mitigate this?