Users and Roles
Users can be created and assigned roles and/or claims to allow them to perform certain types of operations.
To create a new User
- Navigate to Users in the configuration’s Main Menu. Here you can add, edit, and view users. To add a user, click the New User button.
- Enter the Username and Password. Click Next to continue.
- Select the Roles and/or set the Claims the user inherits. Click Submit to add the user. Claims are specified through the usage of resources and actions. Resources are the object (e.g., connection) and actions are the operation that can be performed in CRUD terminology (create, read, update, delete) on a resource.
To create a new Role
Roles can be created and assigned claims that are inherited by one or more users. The roles define the type of operations a class of users may perform.
- Navigate to Roles in the configuration’s Main Menu. Here you can add, edit, and view roles. To add a role, click the New Role button.
- Enter a Name to represent the new role. Role names cannot contain dashes or spaces.
- Optionally, add one or more Aliases. See Role Aliases below for details.
- Set the Claims the user assigned to this role should inherit. Click Submit to add the role.
Role Aliases
Roles can define one or more aliases that are used to match the role against groups or
roles returned by an
external identity provider
(SAML, OIDC, or
Active Directory). Aliases exist because role names cannot contain dashes or spaces, while
external group names (for example, an Active Directory group named Plant-Ops) frequently do.
By adding an alias, you can map such a group to a hub role without changing the role’s name.
- A role can have
1...Naliases and have no character restrictions. - Every alias must be unique across all other role names and aliases. Creating or updating a role with an alias that collides with an existing role name or alias is rejected, and the error names the conflicting role.
- When a role has one or more aliases, the external provider is matched only against the
aliases — the role’s name is no longer used for matching. For example, if a role is named
PlantOpswith an aliasPlant-Ops, an IDP that returnsPlant-Opsmatches the role, but an IDP that returnsPlantOpsdoes not. When a role has no aliases, the role’s name is used for matching as before. - All matching against external groups and roles is case-sensitive. An IDP group
Plant-Opswill not match an aliasplant-ops. - If the users store has two roles that share the same alias, that alias is treated
as ambiguous: it grants no role and a warning is logged (
highbyte.authentication.UserStore). Any other roles the user is assigned to are still granted, and login still succeeds.
See SAML, OIDC, and Active Directory for how aliases are used during login.
Claim Information
Supported Resources
| Resource | Description |
|---|---|
| * | Specifies all resources |
| audit | Audit messages in the event log |
| broker | MQTT Broker |
| certificate | Certificates |
| condition | Conditions |
| connection | Connections, includes inputs and outputs |
| function | Global functions |
| instance | Instances |
| log | The event log |
| lookupmap | Lookup maps |
| model | Models |
| namespace | Namespaces |
| network | Network hubs, groups, and sync operations |
| pipeline | Pipelines |
| secret | Secrets |
| server | Servers (e.g., the I3X Server) |
| settings | System level settings |
| tag | Tags |
| user | Users and roles |
Supported Actions
| Action | Description | Applies To |
|---|---|---|
| * | Specifies all actions | All resources |
| create | Create a new resource | certificate, condition, connection, connection inputs, connection outputs, instance, lookupmap, model, namespace, network, pipeline, secret, tag, user |
| read | Read the full configuration of a resource, including both list and detail information | audit, certificate, condition, connection, connection inputs, connection outputs, function, instance, log, lookupmap, model, namespace, network, pipeline, secret, server, settings, tag, user |
| list | Retrieve the names of resources without exposing their configuration. This allows the resources whose data can be read or written using the execute actions to be discovered, or a resource to be resolved by name. | connection, connection inputs, connection outputs, condition, instance, model, pipeline |
| update | Edit an existing resource. Editing an existing resource also requires the read action. | certificate, condition, connection, connection inputs, connection outputs, function, instance, lookupmap, model, namespace, network, pipeline, secret, server, settings, tag, user |
| delete | Delete a resource | certificate, condition, connection, connection inputs, connection outputs, instance, lookupmap, model, namespace, network, pipeline, secret, tag, user |
| execute read | Read data from a source | connection, connection inputs, condition, instance, lookupmap, namespace |
| execute write | Write data to a target or run a pipeline | connection, connection outputs, pipeline, settings |
| publish | Publish to an MQTT Broker topic | broker |
| subscribe | Subscribe to an MQTT Broker topic | broker |
Supported Scopes
| Scope | Description |
|---|---|
| Contains Tag | Limits access to resources tagged by one of the specified tags. NOTE: This scope only applies to Pipelines, Connections, Conditions, Models, and Instances. |
API Keys
API Keys can be created and assigned to a user to limit access to the REST Data Server.
User API keys have a name, expiration date (optional) and description. Once created, the API key can be used as part of the REST Data Server login. See Application Settings for details on token based login.
As an example, to limit write access to an OPC UA connection through the REST Data Server, create a claim for the user with the execute write action on a connection resource, tag the connection with a new tag (ex. opcua_write), and include the tag in claim.