Joseph Doherty
5e9cbd3ecf
Packing Secrets 0.1.3 surfaced NU1903: Microsoft.Data.Sqlite 10.0.7 pulls SQLitePCLRaw.lib.e_sqlite3 2.1.11, which carries high-severity advisory GHSA-2m69-gcr7-jv3q. Auth.ApiKeys had the same exposure and was already shipped at 0.1.4 to three consumers, so both libs are fixed rather than only the one being published. Fixed the way ZB.MOM.WW.LocalDb already had it: CentralPackageTransitivePinningEnabled plus a pin to the patched 2.1.12. Bumping Microsoft.Data.Sqlite does not help -- even 10.0.10 still resolves 2.1.11 -- so the pin is the actual fix. The pin reaches consumers: both nuspecs now declare SQLitePCLRaw.lib.e_sqlite3 >= 2.1.12 as a direct dependency, verified by restoring the published packages into a scratch project, which resolves 2.1.12 and scans clean. Auth goes 0.1.4 -> 0.1.5 with no API change (0.1.4 plus the pin). Suites re-run after the native-lib swap with identical counts, so no behavioral regression: Secrets 97 pass/1 skip, Auth 215 pass/1 skip (both skips are Windows-only DPAPI and opt-in LDAP). Consumers are NOT yet bumped and remain on vulnerable versions: mxaccessgw 0.1.4, HistorianGateway 0.1.4, ScadaBridge 0.1.3. Secrets consumers all sit at 0.1.2 and also lack KEK rotation. Claude-Session: https://claude.ai/code/session_01BL2Vu1ESDQ9SCN4gVKkdts
Auth (login / identity / authorization)
First normalized component. Goal: path to shared code — converge the three sister
projects onto a common identity + API-key contract, proposed as the ZB.MOM.WW.Auth
library set, while each project keeps its own authorization vocabulary.
- The one target:
spec/SPEC.md - The proposed shared library:
shared-contract/ZB.MOM.WW.Auth.md - Divergences + backlog:
GAPS.md - Current state, per project:
current-state/
Why auth is a strong first candidate
All three projects authenticate humans via LDAP (GLAuth in dev), do bind-then-search,
read groups from memberOf, use a service account, support TLS/StartTLS with an
AllowInsecureLdap dev escape hatch, and never log secrets. Two of three implement an
almost identical peppered HMAC-SHA256 API-key scheme with constant-time comparison. That
common core is re-implemented per repo and has already drifted (config key names, dev base DN,
cookie names). Authorization, by contrast, is genuinely domain-specific and is not unified.
Status by project
| Project | AuthN today | Machine auth | AuthZ model (stays per-project) | Sessions | Adoption status |
|---|---|---|---|---|---|
| OtOpcUa | LDAP (GLAuth) via OPC UA UserName token; X.509 + anonymous also | — (OPC UA transport security) | NodePermissions bitmask (data-plane ACL trie) + AdminRole (control-plane) |
Per-session UserAuthorizationState, 5-min freshness / 15-min staleness, generation-bound |
Not started |
| MxAccessGateway | LDAP (GLAuth) for dashboard | API keys (mxgw_…, SQLite, peppered HMAC, scopes + constraints) |
gRPC scopes (session:*/invoke:*/events:*/metadata:*/admin) + dashboard Admin/Viewer |
Dashboard cookie (8h sliding) + 30-min Data-Protection hub bearer | Not started |
| ScadaBridge | LDAP for UI/CLI/Management API (Basic→LDAP) | API keys (X-API-Key, peppered HMAC, per-method approval) — Inbound API only |
Roles Admin/Design/Deployment/Audit/AuditReadOnly + site-scoping |
Cookie (…ScadaBridge.Auth, 30-min idle) + 15-min refresh JWT for programmatic |
Not started |
See each project's current-state/<project>/CURRENT-STATE.md for the
code-verified detail and its adoption plan.
Normalized vs. left per-project
Normalized (the shared target): LDAP/identity config schema + canonical key names;
bind-then-search behavior incl. DN/filter escaping and timeouts; a generic group→role
mapping seam; the standardized canonical role set every project maps onto
(spec/CANONICAL-ROLES.md); the API-key contract (token format,
peppered HMAC-SHA256, constant-time compare, audit); cookie/claim conventions; dev-bypass
flag conventions; secret handling.
Left per-project (native enforcement, mapped onto the canonical roles): the authorization
enforcement vocabularies (NodePermissions / gRPC scopes / app roles + site-scoping), OPC UA
transport security, OtOpcUa's generation/staleness session model, ScadaBridge's site-scope rules.