Fine-grained RBAC per service (DataEditor vs ReadOnly)

[mikemcdougall]

Context

Write endpoints are currently gated by coarse auth (admin or any authenticated user). We need fine-grained RBAC so that users can be read-only or data-editor on a per-service basis. This aligns with the Roadmap item for layer-level RBAC.

Goal

Add service-scoped RBAC for write operations so that:

• Read endpoints remain accessible per current auth rules.
• Write endpoints require a DataEditor role/claim scoped to the target service.
• Admin role continues to override.

Scope

Protocols/endpoints that must enforce DataEditor:

• FeatureServer: applyEdits, add/update/delete attachment
• OGC API Features: transactions (POST/PUT/DELETE items)
• OData: CRUD + $batch

Non-goals:

• Admin endpoints (stay admin-only)
• UI for role management

Proposed Approach (candidate)

• Add a custom authorization requirement/handler that:
  • Extracts serviceId (and optionally layerId) from route
  • Checks claims for data-editor access scoped to that service
  • Allows admin role to bypass
• Introduce config to map claim types/role patterns, e.g.:
  • Rbac:RoleClaimType
  • Rbac:DataEditorRoles (list)
  • Rbac:DataEditorServicePrefix (e.g., data-editor: to support data-editor:serviceA)
• Add endpoint helpers like RequireDataEditorAuthorization() and apply to write endpoints
• Add integration tests for allow/deny behavior per service
• Update docs/troubleshooting for role claims and examples

Acceptance Criteria

• A user with read-only role for service X cannot write to service X (403).
• A user with data-editor role for service X can write to service X but not service Y (403).
• Admin role can write across services.
• All relevant write endpoints enforce the new policy.
• Docs and tests updated.

References

• docs/ROADMAP.md ("Security: Layer-level RBAC")