simonvetter
commented
3 years ago I went and dug the relevant roles/AuthZ requirements from the spec since it's been a while:
R-22: The Role in the x.509v3 certificate MUST use ASN1:UTF8String encoding.
R-65: There MUST only be one role defined per certificate. The entire string will be treated as one role.
R-23: If no Role is specified in the X.509v3 certificate, the mbaps server MUST provide a NULL role to the AuthZ algorithm.
R-24: The mbaps AuthZ Algorithm MUST be defined and provided by the device vendor.
R-27: The Roles-to-Rights Rules Database for a particular application MUST be configurable by the end user.
R-28: The Roles-to-Rights Rules Database for a particular application MUST NOT have hardcoded default roles that are unchangeable.So you can only have one role per client cert (R-65), that role is encoded as an UTF-8 string (R-22) and that string must be treated as one single role (R-65).
It is up to the manufacturer of the server device to build a role-based authorization system (R-24), users have to be able to change the list of allowed roles and their authorizations (R-27), including any default roles installed during the manufacturing process (R-28).
To me, this sounds like roles are opaque strings from the TLS and modbus subsystems point of view and you should feel free to use anything you like. The spec definitely doesn't say anything wrt role names or what "standard" roles should be.
guest, operator, admin, technician, etc. are popular roles in the control systems industry because they're explicit to non-technical users and are easy to reason about when assigning rights to roles (e.g. in an air conditioning control system, guests would only be able to view the system state, operators would be able to define schedules and change temperature setpoints, and technicians would have access to additional configuration parameters like evaporator pressure setpoints, protection controls, safety limits, etc.).
Coming back to your example, using ro/rw as roles to gate write requests is definitely compliant with the spec and is fairly easy to understand to a technical audience.
That said, I would opt for using function names (as in my aircon example above) as roles if possible, since that's what most people are used to reason about and they're usually more descriptive.
As for the MIB, there aren't any other OID defined outside of the modbus role afaik.
wz2b
Are the roles "operator" and "user" specified by modbus.org or is it only important that the server and clients agree on how to interpret the string? The spec gives an example:
which has a capital O. Your examples include "operator" and "operator2" which helped me understand how this works (thank you) but I'm wondering if there is any agreed-upon standard for these roles and what they mean. For example, could I just choose roles of "ro" and "rw", tell 3rd parties to generate their certs accordingly, and not be in violation of any standard conventions?
I'm also wondering if modbus.org publishes a proprietary mib for .50316 somewhere (and what else is in it).