Improved cloud security
Today we deployed a significant update to how Jira user permissions are used by Behave Pro Cloud. This change will require the Jira administrator to grant a new permission to Behave Pro Cloud and we thought you might want to know why.
How Jira cloud add-on's permissions were managed
Typically add-ons have their own "service user" account within Jira. Any interactions the add-ons makes with Jira (reading issues, writing to issues, reading projects etc....) will be done using this add-on's user account permissions. At face value this looks a simple method for controlling add-on access, but Jira's permission systems can be complex to allow some users access to some Issues and not access to other e.g. clients can not view each others Issues
Consider this example; User A has access to Issue-1 but the Behave Pro "service user" does not have access to Issue-1. When User A tries to use Behave Pro on Issue-1 they receive a permissions error and the operation fails. The Jira admin gives the Behave Pro "service user" permission to access Issue-1 and User A can now happily use Behave Pro with Issue-1. Now there could be another user, User B, who doesn't have permission to access Issue-1. Now that the Behave Pro "service user" has been granted access to Issue-1, User B can use Behave Pro to access Issue-1 circumventing their own limited access permissions. The individual users permissions are never taken into account by cloud add-ons (This applies to all cloud add-ons), and could be used as a way of circumventing security permissions.
Introducing the ACT_AS_USER permission
ACT_AS_USER is a new cloud add-on permission Atlassian introduced in October 2016, and we've implemented to improve the security posture of Behave Pro.
The ACT_AS_USER permissions allow's an add-on to access Jira as a specified user and using that user's particular permissions. This means Behave Pro with the ACT_AS_USER permission can act as User A when accessing Issue-1 and Behave Pro will have access to Issue-1 based on User A's permissions. Now if User B uses Behave Pro to access Issue-1, Behave Pro will act as User B and it will be denied access because User B doesn't have permission to access Issue-1.
With Great Power Comes Great Responsibility
As a cloud vendor we have always been committed to good security. For example, we are still the only BDD tool vendor within the Atlassian Marketplace to have passed Atlassian's cloud security program
We will only ever use this new ACT_AS_USER permission on user initiated requests so we only give users access to information that they been granted by the administrator. We will not use this capability in non-user initiated requests or "act as" a user that hasn't made the request to Behave Pro.
Security can be a little complicated, so just contact the support team if you have any questions
You may also like…