ACT_AS_USER is a new add-on permission Atlassian introduced in October 2016, and we've implemented to improve the security posture of Behave Pro.

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.

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 this new permission comes a great responsibility, and we will only ever use this user "act as" feature on user initiated requests so we only give users access to information that they are allowed to. We do not use this capability in non-user initiated requests or "act as" a user that hasn't made the initial request.

Did this answer your question?