Example Roles for HighByte Intelligence Hub

HighByte Intelligence Hub uses a role-based access control (RBAC) model to determine what each user can see and do. Every user is assigned one or more roles, and each role is a set of claims that grant specific actions on specific resources. This article walks through the built-in roles, provides example custom roles for common personas, and shows how to apply them.

How roles work

A role is a named collection of claims. Each claim answers two questions:

• Resources: what kind of object does this apply to? (e.g. pipeline, connection, model)
• Actions: what operations are allowed on those resources? (e.g. read, list, create, update, delete, execute_read, execute_write)

Both fields accept "*" as a wildcard. A claim of "resources": ["*"], "actions": ["*"] grants full access to everything.

Roles are defined in the Intelligence Hub intelligencehub-users.json file. On a typical install this lives under the appData directory. Edits require an Intelligence Hub restart to take effect.

 Action verbs

The actions used in claims map to specific operations in the Intelligence Hub UI and REST API.

• read: view the configuration of an individual object (open a pipeline, inspect a connection).
• list: enumerate objects of a given type (see the pipeline list, see the connection list). Without list, an object type is effectively hidden even if read is granted.
• create: add new objects of that type.
• update: modify existing objects.
• delete: remove objects.
• execute_read: run read-side operations against a resource. For a connection, this means reading tag values from the source. For an instance, it means resolving the instance's current data.
• execute_write: run write-side operations. For a pipeline, this means starting, stopping, and running the pipeline. For a connection, it means writing values back to the source.
• *: wildcard for every action supported on that resource.

Built-in roles

Every Intelligence Hub install ships with two roles.

admin

Full access to all resources and actions. Assigned to the default administrator user out of the box.

{ "name" : "admin", "policyVersion" : 1, "claims" : [ { "resources" : [ "*" ], "actions" : [ "*" ] } ] } 

default

Applied to any authenticated user who has no other role assigned. Grants read access across the board plus full control over connections, instances, and pipelines. If you want unauthenticated or fallback access to be more restrictive, tighten this role.

{   "name" : "default",   "policyVersion" : 1,   "claims" : [ {     "resources" : [ "*" ],     "actions" : [ "read" ]   }, {     "resources" : [ "connection", "instance", "pipeline" ],     "actions" : [ "*" ]   } ] }  Example custom roles

 Example custom roles 

The following roles are a starting point for common personas. Copy them into the roles array of your intelligencehub-users.json, adjust as needed, and assign them to users. 

DataOpsConfigurationViewer

Read-only visibility into the Intelligence Hub configuration. Good for auditors, reviewers, or stakeholders who need to see how things are set up without any ability to change them.

Can do: view and list connections, instances, models, and pipelines. Read logs. Cannot do: create, edit, or delete anything. Execute anything (no reading live tag values, no starting pipelines). Manage tags, functions, users, or system settings.

{   "name" : "DataOps-ConfigurationViewer",   "policyVersion" : 1,   "claims" : [     { "name" : "LogRead",        "resources" : [ "log" ],        "actions" : [ "read" ] },     { "name" : "InstanceRead",   "resources" : [ "instance" ],   "actions" : [ "read", "list" ] },     { "name" : "ModelRead",      "resources" : [ "model" ],      "actions" : [ "read", "list" ] },     { "name" : "PipeLineRead",   "resources" : [ "pipeline" ],   "actions" : [ "read", "list" ] },     { "name" : "ConnectionRead", "resources" : [ "connection" ], "actions" : [ "read", "list" ] }   ] } 

DataPipelineEngineer

Focused on building and operating pipelines and functions. Can read connections and execute reads against them but cannot modify connection configuration. Ideal for IT or data engineering staff whose job is data movement and transformation, not source system connectivity.

Can do: create, edit, and delete pipelines and functions. Start, stop, and run pipelines. View connections and read live values from them. Read and list logs. Cannot do: create, edit, or delete connections. Manage instances, models, or tags. Write values back to source systems.

{   "name" : "DataPipelineEngineer",   "policyVersion" : 1,   "claims" : [     { "name" : "LogRead",             "resources" : [ "log" ],        "actions" : [ "read", "list" ] },     { "name" : "FunctionManagement",  "resources" : [ "function" ],   "actions" : [ "create", "read", "list", "update", "delete" ] },     { "name" : "ConnectionRead",      "resources" : [ "connection" ], "actions" : [ "read", "list", "execute_read" ] },     { "name" : "PipelineManagement",  "resources" : [ "pipeline" ],   "actions" : [ "create", "read", "list", "update", "delete", "execute_write" ] }   ] } 

OTDataEngineer

For OT-side users who own the source system connectivity and modeling layer. Can manage instances, tags, and models, and can execute reads against connections. Cannot modify pipelines or functions.

Can do: create, edit, and delete instances, tags, and models. Read live values from connections and instances. View existing connections. Read and list logs. Cannot do: create, edit, or delete connections themselves. Build or run pipelines. Create or modify functions.

{   "name" : "OTDataEngineer",   "policyVersion" : 1,   "claims" : [     { "name" : "LogRead",            "resources" : [ "log" ],        "actions" : [ "read", "list" ] },     { "name" : "ConnectionRead",     "resources" : [ "connection" ], "actions" : [ "read", "list", "execute_read" ] },     { "name" : "TagManagement",      "resources" : [ "tag" ],        "actions" : [ "create", "read", "list", "update", "delete" ] },     { "name" : "InstanceManagement", "resources" : [ "instance" ],   "actions" : [ "create", "read", "list", "update", "delete", "execute_read" ] },     { "name" : "ModelManagement",    "resources" : [ "model" ],      "actions" : [ "create", "read", "list", "update", "delete" ] }   ] } 

DataPlatformEngineer

Full-access role equivalent to admin. Provided as a named alternative so you can distinguish platform owners from the built-in administrator account in audit logs.

Can do: everything. Full control over all resources. Cannot do: nothing is restricted at the role level.

{   "name" : "DataPlatformEngineer",   "policyVersion" : 1,   "claims" : [ {     "name" : "all",     "resources" : [ "*" ],     "actions" : [ "*" ]   } ] }  Assigning roles to users

Full importable example intelligencehub-users.json

Deploying these roles

There are two supported ways to get these roles into an Intelligence Hub install.

Option 1: Fresh install

Drop the attached intelligencehub-user.json into the application data directory before starting Intelligence Hub for the first time. The file ships with the default administrator state (no password).

1. Stop Intelligence Hub if it is running.
2. Copy intelligencehub-user.json into the application data directory.
3. Start Intelligence Hub.
4. Log in as administrator with no password.
5. Immediately set a real password. Navigate to Users, edit the administrator account, and set a password.

Option 2: Existing install

If Intelligence Hub is already running with users and passwords in place, do not overwrite the file. Merge the roles in instead.

1. Stop Intelligence Hub.
2. Back up the existing intelligencehub-user.json in the application data directory.
3. Open the file and copy the role entries from the attached example into the roles array. Leave the existing users, credentials, and apiKeys sections alone.
4. Save the file.
5. Start Intelligence Hub.
6. Assign the new roles to users through the UI (Users, edit user, select roles).

Tips

• Roles are additive. If a user has two roles, they get the union of both. Design roles as focused building blocks rather than large all-in-one permission sets.
• After editing intelligencehub-users.json, restart Intelligence Hub for the changes to take effect.
• Back up intelligencehub-users.json before making changes. A malformed file will prevent Intelligence Hub from starting.