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

docs(m7): reflect OPC UA / MxGateway UX (T13-T17) across component docs + CLAUDE/stillpending/completion-design

Browse Source
This commit is contained in:
Joseph Doherty
2026-06-18 04:13:21 -04:00
parent 39afa2743e
commit 40928535fd
11 changed files with 158 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/requirements/Component-Security.md
+31
View File
@@ -123,6 +123,34 @@ Set in a local or docker-dev environment via the environment variable `ScadaBrid
- Navigation to audit pages.
- Does not grant export or any mutating action.
### Operator
- **Scope**: System-wide (always).
- **Permissions**:
- Submit a **secured write** to an MxAccess Gateway connection from the Central UI Secured Writes page (`/operations/secured-writes`) — the *initiating* half of the two-person write workflow.
- **Purpose**: One of the two distinct global roles backing MxGateway secured writes. An Operator initiates a write; it never executes until a separate **Verifier** approves it. Holding Operator alone never executes a write.
### Verifier
- **Scope**: System-wide (always).
- **Permissions**:
- Approve or reject a pending secured write from the Secured Writes page — the *approving* half of the two-person write workflow.
- **Purpose**: The approving counterpart to **Operator**. Separation of duties is enforced **server-side**: the ManagementActor rejects any approval where the approving user equals the submitting Operator (no self-approval), so the two roles must be held by distinct principals for a write to execute. (See Component-ManagementService.md and Component-CentralUI.md.)
> **Two-person secured-write workflow.** `Operator` and `Verifier` are deliberately separate global roles so a single principal cannot both initiate and approve a write through the MxAccess Gateway. Both are coarse global roles like the others; any site scoping is layered on at the LDAP-mapping level. Note the dev `DisableLogin` caveat: with `DisableLogin` on, the auto-login principal holds **all** roles, so the two-person flow cannot be exercised end-to-end by a single identity — no-self-approval is covered by handler tests and real two-person use requires two real identities.
## Authorization Policies
Role checks are expressed as named ASP.NET Core authorization policies (in `AuthorizationPolicies`), each requiring the matching role claim:
| Policy | Role required | Used by |
|--------|---------------|---------|
| `RequireAdmin` | Administrator | Site/data-connection management, API keys, LDAP mappings, bundle import, server-certificate trust/remove |
| `RequireDesign` | Designer | Template authoring, shared scripts, external/DB definitions, notification lists, bundle export |
| `RequireDeployment` | Deployer | Instance/deployment management, debug view, parked messages, Notification Outbox, Alarm Summary |
| `RequireOperator` | Operator | Submit a secured write (Secured Writes page) |
| `RequireVerifier` | Verifier | Approve/reject a pending secured write |
`RequireOperator` and `RequireVerifier` were added with the two-person secured-write feature (M7); the rest predate it.
## Multi-Role Support
- A user can hold **multiple roles simultaneously** by being a member of multiple LDAP groups.
@@ -138,6 +166,8 @@ Set in a local or docker-dev environment via the environment variable `ScadaBrid
- `SCADA-Deploy-All` → Deployer role (all sites)
- `SCADA-Deploy-SiteA` → Deployer role (Site A only)
- `SCADA-Deploy-SiteB` → Deployer role (Site B only)
- `SCADA-Operators` → Operator role (initiates secured writes)
- `SCADA-Verifiers` → Verifier role (approves secured writes)
- A user can be a member of multiple groups, granting multiple independent roles.
- Group mappings are stored in the configuration database and managed via the Central UI (Administrator role).
@@ -158,6 +188,7 @@ Set in a local or docker-dev environment via the environment variable `ScadaBrid
- **Central UI**: All UI requests pass through authentication and authorization.
- **Template Engine**: Designer role enforcement.
- **Deployment Manager**: Deployer role enforcement with site scoping.
- **Management Service / Central UI (secured writes)**: `RequireOperator` gates submission and `RequireVerifier` gates approval/rejection of MxGateway secured writes; the no-self-approval rule (Operator ≠ Verifier) is enforced server-side by the ManagementActor, not just in the UI.
- **All central components**: Role checks are a cross-cutting concern applied at the API layer.
- **Management Service**: The ManagementActor enforces role-based authorization on every incoming command using the authenticated user identity carried in the message envelope. The CLI authenticates users via the same LDAP bind mechanism and passes the user's identity (username, roles, permitted sites) in every request message. The ManagementActor applies the same role and site-scoping rules as the Central UI — no separate authentication path exists on the server side.
- **Transport (#24)**: Provides the `RequireDesign` policy (export) and `RequireAdmin` policy (import) enforced at both the Razor page layer and inside the `ZB.MOM.WW.ScadaBridge.Transport` service entrypoints.