A Roleis a function assumed by a Client when it accesses a Server. Rolesare used to separate authentication (determining who a Clientis) from authorization (determining what the Clientis allowed to do). By separating these tasks Serverscan allow centralized services to manage user identities and credentials while the Serveronly manages the Permissionson its Nodesassigned to Roles.
The set of Rolessupported by a Serverare published as components of the Roles Objectdefined in OPC 10000-5. Serversshould define a base set of Rolesand allow configuration Clientsto add system specific Roles.
When a Sessionis created, the Servermust determine what Rolesare granted to that Session. This specification defines standard mapping rules which Serversmay support. Serversmay also use vendor specific mapping rules in addition to or instead of the standard rules.
The standard mapping rules allow Rolesto 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 ApplicationUrispecified in the Client Certificate. Application identity can only be enforced if the Clientproves possession of a trusted Certificateby using it to create a Secure Channelor 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 Clientsrunning on particular networks.
OPC 10000-5defines the Objects, Methodsand DataTypesused to represent and manage these mapping rules in the Address Space.
All Serversshould support the well-known Roleswhich are defined in Table 2. The NodeIdsfor the well-known Rolesare defined in OPC 10000-6.
BrowseName |
Suggested Permissions |
Anonymous |
The Rolehas very limited access for use when a Sessionhas anonymous credentials. |
AuthenticatedUser |
The Rolehas limited access for use when a Sessionhas valid non-anonymous credentials but has not been explicitly granted access to a Role. |
Observer |
The Roleis allowed to browse, read live data, read historical data/events or subscribe to data/events. |
Operator |
The Roleis allowed to browse, read live data, read historical data/events or subscribe to data/events. In addition, the Sessionis allowed to write some live data and call some Methods. |
Engineer |
The Roleis allowed to browse, read/write configuration data, read historical data/events, call Methods or subscribe to data/events. |
Supervisor |
The Roleis allowed to browse, read live data, read historical data/events, call Methods or subscribe to data/events. |
ConfigureAdmin |
The Roleis allowed to change the non-security related configuration settings. |
SecurityAdmin |
The Roleis allowed to change security related settings. |
When a Clientattempts to access a Node,the Servergoes through the list of Rolesgranted to the Sessionand logically ORs the Permissionsfor the Roleon the Node. If there are no Node specific Permissions thenthe default Permissionsfor the Rolein the DefaultRolePermissions Property of the NamespaceMetadatafor the namespace the Nodebelongs 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 Serverreturns Bad_UserAccessDenied.
Rolesappear under the Roles Objectin the Server Address Space. Each Rolehas mapping rules defined which appear as Propertiesof the Role Object(see OPC 10000-5). The examples shown in Table 3illustrate how the standard mapping rules can be used to determine which Rolesa Sessionhas access to and, consequently, the Permissionsthat are granted to the Session.
Role |
Mapping Rules |
Description |
Anonymous |
Identities = Anonymous Applications = Endpoints = |
An identity mapping rule that specifies the Roleapplies to anonymous users. |
AuthenticatedUser |
Identities = AuthenticatedUser Applications = Endpoints = |
An identity mapping rule that specifies the Roleapplies 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 Rolewith 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 Nodesdefined in Table 4. The table specifies the value of the RolePermissions Attributefor 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 Clientcreates a Sessionthe Rolesassigned to the Sessiondepend on the rules defined for each Role. Table 5lists the assigned Rolesfor different Sessionscreated with different Users, Clientapplications 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 Clientapplication accesses a Nodethe RolePermissionsfor the Nodeare compared to the Rolesassigned to the Session. Any Permissionsavailable to at least one Roleis granted to the Client. Table 6provides 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 Valueof Unit1.Measurement Node. |
Access denied because AuthenticatedUser is not granted Read Permission. |
User ‘Joe’ using OperatorStation1 application reads Valueof Unit1.Measurement Node. |
Allowed because Operator1 is granted Read Permission. |
User ‘Joe’ using OperatorStation2 application reads Valueof Unit1.Measurement Node. |
Access denied because AuthenticatedUser and Operator2 are not granted Read Permission. |
User ‘Joe’ using generic OPC UA application reads Valueof Measurement Node. |
Access denied because AuthenticatedUser is not granted Read Permission. |
User ‘Joe’ using OperatorStation1 application write Valueof SetPoint Node. |
Allowed because Operator1 is granted Write Permission. |
User ‘Root’ using OperatorStation1 application write the Valueof 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 Valueof DisableDevice Node. |
Access denied because AuthenticatedUser and Supervisor are not granted Write Permission. |
User ‘Root’ using endpoint 127.0.0.1 to write Valueof DisableDevice Node. |
Allowed because Administrator is granted Write Permission. |