Limiting access to Atlassian Connect add-on views based on user's groups

Atlassian Developer Tools
1

Hi!
I am working on an Atlassian Connect add-on that should have restricted access for some of its views based on the groups of the user. The access control should mean both having the restricted items hidden in the UI and not being able to make direct calls to the backend API. The add-on is for JIRA but I think this question is not specific to JIRA.

As far as I understand, the only way (without deprecated remote conditions) to have conditions for not showing the views based on groups would be to use ‘addon_property_contains_any_user_group’ condition and then add a property stored in the hosted data storage for setting which groups are allowed to access the views.

I have two questions:

  1. Is this approach secure enough for using it as the access control to the backend?

Ideally I would want to trust in my backend code that anyone coming to the view link with a valid JWT also meets the security condition on belonging to the required group. But if “a malicious authenticated user” can change the add-on properties, does that mean that I would also need to store the group permissions in my own backend and double check in the backend using the REST API that the user really belongs to the required group? I would still need to also use the add-on property for controlling the visibility of the UI elements, so then the check would need to be done with twice.

In the REST API doc it says that only the add-on user can set the properties, which as far as I understand is only used when doing the request from the back-end through the REST API (and not when using AP.request() which would use the user in browser)? But what does it mean then that “a malicious authenticated user” can change them too?

  1. What would be a recommended way of setting default values to the add-on properties?

In my current use case it would actually be enough to set the required groups statically in the atlassian-connect.json. In any case I would want to set default values to the add-on properties.

Is there a way to specify default values for the hosted data storage properties in eg. atlassian-connect.json? If not what would be a good way of doing this? I am currently doing this by REST API in the ‘add-on enabled’ lifecycle hook, does that sound reasonable?

Thanks!

2

It’s sad that no one has answered this question. I’m also asking myself the same question. A typical user who authenticates to the add-on server by viewing a view which he has access to has now been granted access to all the add-on server APIs. For sure the admin views will be blocked by JIRA but not the server API. A secure application needs both: limiting access to the views and server APIs. A very simply way would have been to provide permissions via the JWT claim context. For sure, one can query the JIRA permission API but that makes for another round trip to the JIRA server.

What did you manage to do?

3

My approach is to assume that conditions in the add-on’s descriptor can be subverted. A user may manage to twiddle the properties in order to reveal a link or a panel or something, but they can never see data that they shouldn’t, and they can never manipulate data that they shouldn’t. In my experience, that means writing code behind the add-on’s REST API to validate the user’s permissions; and yes, it often means another call to the JIRA server.

I would not store permission-related information in hosted data storage. It would be better to store those data in a protected database on your add-on’s server.

4

Thanks @david.pinn! It would be so simple to have the user’s permission along with the user’s key in the JWT. I think I will write a request for it.

5

What was your final solution?