Confluence has been updated to version 6.15.9

A proxy user is a work management system user, who will be used by Exalate to make changes, such as:

  • Creating issues.
  • Updating data.

The proxy user impersonates external instances. All changes on local issues are performed on behalf of this user. You can use an existing user account or create a new one, specifically dedicated to Exalate. 

Changes made by the proxy user will not be synchronized.

If you set the administrator as a proxy user and create issues with the help of the 'create on behalf of ' Service Desk functionality, issues will not be synchronized.

The proxy user configuration is different for each work management system. 

In this article

Azure DevOps

By default, the Exalate proxy user is the Project administrator and a member of the Project Collection Administrator group.

To integrate Exalate with Azure DevOps instance you need a Proxy User.

The proxy user is the Azure DevOps user account that fetches information from the Azure DevOps instance and updates work items with incoming changes. 

Access to Azure DevOps

Exalate needs to authenticate to the Azure DevOps instance. You can provide such access using the Personal Access Token(PAT).

Use the PAT to access the Exalate admin console. Check how to generate the PAT(Personal Access Token) in your Azure DevOps instance.

Proxy User Permissions

This user must have the following permissions:

  • be a Project Administrator and a member of the Project Collection Administrator group on the Organization level

    You can add the project administrator to the Project Collection Administrator in your Azure DevOps under Organization Settings → Permissions → Project Collection Administrators.


  • Personal Access Token with authorization to Read, Write, and Manage work items.

GitHub

By default, Exalate for GitHub proxy user is the repository admin or the organization owner, who is installing Exalate.

Access to GitHub

Use a personal access token to log in to Exalate for GitHub. The token needs to have access to private repositories with the repo scope.

Read how to generate a personal access token in GitHub: How to generate an access token.


Proxy user permissions in GitHub

The proxy user has the same permissions as an admin or an organization owner in GitHub.

HP ALM/QC

You can set up the proxy user when configuring Exalate for HP ALM/QC, or in the General Settings.

Access to Exalate app for HP ALM/QC

Log in to the Exalate app admin console with the credentials of the HP ALM/QC admin user. This can be a user you set up during the first configuration of the Exalate app for HP ALM/QC.

Proxy user permissions in HP ALM/QC

For more information about user permissions in HP ALM/QC check HP ALM/QC documentation.

Jira Cloud

The app user for Jira Cloud is created automatically. This user cannot be modified. The app user is a proxy user for Exalate.

At the moment, there is a security vulnerability in Exalate, that lets you access private project data with the Connect operation. We recommend making sure, that the proxy user has access only to private projects.

For more info, check Security Vulnerability — You can access restricted project data with the Connect operation.

The username is Exalate and the email address is com.exalate.jiranode@connect.atlassian.com

The proxy user on Jira Cloud is a member of the following user-groups: 

  • atlassian-addons
  • atlassian-addons-admin
  • jira-core-users
  • jira-servicedesk-users
  • jira-software-users 

Proxy user permissions in Jira Cloud

Jira Cloud grants correct permissions to addons through the atlassian-addons-project-access role. It is done after installing or updating an addon. Jira Cloud also checks the permissions of existing add-ons across all JIRA and JIRA Service Desk projects and grants them the correct permissions.

If you want to ensure that the add-on has no access to the project—remove the group from the corresponding permission in the permission scheme.


For more details, check Atlassian documentation.


Jira on-premise

By default, the proxy user is the user who installs Exalate.

To change the proxy user in the Navigate to General Settings → Proxy User in the Exalate admin menu to set the proxy user.

At the moment, there is a security vulnerability in Exalate, that lets you access private project data with the Connect operation. We recommend making sure, that the proxy user has access only to private projects.

For more info, check Security Vulnerability — You can access restricted project data with the Connect operation.

Proxy user permissions in Jira on-premise

In Jira on-premise, the proxy user needs to have the following permissions:

  • Browse Project.
  • Create issue.
  • Edit issue.
  • Link issue.
  • Transition issue: change statuses (on issue transition).
  • If comments are synchronized, the proxy user will need to add, edit, and delete a comment.
  • If attachments are synchronized, the proxy user needs to add, and delete attachments.
  • If work logs are synchronized, the proxy user needs to add, edit, and delete work logs.
  • If security levels are synchronized, the proxy user needs to access the security levels.
  • If you're using trigger the proxy user must be able to search issues. 


Jira Service Desk permissions

The proxy user needs to be a service desk agent.

Zendesk

By default, Exalate sets the Zendesk instance admin as the proxy user during installation.

Exalate requires a dedicated Zendesk admin as a proxy user. 

Proxy user permissions in Zendesk

Exalate requires a dedicated Zendesk admin as a proxy user. 

The proxy user can restrict the roles or groups that can access Exalate. It is possible when installing the app or when managing the app settings.


ServiceNow

To change the proxy user in Exalate for ServiceNow:

  1. Log in to the Exalate admin console.
  2. Navigate to General Settings.
  3. Input details:
    • Servicenow instance URL.
    • Proxy user name.
    • Proxy user password.

Proxy user permissions in ServiceNow

Users and permissions

For security reasons, it is better to create a separate role with specific permissions for a proxy user instead of giving him an administrator role.

To integrate Exalate with ServiceNow you need 2 ServiceNow user accounts:

Proxy User
The ServiceNow user account that fetches information from the ServiceNow instance and updates the ServiceNow entities with incoming changes.

The proxy user can integrate various tables or attributes depending on the permissions defined by his user role in ServiceNow.
Exalate Console user
The ServiceNow user that is authorized to configure the Exalate app for ServiceNow. The Exalate console user must be an admin in your ServiceNow instance or the proxy user.

Exalate uses REST API to communicate with the ServiceNow issue tracker. By default, ServiceNow REST APIs use basic authentication or OAuth to authorize user access to REST APIs/endpoints. Therefore, Exalate console user must have access to the ServiceNow instance admin configuration.

Role Management V2 REST API plugin must be installed and activated on your ServiceNow instance.

Starting from the New York version this plugin is included by default. But if you've recently updated your ServiceNow instance to the latest version you need to activate Role Management V2 REST API plugin manually. ServiceNow contextual security.

Configuring access on ServiceNow

You can access the ServiceNow instance in one of these ways: 

Basic login
In order to login you use a Username and a Password. Exalate will not store the password in the database, but use the rest connection to attempt to log in to the ServiceNow node.
OAuth token
Authentication with a Username and a OAuth token. Exalate will store the token and use it to access. The token is refreshed every time the lifespan ends.

OAuth token can be used as long as the refresh token is valid. Read more about setting up the refresh token in the article Access the Exalate app in ServiceNow.

You need to generate a new refresh token after the old one is expired. We suggest setting a longer lifespan for the refresh token.