About RBAC Permissions

Using Role-Based Access Control, an admin of an organization can empower their users with specific abilities or tools using permissions. Each user is defined by a role and assigned to a team; these aspects of the user's values in RBAC's organizational system will specify which permissions are available to them.

A team is a collection of multiple users identified as a single group unit within RBAC. A role is a defined set of permissions that can be granted to a user. Users assigned a certain role are considered "members" of that role, and members of a role are granted the permissions assigned to that role.

When a user is creating a new team, the following permissions are displayed, along with the team roles for whom the permissions applies:


A team permission can be granted to the team owner, a team admin, a team member, or any combination of those three. A purple toggle indicates that the permissions is active; a grey toggle means the permissions is inactive and therefore not granted to the indicated user. Toggles that appear faded are in their default state for the indicated user group and are locked. For example, in the picture above, by default the team owner has all permissions granted to them, and these permissions cannot be taken away from the team owner--so the toggles are all purple (active) and faded.

The permissions for a team can be described as follows:

Permission Codes Description
settings.modify Can change settings for team
members.modify Can change members on team
devices.modify Can change devices for team
member.make_admin User can make a member an admin (only available for Team Owner)
member.make_owner User can make a member an owner (only available for Team Owner)


Every user is assigned a role to determine what actions they can take in the Kobiton portal. These roles can be customized so that different users have unique sets of permissions (for example, a role called "App Manager" that has all app repo permissions assigned and none of the others, or a "Universal" role with all of the permissions assigned.) The actions contained in each permissions are described below:


Role permissions:

Permission codes

App Repo


Delete other users' public apps (this also includes private apps if the view_all permissions below is enabled)


View all public/locked apps


Upload app; can also rename an app uploaded by the user previously



User can create custom device name

Device Tag


User can create tags for devices

Organization Management


User has access to all abilities in org management tab (create, edit, invite user, etc… for Groups/Roles/Users/Devices Bundle



Delete other users' softbook



View all sessions in the org


Terminate others (all) session


Modify information of session (e.g, session name, etc.); also allows user to delete sessions

Organization Settings


View and edit cleanup policy (org level) + iFrame + Integration (disable/enable) + Other Settings


View and edit SSO settings/configuration


Note: Team permissions are somewhat limited by the Owner/Admin/Member structure of teams, and some permissions can only be held by a user with a specific team user status of Owner or Admin. Role permissions do not have this limitation as they are designed to be highly customizable.

Was this article helpful?
0 out of 0 found this helpful