When I was finishing my studies, I had to do what every student eventually does: pick a master’s thesis topic. Or in my case, mostly get one assigned. My colleagues at Prosys had been aware of OPC UA Role-Based Access Control being added to the specification, but none had the pleasure to take a closer look at what had been defined in the spec, and even less so, how it should be used or implemented in real industrial scenarios.
One thought that came from one of my colleagues was to reuse IT infrastructure, specifically directory services (such as LDAP and AD), on the OT side as well. This has several obvious benefits, like a single source of truth for role assignments and a low barrier to entry due to industry-standard systems. However, as with all OT environments, operational availability is key and must be ensured with such dependencies between OT and IT. This led me to investigate the feasibility of such a system architecture and to consider how to ensure that OT requirements are not compromised.
This post is the short, practical overview of what I looked at and what seems to matter the most.
The complete thesis is available in Tampere University’s Trepo archive.
OPC UA RBAC in Brief
OPC UA separates who you are (authentication) from what you’re allowed to do (authorization). With RBAC, permissions are attached to roles instead of individual users.
- Clients (users or applications) are mapped to one or more roles for the session.
- Roles define what’s allowed on nodes.
- The spec includes well-known roles (like Operator or Engineer) to give everyone a common starting point.
Two main approaches
- Directory integration (LDAP/AD). Existing IT directories can be reused so that user and group information is not duplicated. The risk is that if the directory is unreachable, the plant may lose access control definitions. To counter this, the thesis presented a case study with redundant LDAP servers in the OT network (DMZ), ensuring that operations continue even if the corporate IT link is down.
- Local mappings. Each server maintains its own identity-to-role mapping, along with role permissions. This avoids external dependencies and works even in isolated networks. The drawback is the extra maintenance work and the chance of inconsistencies between servers, especially in larger setups.
A simulated case study
Initially, I had planned to discuss with industry experts who have real-life setups to gather insight into what their OT access controls look like currently and to ask for their opinions on what they need or how different OT RBAC solutions could benefit them. Unfortunately, due to time constraints (and the fact that the scope of the work was getting out of hand), I couldn’t get in touch with the necessary people and thus lacked some practical examples of network architecture that I could use as a blueprint for my considerations. This led me to create a case study (as shown in the picture below) as an attempt to test different approaches for RBAC information persistence.
No silver bullets
- Directory integration makes sense when identities are already centralized and redundancy is available.
- Local mappings are straightforward and resilient for smaller or isolated plants.
- Orchestration might fit large or complex systems that need both coordination and local independence, however, the feasibility and robustness of such tooling is hard to determine as it doesn’t exist.
Final takeaways
Luukas Lusetti
Software Engineer
Email: luukas.lusetti@prosysopc.com