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

  1. 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.
  2. Enter the Username and Password. Click Next to continue.
  3. 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.

  1. 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.
  2. Enter a Name to represent the new role. Role names cannot contain dashes or spaces.
  3. Optionally, add one or more Aliases. See Role Aliases below for details.
  4. 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...N aliases 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 PlantOps with an alias Plant-Ops, an IDP that returns Plant-Ops matches the role, but an IDP that returns PlantOps does 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-Ops will not match an alias plant-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

ResourceDescription
*Specifies all resources
auditAudit messages in the event log
brokerMQTT Broker
certificateCertificates
conditionConditions
connectionConnections, includes inputs and outputs
functionGlobal functions
instanceInstances
logThe event log
lookupmapLookup maps
modelModels
namespaceNamespaces
networkNetwork hubs, groups, and sync operations
pipelinePipelines
secretSecrets
serverServers (e.g., the I3X Server)
settingsSystem level settings
tagTags
userUsers and roles

Supported Actions

ActionDescriptionApplies To
*Specifies all actionsAll resources
createCreate a new resourcecertificate, condition, connection, connection inputs, connection outputs, instance, lookupmap, model, namespace, network, pipeline, secret, tag, user
readRead the full configuration of a resource, including both list and detail informationaudit, certificate, condition, connection, connection inputs, connection outputs, function, instance, log, lookupmap, model, namespace, network, pipeline, secret, server, settings, tag, user
listRetrieve 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
updateEdit 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
deleteDelete a resourcecertificate, condition, connection, connection inputs, connection outputs, instance, lookupmap, model, namespace, network, pipeline, secret, tag, user
execute readRead data from a sourceconnection, connection inputs, condition, instance, lookupmap, namespace
execute writeWrite data to a target or run a pipelineconnection, connection outputs, pipeline, settings
publishPublish to an MQTT Broker topicbroker
subscribeSubscribe to an MQTT Broker topicbroker

Supported Scopes

ScopeDescription
Contains TagLimits 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.