Role-Based Access Control

Permissions are assigned to Roles, not individual users. A Role is a Node of type RoleType in the Address Space. Administrators grant access by adding an IdentityMappingRule to a Role, which specifies criteria (e.g., user identity, application URI) for membership. This decouples user management from access control logic, simplifying administration at scale.

RBAC enables fine-grained control over every Node in the Address Space. Permissions are defined using the standard RolePermissionType attribute, which specifies:

• Read: View the Node's attributes
• Write: Modify the Node's value
• Call: Execute Methods
• Browse: Discover the Node
• ReceiveEvents: Subscribe to Events Each permission can be independently granted or denied per Role.

When a Session is created, the Server evaluates all IdentityMappingRule criteria against the authenticated user's credentials and the Client's ApplicationInstanceCertificate. Rules can match on:

• User Identity: Specific username or group membership
• Application URI: The Client application's unique identifier
• Endpoint URL: The connection endpoint used Matching Roles are aggregated to determine the effective permissions for the Session.

OPC UA defines a set of standard Roles to bootstrap authorization:

• Anonymous: Unauthenticated users (default: minimal access)
• AuthenticatedUser: Any authenticated identity
• Observer: Read-only access to process data
• Operator: Read and write access to operational variables
• Supervisor: Elevated privileges for configuration
• ConfigureAdmin: Full administrative access
• SecurityAdmin: Manage security policies and certificates These can be extended or restricted per deployment.

Roles can be organized hierarchically using Organizes or HasChild References. A child Role inherits all permissions from its parent Role, plus any additional permissions explicitly granted. For example, a SeniorOperator Role can inherit all permissions from Operator and add the ability to acknowledge critical Alarms. This reduces redundant configuration and enforces consistent policy structures.

All RBAC configuration is stored as Nodes in the Address Space, making it fully discoverable and auditable via standard OPC UA Browse and Read services. The RoleMappingRuleChangedAuditEvent is generated whenever a Role's membership rules are modified. This provides a verifiable audit trail for regulatory compliance, ensuring that access control changes are tracked with timestamps and user attribution.

The fundamental atomic unit within an OPC UA Address Space to which RBAC permissions are assigned. Each Node possesses a unique NodeId and a set of Attributes that describe its value and behavior. Access rights are granted or denied at the Node level, allowing administrators to restrict visibility of specific sensors, actuators, or methods. A Node's RolePermissions attribute stores the list of roles authorized to interact with it.

A long-lived logical connection between an OPC UA Client and Server that carries the authenticated user's identity. Upon session creation, the Server associates the user with their assigned Roles. All service requests within that Session—reads, writes, method calls—are evaluated against the RolePermissions of the target Node. The session's identity context is immutable for its lifetime.

A set of predefined, standardized roles defined by the OPC UA specification to ensure baseline interoperability:

• Anonymous: Unauthenticated users with minimal access
• AuthenticatedUser: Any user who has successfully logged in
• Observer: Read-only access to non-sensitive data
• Operator: Ability to execute methods and acknowledge alarms
• Engineer: Configuration and tuning privileges
• Supervisor: User management and role assignment
• ConfigureAdmin: Full system configuration rights
• SecurityAdmin: Exclusive control over certificates and security policies

A complementary OPC UA security mechanism that works alongside RBAC to enforce session-level constraints. While RolePermissions control access based on user identity, Access Restrictions apply additional rules such as:

• Session timeout limits
• Transport layer requirements (e.g., only secure channels)
• IP address allowlists
• Certificate policy enforcement Together, they create a defense-in-depth authorization model.

The process by which an OPC UA Server resolves an authenticated user's credentials—X.509 certificate, WS-Security token, or username/password—into a set of assigned roles. This mapping is typically configured through the Server's UserManagement model. Effective RBAC depends on accurate identity mapping; a misconfigured mapping can inadvertently grant elevated privileges to unauthorized users.

The OPC UA AuditEvent system generates tamper-proof logs of all access attempts, both permitted and denied. Each event records:

• The SessionId and user identity
• The target NodeId
• The requested action (read, write, execute)
• The RolePermissions evaluated
• The final access decision This audit trail is essential for compliance with IEC 62443 and other industrial security standards.