User accounts and roles

When a server has OPCUA_AUTH_USERS=true, it validates username/password credentials against config/users.json. The suite ships four canned accounts covering the three role tiers plus a convenience admin.

The four accounts

Plaintext passwords are intentional — this is a test suite, not a real auth system. Don't mirror this config into a real deployment.

What each role implies

The role maps to a set of OPC UA role identifiers (per the spec's WellKnownRoles):

admin

AuthenticatedUser, ConfigureAdmin, SecurityAdmin, Operator, Engineer

• Read: every variable.
• Write: every writable variable, including AccessControl/AdminOnly and AccessControl/OperatorLevel.
• Method calls: all.
• History: full read.

operator

AuthenticatedUser, Operator

• Read: every variable.
• Write: AccessControl/OperatorLevel variables, regular _RW variables. Cannot write AccessControl/AdminOnly.
• Method calls: all (method-level role checks are not enforced).
• History: read.

viewer

AuthenticatedUser

• Read: every readable variable.
• Write: none. Any write returns Bad_UserAccessDenied.
• Method calls: yes (consistent with the spec — methods aren't role-gated in the test suite).
• History: read.

anonymous (no user)

• Read: variables marked anonymous-allowed.
• Write: depends on server.
• No role identifiers.

Which servers accept which auth

Test patterns

Happy path

Negative path — auth failure

The two failure codes are distinct — Bad_UserAccessDenied means "the credentials were of the right type but failed validation" (wrong password or unknown user), while Bad_IdentityTokenRejected means "the token type itself is not accepted on this endpoint" (Anonymous on a server with AllowAnonymous=false, or Certificate on a server with AuthCertificate=false). Asserting on the wrong code will hide bugs in either branch.

Negative path — role-based write rejection

Adding users (fork)

Edit config/users.json and restart the server:

[
  { "username": "admin",      "password": "admin123",      "role": "admin"    },
  { "username": "operator",   "password": "operator123",   "role": "operator" },
  { "username": "viewer",     "password": "viewer123",     "role": "viewer"   },
  { "username": "test",       "password": "test",          "role": "admin"    },
  { "username": "plc_svc",    "password": "s3cure!",       "role": "operator" }
]

docker compose restart opcua-userpass

The new user is now valid. UserManager only exposes GetRole(username) → string, IsAdmin, IsOperator and HasPermission(username, permission); there is no GetUserRoles() method. For role-aware write hooks beyond operator/admin, extend IsOperator/IsAdmin (or add a new helper) and the switch in AccessControlBuilder.CreateRoleProtectedVariable. See Customization.

Where to read next

• Certificate authentication — the cert-based identity flow.
• Data features · Access control — the 50 access-control variables that exercise these roles.