Errata exists for this version of the document.
A Role is a function assumed by a Client when it accesses a Server. Roles are used to separate authentication (determining who a Client is) from authorization (determining what the Client is allowed to do). By separating these tasks Servers can allow centralized services to manage user identities and credentials while the Server only manages the Permissions on its Nodes assigned to Roles.
The set of Roles supported by a Server are published as components of the Roles Object defined in OPC 10000-5. Servers should define a base set of Roles and allow configuration Clients to add system specific Roles.
When a Session is created, the Server must determine what Roles are granted to that Session. This specification defines standard mapping rules which Servers may support. Servers may also use vendor specific mapping rules in addition to or instead of the standard rules.
The standard mapping rules allow Roles to be granted based on:
- User identity;
- Application identity;
- Endpoint;
User identity mappings can be based on user names, user certificates or user groups. Well known groups include ‘AuthenticatedUser’ (any user with valid credentials) and ‘Anonymous’ (no user credentials provided).
Application identity mappings are based on the ApplicationUri specified in the Client Certificate. Application identity can only be enforced if the Client proves possession of a trusted Certificate by using it to create a Secure Channel or by providing a signature in ActivateSession (see OPC 10000-4).
Endpoint identity mappings are based on the URL used to connect to the Server. Endpoint identity can be used to restrict access to Clients running on particular networks.
OPC 10000-5 defines the Objects, Methods and DataTypes used to represent and manage these mapping rules in the Address Space.
All Servers should support the well-known Roles which are defined in Table 2. The NodeIds for the well-known Roles are defined in OPC 10000-6.
BrowseName |
Suggested Permissions |
Anonymous |
The Role has very limited access for use when a Session has anonymous credentials. |
AuthenticatedUser |
The Role has limited access for use when a Session has valid non-anonymous credentials but has not been explicitly granted access to a Role. |
Observer |
The Role is allowed to browse, read live data, read historical data/events or subscribe to data/events. |
Operator |
The Role is allowed to browse, read live data, read historical data/events or subscribe to data/events. In addition, the Session is allowed to write some live data and call some Methods. |
Engineer |
The Role is allowed to browse, read/write configuration data, read historical data/events, call Methods or subscribe to data/events. |
Supervisor |
The Role is allowed to browse, read live data, read historical data/events, call Methods or subscribe to data/events. |
ConfigureAdmin |
The Role is allowed to change the non-security related configuration settings. |
SecurityAdmin |
The Role is allowed to change security related settings. |
When a Client attempts to access a Node, the Server goes through the list of Roles granted to the Session and logically ORs the Permissions for the Role on the Node. If there are no Node specific Permissions then the default Permissions for the Role in the DefaultRolePermissions Property of the NamespaceMetadata for the namespace the Node belongs to are used (see OPC 10000-5). The resulting mask is the effective Permissions. If the bits corresponding to current operation are set, then the operation can proceed. If they are not set the Server returns Bad_UserAccessDenied.
Roles appear under the Roles Object in the Server Address Space. Each Role has mapping rules defined which appear as Properties of the Role Object (see OPC 10000-5). The examples shown in Table 3 illustrate how the standard mapping rules can be used to determine which Roles a Session has access to and, consequently, the Permissions that are granted to the Session.
Role |
Mapping Rules |
Description |
Anonymous |
Identities = Anonymous Applications = Endpoints = |
An identity mapping rule that specifies the Role applies to anonymous users. |
AuthenticatedUser |
Identities = AuthenticatedUser Applications = Endpoints = |
An identity mapping rule that specifies the Role applies to authenticated users. |
Operator1 |
Identities = User with name ‘Joe’ Applications = urn:OperatorStation1 Endpoints = |
An identity mapping rule that specifies specific users that have access to the Role with a application rule that restricts access to a single Client application. |
Operator2 |
Identities = Users with name ‘Joe’ or ‘Ann’ Applications = urn:OperatorStation2 Endpoints = |
An identity mapping rule that specifies specific users that have access to the Role with a application rule that restricts access to a single Client application. |
Supervisor |
Identities = User with name ‘Root’ Applications = Endpoints = |
An identity mapping rule that specifies specific users that have access to the Role |
Administrator |
Identities = User with name ‘Root’ Applications = Endpoints = opc.tcp://127.0.0.1:48000 |
An identity mapping rule that specifies specific users that have access to the Role when they connect via a specific Endpoint. |
The examples also make use of the Nodes defined in Table 4. The table specifies the value of the RolePermissions Attribute for each Node.
Node |
Role Permissions |
Unit1.Measurement |
AuthenticatedUser = Browse Operator1 = Browse, Read |
Unit2.Measurement |
AuthenticatedUser = Browse Operator2 = Browse, Read |
SetPoint |
AuthenticatedUser = Browse Operator1 and Operator2 = Browse, Read, Write Supervisor = Browse, Read |
DisableDevice |
AuthenticatedUser = Browse Operator1 and Operator2 = Browse, Read Administrator = Browse, Read, Write |
When a Client creates a Session the Roles assigned to the Session depend on the rules defined for each Role. Table 5 lists the assigned Roles for different Sessions created with different Users, Client applications and Endpoints.
Table 5 – Example Role Assignment
User Provided by Client |
Roles Assigned to Session |
Anonymous |
Anonymous |
Sam |
AuthenticatedUser |
Joe using OperatorStation1 application. |
AuthenticatedUser, Operator1 |
Joe using OperatorStation2 application. |
AuthenticatedUser, Operator2 |
Joe using generic application. |
AuthenticatedUser |
Root using OperatorStation1 application. |
AuthenticatedUser, Supervisor |
Root using generic application and 127.0.0.1 endpoint. |
AuthenticatedUser, Supervisor, Administrator |
Root using generic application and another endpoint. |
AuthenticatedUser, Supervisor |
When a Client application accesses a Node the RolePermissions for the Node are compared to the Roles assigned to the Session. Any Permissions available to at least one Role is granted to the Client. Table 6 provides a number of scenarios and examples and the resulting decision on access.
Table 6 – Examples of Evaluating Access
Use Case |
Role Permissions |
Anonymous user on localhost browses Unit1.Measurement Node. |
Access denied because no rule defined for Anonymous users. |
User ‘Sam’ using OperatorStation1 application browses Unit1.Measurement Node. |
Allowed because AuthenticatedUser is granted Browse Permission. |
User ‘Sam’ using OperatorStation2 application reads Value of Unit1.Measurement Node. |
Access denied because AuthenticatedUser is not granted Read Permission. |
User ‘Joe’ using OperatorStation1 application reads Value of Unit1.Measurement Node. |
Allowed because Operator1 is granted Read Permission. |
User ‘Joe’ using OperatorStation2 application reads Value of Unit1.Measurement Node. |
Access denied because AuthenticatedUser and Operator2 are not granted Read Permission. |
User ‘Joe’ using generic OPC UA application reads Value of Measurement Node. |
Access denied because AuthenticatedUser is not granted Read Permission. |
User ‘Joe’ using OperatorStation1 application write Value of SetPoint Node. |
Allowed because Operator1 is granted Write Permission. |
User ‘Root’ using OperatorStation1 application write the Value of SetPoint Node. |
Denied because AuthenticatedUser and Supervisor are not granted Write Permission. |
User ‘Joe’ using OperatorStation1 application write Value of DisableDevice Node. |
Access denied because AuthenticatedUser and Operator1 are not granted Write Permission. |
User ‘Root’ using OperatorStation1 application write the Value of DisableDevice Node. |
Access denied because AuthenticatedUser and Supervisor are not granted Write Permission. |
User ‘Root’ using endpoint 127.0.0.1 to write Value of DisableDevice Node. |
Allowed because Administrator is granted Write Permission. |