Client access control

Unified Architecture topics related to OPC UA Specification, compliant behavior and any technical issues of OPC UA, like Security, Information Model, Companion Specs DI, PLCopen, ADI, ...

Moderator: Support Team

Post Reply
pfp.meijers
Sr. Member
Sr. Member
Posts: 13
Joined: 02 Oct 2014, 09:08

Client access control

Post by pfp.meijers »

Hi all,

I am new in OPC UA and considering usage of OPC UA as the inter-process communication backbone of my system, for which I have the following requirement:
I need to have (design-time) control of which client software modules are allowed to use what parts of a server's address space.
(I am talking about a mechanism to control dependencies between my software modules and not about user authorization.)

How can this be arranged in OPC-UA? Does anyone have a suggestion?
Can different views be of help in this, or different namespaces and can access certificates be managed for parts of the server's address space instead of the whole?

Thanks in advance, Patrick

User avatar
Support Team
Hero Member
Hero Member
Posts: 3064
Joined: 18 Mar 2011, 15:09

Re: Client access control

Post by Support Team »

Hi Patrick,

Views are server provided subsets of the server address space for browse. But a client must pass in the View ID as browse filter to just get the nodes back in browse which are contained in the View. Therefore Views are not the right thing for what you want to do.

For all OPC UA service invocations (browse, read, write, call, monitoring), the server known the session context and therefore it knows the software connected (ProductUri), the application instance connected (Application URI + OPC UA application instance certificate) and the user connected (user+password or certificate or any other supported token type). The application instance and user can be verified cryptographically. For ProductUris it would be easy to fake them.

Based on this information, the server can decide if he makes nodes visible (browse), allows access to attributes (read, monitoring), allows update of attributes (write) or allows Method invocation.

The level of built-in support for this depends on the SDK and version. The built-in support is normally based on user tokens and user groups but it should be easy to assign the right group during session creation based on the user and the application information.

Best Regards,
Unified Automation Support Team

pfp.meijers
Sr. Member
Sr. Member
Posts: 13
Joined: 02 Oct 2014, 09:08

Re: Client access control

Post by pfp.meijers »

So application URIs represent the clients and thus what I would need to do is manage which nodes are allowed to be accessed for each application URI.
In order to simplify this, and instead of defining access rules for each inidvidual node, why can't I do this by grouping nodes into views.
So consider each view as an interface and specifying somehow which application URIs are allowed to access which views.

(Views can they be overlapping? Are they supported in UaModeller? I see a views folder but could not figure out how to add node refereces to it.)

By the way, I do not want the server to know/define all its clients at development-time, i.e. expicitly speccify which are allowed to access which views. This is to be managed by system level config.

Grt, Patrick

User avatar
Support Team
Hero Member
Hero Member
Posts: 3064
Joined: 18 Mar 2011, 15:09

Re: Client access control

Post by Support Team »

Hi Patrick,

Views will not help you. A view only affects browse and a client controls which view he is browsing. All other services like Read, Write, Call are not affected by a view. Therefore a view cannot be used to limit access for a client or user.

You can group nodes somehow internally but you must limit access for all relevant services, not only for browse.

The common way is to control access through configuration and not at compile time.

Best Regards,
Unified Automation Support Team

pfp.meijers
Sr. Member
Sr. Member
Posts: 13
Joined: 02 Oct 2014, 09:08

Re: Client access control

Post by pfp.meijers »

Ok, I understand.

But still I could use the view concept as the primary source for specifying client access:
As a sw architect I would like to specify e.g. that client C1 is allowed to access interface V1 (read all nodes from view 1) of server S. Client C2 can access V1 and V2.
In a text file specifying the "scope" of each client, something like:
C1: S/V1
C2: S/V1, S/V2
(but then using app, server and view node URIs)

The clients are in principle still capable of accessing any node - as you explained - but if the server will read this file at run-time (configuration) it can reject services for nodes outside the client's scope.

Is a search for a node within a container node (such as a view) facilitated by your SDK?

Grt, Patrick

PS:
- Never had these kind of questions about architectural dependency control before? For a large scale project with many developers and teams, this seems quite essential to avoid one big code monolith.
- I will move the question about view support in UaModeler to a different forum.

User avatar
Support Team
Hero Member
Hero Member
Posts: 3064
Joined: 18 Mar 2011, 15:09

Re: Client access control

Post by Support Team »

Hi,

It is common to restrict user or application access in servers but this is done based on access masks configured on nodes, not based on Views.

Again: A View is a starting point for browsing and a filter in Browse, nothing else. Views are unknown to any of thee other Services and there is also no way to assign a View to a certain application. There is nothing in OPC UA that can be used to link a View to a client Session.

There is no generic OPC UA way to define if a node is part of a view. This is application specific knowledge. Therefore there is no support in the SDK for views. If you want to use and implement views, you must implement the NodeManager interface directly or overwrite NodeManager::browse to check if a view filter is passed to Browse.

Best Regards,
Unified Automation Support Team

pfp.meijers
Sr. Member
Sr. Member
Posts: 13
Joined: 02 Oct 2014, 09:08

Re: Client access control

Post by pfp.meijers »

There is no generic OPC UA way to define if a node is part of a view.
This I do not understand. View nodes contain references (of type Organizes) to other nodes which are thereby defined to be part of that view, if I read the OPC UA spec correctly.
there is also no way to assign a View to a certain application.
There is always a way ;-) But I understand that this is not standard SDK/server functionality.

Another approach would be to generate client side interface files per view (header files in case of c/c++) with only the node ID constants for the nodes that are part of that view.
If we then have a mechanism to restrict client code to use specific interfaces (headers), then we have design-time access control, (assumed that client does not use node IDs from dynamic introspection/browsing, or hardcoded inline magic number IDs).

Grt, Patrick

User avatar
Support Team
Hero Member
Hero Member
Posts: 3064
Joined: 18 Mar 2011, 15:09

Re: Client access control

Post by Support Team »

If you have a closed system where you have full control over client and server side you can of course move that logic to the client side.

If you want to control access to certain nodes and/or operations, the generic way to do it is restricting access on the server side by setting access permissions for the nodes as part of the server configuration.

Best Regards,
Unified Automation Support Team

pfp.meijers
Sr. Member
Sr. Member
Posts: 13
Joined: 02 Oct 2014, 09:08

Re: Client access control

Post by pfp.meijers »

We have a closed system, though also have to deal with some off-the-shelf servers.
Access permissions on nodes are not coupled to specific clients to my understanding.
What we need to arrange is a mechanism to specify access contol per client (typically not at the level of each single node, but on a group of nodes).
This allows us to manage dependencies between different SW modules (client or server).

Grt, Patrick

Post Reply