Security Conformance Units and serverside implementation

[P_Berger]

Hi all

I'm struggling a bit with the security related information available.
OPC UA defines a lot of conformance units (security group, security best practices) and also has a lot of text like "it should not be made accessible to all users, but only to authorized users via encrypted channels" or "may only be browsed and accessed by authorized administrators and requires an encrypted channel".
And the "well known roles" are also widely used, right up to the conformance units.

Regardless of the use case and implementation scenario, there are a number of server-related restrictions that should be resolved by the SDK itself. For example, in the node paths and their childs Server/ServerConfiguration/UserManagements or Server/ServerCapabilities/RoleSet or Server/PublishSubscribe, permissions should be restricted to certain admin roles in order to be compliant with the specification. On the other hand, access to the PermissionType attribute of each node should also be restricted to a security-relevant role.
In the whell-known-roles, SecurityAdmin and ConfigureAdmin are mentioned...

So the questions are:
- What is already solved by the SDK (especially the server SDK)?
- Where can I get an overview of the (predefined) permissions (especially the value of the permissionType attribute) and the affected nodes within the server object?
- If there are no predefined authorization restrictions for certain whell-known-roles, how can the permissions for server-internal nodes be set?
- Does a list or best practices of permissions and the corresponding node IDs for admin roles exists?

Best regards
Patrick

[Support Team]

Hi,

we would to some extend agree that the SDK could do some (default) settings for the NS0 and NS1 nodes and assign some of the predefined roles to them. (see .NET SDK 3.4.1 for reference). However, the use case may decide differently, hence the OPCF gives advice rather than rules. Secondly you need to consider backward compatibility to e.g. many clients out there that have never seen nor set any user authentication.

The basic idea is, that all the SDK that support role based security, will in turn preconfiger at least some default roles (from the list if well known), and may even have a default role per each namespace (for simplicity), however the beauty of the OPCF role based user authentication is it's flexibility and extendability, which we leave to the implementer.

Specifically for the .NET SDK we can configure/load roles with XMLNodeSet and we can (recursively) inherit from the parent folder on startup.

Caution: must be careful when creating new nodes thereafter and set role correctly.