docs(m4.2): reconcile InboundAPI (Bearer/audit-timing/type-validation), Security (cookie session, role names), Notification (Email-only, AuditKind vocab) to code
This commit is contained in:
@@ -13,7 +13,7 @@ Central cluster. Sites do not have user-facing interfaces and do not perform ind
|
||||
- Authenticate users against LDAP/Active Directory using a direct LDAP/AD bind (username/password).
|
||||
- Map LDAP group memberships to system roles.
|
||||
- Enforce role-based access control on all API and UI operations.
|
||||
- Support site-scoped permissions for the Deployment role.
|
||||
- Support site-scoped permissions for the Deployer role.
|
||||
|
||||
## Authentication
|
||||
|
||||
@@ -39,7 +39,7 @@ Set in a local or docker-dev environment via the environment variable `ScadaBrid
|
||||
- The JWT is embedded in an **authentication cookie** rather than being passed as a bearer token. This is the correct transport for Blazor Server, where persistent SignalR circuits do not carry Authorization headers — the browser automatically sends the cookie with every SignalR connection and HTTP request.
|
||||
- The cookie is **HttpOnly** and **Secure** (requires HTTPS).
|
||||
- On each request, the server extracts and validates the JWT from the cookie. All authorization decisions are made from the JWT claims without hitting the database.
|
||||
- **JWT claims**: User display name, username, list of roles (Admin, Design, Deployment), and for site-scoped Deployment, the list of permitted site IDs.
|
||||
- **JWT claims**: User display name, username, list of roles (`Administrator`, `Designer`, `Deployer`, `Viewer`), and for site-scoped Deployer, the list of permitted site IDs.
|
||||
|
||||
### Token Lifecycle
|
||||
|
||||
@@ -80,7 +80,7 @@ Set in a local or docker-dev environment via the environment variable `ScadaBrid
|
||||
|
||||
## Roles
|
||||
|
||||
### Admin
|
||||
### Administrator
|
||||
- **Scope**: System-wide (always).
|
||||
- **Permissions**:
|
||||
- Manage site definitions.
|
||||
@@ -89,9 +89,9 @@ Set in a local or docker-dev environment via the environment variable `ScadaBrid
|
||||
- Manage LDAP group-to-role mappings.
|
||||
- Manage API keys (create, enable/disable, delete).
|
||||
- System-level configuration.
|
||||
- View audit logs.
|
||||
- View and export audit logs.
|
||||
|
||||
### Design
|
||||
### Designer
|
||||
- **Scope**: System-wide (always).
|
||||
- **Permissions**:
|
||||
- Create, edit, delete templates (including attributes, alarms, scripts).
|
||||
@@ -102,7 +102,7 @@ Set in a local or docker-dev environment via the environment variable `ScadaBrid
|
||||
- Manage inbound API method definitions.
|
||||
- Run on-demand validation (template flattening, script compilation).
|
||||
|
||||
### Deployment
|
||||
### Deployer
|
||||
- **Scope**: System-wide or site-scoped.
|
||||
- **Permissions**:
|
||||
- Create and manage instances (overrides, connection bindings, area assignment).
|
||||
@@ -114,25 +114,32 @@ Set in a local or docker-dev environment via the environment variable `ScadaBrid
|
||||
- Manage parked messages.
|
||||
- Monitor and manage the Notification Outbox (retry and discard parked notifications).
|
||||
- View site event logs.
|
||||
- **Site scoping**: A user with site-scoped Deployment role can only perform these actions for instances at their permitted sites.
|
||||
- **Site scoping**: A user with site-scoped Deployer role can only perform these actions for instances at their permitted sites.
|
||||
|
||||
### Viewer
|
||||
- **Scope**: System-wide (always).
|
||||
- **Permissions**:
|
||||
- Read-only access to operational audit data (Audit Log, Notifications, Site Calls).
|
||||
- Navigation to audit pages.
|
||||
- Does not grant export or any mutating action.
|
||||
|
||||
## Multi-Role Support
|
||||
|
||||
- A user can hold **multiple roles simultaneously** by being a member of multiple LDAP groups.
|
||||
- Roles are **independent** — there is no implied hierarchy between roles.
|
||||
- For example, a user who is a member of both `SCADA-Designers` and `SCADA-Deploy-All` holds both the Design and Deployment roles, allowing them to author templates and also deploy configurations.
|
||||
- For example, a user who is a member of both `SCADA-Designers` and `SCADA-Deploy-All` holds both the Designer and Deployer roles, allowing them to author templates and also deploy configurations.
|
||||
|
||||
## LDAP Group Mapping
|
||||
|
||||
- System administrators configure mappings between LDAP groups and roles.
|
||||
- Examples:
|
||||
- `SCADA-Admins` → Admin role
|
||||
- `SCADA-Designers` → Design role
|
||||
- `SCADA-Deploy-All` → Deployment role (all sites)
|
||||
- `SCADA-Deploy-SiteA` → Deployment role (Site A only)
|
||||
- `SCADA-Deploy-SiteB` → Deployment role (Site B only)
|
||||
- `SCADA-Admins` → Administrator role
|
||||
- `SCADA-Designers` → Designer role
|
||||
- `SCADA-Deploy-All` → Deployer role (all sites)
|
||||
- `SCADA-Deploy-SiteA` → Deployer role (Site A only)
|
||||
- `SCADA-Deploy-SiteB` → Deployer role (Site B only)
|
||||
- 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 (Admin role).
|
||||
- Group mappings are stored in the configuration database and managed via the Central UI (Administrator role).
|
||||
|
||||
## Permission Enforcement
|
||||
|
||||
@@ -149,8 +156,8 @@ Set in a local or docker-dev environment via the environment variable `ScadaBrid
|
||||
## Interactions
|
||||
|
||||
- **Central UI**: All UI requests pass through authentication and authorization.
|
||||
- **Template Engine**: Design role enforcement.
|
||||
- **Deployment Manager**: Deployment role enforcement with site scoping.
|
||||
- **Template Engine**: Designer role enforcement.
|
||||
- **Deployment Manager**: Deployer role enforcement with site scoping.
|
||||
- **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.
|
||||
|
||||
Reference in New Issue
Block a user