You manage all settings related to users and authorizations from the "Team" page on the burger menu. This page contains tabs for users, groups, and roles:
The users tab shows details about the configured users, such as their name, email address, and their login type. The login type determines whether the user is an actual person who will log in using a password, or an API user. An API user is a virtual entity that is required to integrate Burp Suite Enterprise Edition with other software using either the REST API or GraphQL API.
The filter bar lets you show or hide users based on particular features. For example, you could choose to only show users who are locked out, or who have never logged in. Hovering the mouse over a user shows contextual options, such as disabling or deleting the user.
Note: Before creating new users, we recommend configuring your email server first as this makes it much easier to invite new users to Burp Suite Enterprise Edition, reset passwords that users have forgotten, and so on.
To edit an existing user, from the burger menu, go to "Team" > "Users" and select the user from the list. You can then edit their details in the same way as you did when creating a new user.
You can also disable a user temporarily by hovering over the user in the list and clicking the "Disable user" switch on the right of the screen. Or you can delete a user completely by clicking the "Delete user" icon.
Note that you cannot change a user's login type.
If you want to integrate Burp Suite Enterprise Edition with other software, such as Jira or a CI system, you need to create a dedicated API user that the other software will use to authenticate communication with Burp Suite Enterprise Edition via either the REST API or GraphQL API.
Note: API users cannot log in to the web UI.
Note that you cannot retrieve the API key for an existing user. If you lose it, you will have to generate a new key and manually update any files where it's used.
A role is a set of permissions to perform specific types of action. Roles group together a number of individual permissions that are related or depend upon each other. It is generally useful to define roles that match the actual job functions of people within your team. This facilitates placing users into the right groups in a quick and reliable way.
On the "Team" page, the roles tab shows all the configured roles. There are various built-in roles that define common job functions, such as administrator, scan initiator, and so on. These cannot be modified. However, you can create your own custom roles as necessary by clicking the "New role" button.
Hovering the mouse over a role shows contextual options for that role, such as deleting it.
You can click into a role to view details. For custom roles, you can edit the role name and the assigned permissions.
There are dependencies between some permissions. Logically, the permission to edit an entity usually depends on having permission to view the same entity. When editing permissions, these dependencies are indicated on the UI - permissions whose prerequisite permission has not been selected will be grayed out and unavailable for selection.
A group is a group of users with a predefined set of roles. For example, rather than managing every role for each user individually, you can set roles centrally on the group level and assign users to the relevant group accordingly.
Groups can also optionally be restricted to parts of the sites tree. Users in the group will inherit the permissions that are defined in the assigned roles, subject to any restrictions on sites. Each user can belong to multiple groups, and will inherit the roles and permissions resulting from all of the groups to which they belong.
The groups tab of the "Team" page shows details of the configured groups, including the group name, user count, and any restrictions on sites.
Hovering the mouse over a group shows contextual options for that group, such as deleting it.
You can use the "New group" button to create a new group. By clicking on an existing group, you can view and edit the group name, its assigned roles, users, and any site restrictions that are defined for the group.
The roles assigned to a group allow for vertical segregation of privileges so that different categories of user can perform different types of action; for example, being able to initiate scans versus being able to view scan results. The ability to place restrictions on sites allows for horizontal segregation of privileges so that different categories of user can perform the same types of action on different data; for example, being able initiate scans for some sites versus others.
The primary use case for restrictions on sites is to support teams where different groups of people require access to different parts of an organization's infrastructure. For example:
By default, groups have no restrictions on sites. This means that users in a group will have the defined roles in relation to all sites. In the group details, on the "Site restrictions" tab, you can configure a group to be restricted to certain sites. You can select parts of the site tree to which this group's roles apply. This can be folders or individual sites. Anything not explicitly allowed will be disallowed by default.
Within any folders that you select as allowed, you can deselect specific sites and subfolders that should be disallowed. This enables you to support various situations. For example, you might want to let a group view scan results for everything within the "Production" folder but disallow the "HR" folder beneath that, because its scan results might contain more sensitive information.