4 AddressSpace concepts ToC Previous Next

4.8 Roles ToC Previous Next

4.8.3 Evaluating Permissions with Roles ToC Previous Next

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.

Table 3 – Example Roles

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.

Table 4 – Example Nodes

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.

Previous Next