dohertj2/lmxopcua
1
0
Fork 0
Code Issues 2 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs(security): fix data-plane alarm-ack GroupToRole value (AlarmAck, not AlarmAcknowledge)

Browse Source 
The gate reads the literal role string OpcUaDataPlaneRoles.AlarmAck = "AlarmAck"
(OtOpcUaNodeManager.cs:643), but the Role-grant-source section told operators to map
their alarm-ack group to "AlarmAcknowledge" (the PermissionFlags ACL bit, a different
vocabulary) — which silently never satisfies the ack gate. Fix the three role-string
occurrences + add a code-true note; generalize the scripted-alarm note to native alarms.
This commit is contained in:
Joseph Doherty
2026-06-15 00:42:32 -04:00
parent d19deb9b42
commit 063d004fda
1 changed files with 11 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/security.md
+11 -4
View File
@@ -160,7 +160,7 @@ LDAP is configured under the `Security:Ldap` section (bound to `LdapOptions`, `s
}
```
`GroupToRole` maps LDAP group names → roles (case-insensitive); a user gets every role whose source group is in their membership. The values are the canonical control-plane role strings (`Viewer` / `Designer` / `Administrator`, plus the appsettings-only `Operator` for the `DriverOperator` policy); the same map also supplies data-plane role strings (`ReadOnly`, `WriteOperate`, `WriteTune`, `WriteConfigure`, `AlarmAcknowledge`) — see [Role grant source (data-plane)](#role-grant-source-data-plane) below. `UserNameAttribute: "sAMAccountName"` is the critical AD override — the GLAuth dev default is `cn`, which is not how AD users are looked up; use `userPrincipalName` instead if operators log in with `user@corp.example.com` form. `LdapOptionsValidator` (`src/Server/ZB.MOM.WW.OtOpcUa.Host/Configuration/LdapOptionsValidator.cs`) fails startup when `Transport = None` and `AllowInsecure = false` on a real-LDAP (non-DevStub) config.
`GroupToRole` maps LDAP group names → roles (case-insensitive); a user gets every role whose source group is in their membership. The values are the canonical control-plane role strings (`Viewer` / `Designer` / `Administrator`, plus the appsettings-only `Operator` for the `DriverOperator` policy); the same map also supplies data-plane role strings (`ReadOnly`, `WriteOperate`, `WriteTune`, `WriteConfigure`, `AlarmAck`) — see [Role grant source (data-plane)](#role-grant-source-data-plane) below. `UserNameAttribute: "sAMAccountName"` is the critical AD override — the GLAuth dev default is `cn`, which is not how AD users are looked up; use `userPrincipalName` instead if operators log in with `user@corp.example.com` form. `LdapOptionsValidator` (`src/Server/ZB.MOM.WW.OtOpcUa.Host/Configuration/LdapOptionsValidator.cs`) fails startup when `Transport = None` and `AllowInsecure = false` on a real-LDAP (non-DevStub) config.
---
@@ -248,7 +248,7 @@ Data-plane roles come from `Security:Ldap:GroupToRole` (appsettings), **not** fr
`LdapGroupRoleMapping` table. That table's `Role` column is the `AdminRole` enum
(`Administrator`/`Designer`/`Viewer`) and supplies **control-plane** roles only — it cannot emit the
data-plane role strings the OPC UA gates read (`ReadOnly`, `WriteOperate`, `WriteTune`,
`WriteConfigure`, `AlarmAcknowledge`). A deployment therefore **must** map its data-plane LDAP groups
`WriteConfigure`, `AlarmAck`). A deployment therefore **must** map its data-plane LDAP groups
to those role strings via `GroupToRole`, e.g.:
```json
@@ -256,14 +256,21 @@ to those role strings via `GroupToRole`, e.g.:
"ot-operators": "WriteOperate",
"ot-tuners": "WriteTune",
"ot-engineers": "WriteConfigure",
"ot-alarm-ack": "AlarmAcknowledge",
"ot-alarm-ack": "AlarmAck",
"ot-readonly": "ReadOnly"
}
```
If this mapping is absent the data-plane evaluator is strictly default-deny: inbound operator writes
and OPC UA Part-9 alarm acknowledgement all return `BadUserAccessDenied` even for users who
authenticate successfully. (The same requirement gates the pre-existing scripted-alarm ack path.)
authenticate successfully. (The same requirement gates both the scripted-alarm and the native
Galaxy-alarm Part-9 ack/confirm/shelve paths.)
The role strings above are **exact, case-insensitive, and code-true** — the inbound gates compare
against the constants in `OpcUaDataPlaneRoles` (`AlarmAck`, `WriteOperate`) and the bare strings
`ReadOnly` / `WriteTune` / `WriteConfigure`. In particular the alarm-ack role is `AlarmAck`, **not**
`AlarmAcknowledge` (that spelling is the `PermissionFlags` ACL bit, a different vocabulary); a
`GroupToRole` value of `AlarmAcknowledge` silently never satisfies the ack gate.
---