Understanding Role-Based Access Control in Mango

Overview

Role-based access control (RBAC) is how Mango by Radix IoT decides what each user can see and do. You do not give permissions to individual users. You create roles, assign roles to users, and name roles in the permissions on Mango's objects. Change which roles a permission names, and every user holding those roles is affected at once.

Key Concepts

Roles

A role is a name, such as "operator", "viewer" or "site-a-engineer". A role carries no permissions of its own: it grants access only where a permission names it. A role can also inherit other roles. If supervisor inherits operator, a user holding supervisor passes every check that names operator. Inheritance flows one way only: operator gains nothing from supervisor.

Mango has exactly three built-in roles:

• superadmin: passes every permission check. The default admin account holds it.
• user: held automatically by every account that can log in, so a permission that names user is open to every logged-in user.
• anonymous: held by visitors who are not logged in.

There is no built-in "admin", "operator" or "viewer" role. Every other role is one you create, and a role's name and XID cannot be changed afterwards.

Users

Each person who logs in has a user account, and roles are assigned on the user editor at Access management > Users. A user's effective roles are the roles assigned to them, every role those roles inherit, and user.

Two Kinds of Permission

• Object permissions are set on each Mango object (a data point, data source, page, watch list, report template or event handler) and say which roles can view it, edit it and, for a data point, set its value.
• System permissions are named capabilities that are not tied to one object, such as Data source management (create/edit data sources) or Create users. They are set at Access management > System permissions.

Neither kind delegates Mango's administration. Every page under Administration requires superadmin, and so do System permissions itself, Event handlers and Bulk data point edit. A custom role can own objects; it cannot administer the instance.

How a Permission Is Checked

A permission is a list of entries. Usually each entry is a single role; with Advanced mode switched on in the permission editor, one entry can be a combination of roles that must all be held together. Mango grants access when:

Example: a data point's View point & value permission has two entries, operator and engineer. A user holding operator can see the point. A user holding only viewer cannot. If the permission instead had one entry combining operator and site-a, a user would need both roles.

An empty permission, with no entries, is open to superadmin only. Most system permissions start superadmin-only; a few, such as View events page and the watch-list permissions, start granted to user, which every logged-in account holds. Roles only ever add access: holding another role never takes any away.

Permission Types by Object

The Dashboard Permission Chain

For a user to see live data on a page, every layer must let them through:

1. Menu item: if they reach the page from the menu, the item's View menu item permission, or its Link to system permission, must include them. Menu items are edited at Platform management > Edit menu.
2. Page: the page's View page permission must include them.
3. Watch list: if the page reads a watch list, View watch list must include them.
4. Data points: each point's View point & value must include them. Points they cannot view are left out.

When someone reports a page with missing data, check the layers in that order. Changing a value from a widget also needs Set point value on that point.

Superadmin

The superadmin role passes every check, and it is the only way to reach the Administration pages. Keep the number of superadmin accounts small, and give everyone else custom roles scoped to the objects they work with.

Common RBAC Patterns

Simple (Small Team)

• superadmin: the one or two people who administer Mango
• operator: named in View point & value and Set point value on the points they run, and in View page on their pages
• viewer: named in View page, View watch list and View point & value only

Multi-Site

• site-a-operator, site-b-operator: each named on its own site's points and pages
• global-viewer: view access across every site. The Data Point view permission system permission gives view on every point in one place.

Tags do not carry permissions: a point tagged site=A is not restricted to site A's roles. Each point's permissions are set on the point itself, and a superadmin can set them on many points at once with Data integration > Bulk data point edit.

Multi-Tenant

• superadmin: runs the instance
• customer-a-admin: inherits customer-a-operator, holds the View users page and Create users system permissions, and edits Customer A's objects
• customer-a-operator: operates Customer A's equipment
• customer-b-admin, customer-b-operator: the same for Customer B

Two rules keep tenants apart. A user who is not a superadmin can assign only roles they hold themselves, and can add or remove only permission entries made of roles they hold, so customer-a-admin can hand out customer-a-operator but never a Customer B role. And a tenant admin still cannot reach Administration. Editing an existing user needs that user's own edit permission; there is no system permission for editing users.

Best Practices

• Create roles for functions, not people: "operator", not "john-permissions"
• Name roles carefully the first time: a role cannot be renamed, only replaced
• Use as few roles as your access rules need: add one only when two groups of users genuinely need different access
• Use inheritance for layered access: a supervisor role that inherits operator saves naming both on every object
• Assign several roles when needed: someone who operates Site A and views everything else holds site-a-operator and global-viewer
• Document your role structure: keep a table of each role and where it is named
• Test as the user: a superadmin can open a user's More options menu on Access management > Users and choose Switch to user to see Mango as that user does

Summary

Mango grants access through roles, never directly to users. Object permissions name roles on each point, data source, page, watch list, report template and event handler; system permissions name roles for a few instance-wide capabilities; and only superadmin administers the instance. A user passes a check by holding every role in one entry, inherited roles included. When data is missing from a page, walk the chain: menu item, page, watch list, data point.