Authorization Matrix
This document defines the initial authorization matrix for WildEditorInChief (WEIC).
The authorization matrix makes the identity and review models operational by mapping roles to concrete actions. This helps prevent authorization drift and gives both backend and client development a shared understanding of what each role may do.
The model assumes centralized authentication through Keycloak and authorization decisions enforced by the WEIC API layer.
Purpose
The authorization matrix exists to support several goals:
- make role expectations explicit
- define who may perform which WEIC actions
- prevent ad hoc authorization growth
- align API behavior with governance requirements
- support future auditability and security review
This matrix is an initial model and can be refined as implementation grows.
Roles
The current conceptual roles are:
- reader
- editor
- reviewer
- publisher
- administrator
In simpler deployments some roles may overlap operationally, but they should remain distinct in the model.
Authorization principles
The matrix follows several principles.
Least privilege
Each role should receive only the permissions it needs.
Explicit governance boundaries
Review and publication permissions should not be silently merged into general editing unless intentionally configured.
Read and write are distinct
Reading content is not equivalent to editing or governing content.
Service enforcement
Authorization is enforced in the WEIC API, not assumed by clients.
Action categories
Actions are grouped into several categories:
- document read
- document metadata write
- document content revision
- fragment read
- fragment metadata write
- fragment content revision
- tagging
- review
- publication
- administration
Matrix
| Action | Reader | Editor | Reviewer | Publisher | Administrator |
|---|---|---|---|---|---|
| List documents | Yes | Yes | Yes | Yes | Yes |
| Get document | Yes | Yes | Yes | Yes | Yes |
| Create document | No | Yes | No | No | Yes |
| Update document metadata | No | Yes | No | No | Yes |
| List document revisions | Yes | Yes | Yes | Yes | Yes |
| Get specific document revision | Yes | Yes | Yes | Yes | Yes |
| Create document revision | No | Yes | No | No | Yes |
| List fragments | Yes | Yes | Yes | Yes | Yes |
| Get fragment | Yes | Yes | Yes | Yes | Yes |
| Create fragment | No | Yes | No | No | Yes |
| Update fragment metadata | No | Yes | No | No | Yes |
| List fragment revisions | Yes | Yes | Yes | Yes | Yes |
| Get specific fragment revision | Yes | Yes | Yes | Yes | Yes |
| Create fragment revision | No | Yes | No | No | Yes |
| List tags | Yes | Yes | Yes | Yes | Yes |
| Create tag | No | Yes | No | No | Yes |
| Attach tag to document | No | Yes | No | No | Yes |
| Remove tag from document | No | Yes | No | No | Yes |
| Create review decision | No | No | Yes | No | Yes |
| View review records | Yes | Yes | Yes | Yes | Yes |
| Publish approved revision | No | No | No | Yes | Yes |
| View publication records | Yes | Yes | Yes | Yes | Yes |
| Administrative configuration | No | No | No | No | Yes |
Interpretation notes
Reader
A reader has read-only access to WEIC content and history.
Typical abilities:
- list and retrieve documents
- list and retrieve fragments
- view revisions
- view review and publication records where readable
A reader cannot author, review, or publish.
Editor
An editor may author and maintain content.
Typical abilities:
- create documents and fragments
- update metadata
- create revisions
- manage tags
An editor cannot approve content or publish governed content unless also granted those roles.
Reviewer
A reviewer may record review decisions.
Typical abilities:
- read content and revisions
- approve or reject revision submissions
- enter review notes
A reviewer is not automatically a publisher.
Publisher
A publisher may expose approved content as published state.
Typical abilities:
- publish a revision
- view publication history
A publisher is not automatically a content editor unless explicitly granted that role too.
Administrator
An administrator may perform all actions and broader system management activities.
This role should be tightly controlled and used sparingly.
Endpoint mapping examples
The matrix can also be understood in endpoint terms.
Reader endpoints
Allowed examples:
GET /api/documents
GET /api/documents/{id}
GET /api/documents/{id}/revisions
GET /api/fragments
GET /api/fragments/{id}
GET /api/tags
Editor endpoints
Allowed examples:
POST /api/documents
PATCH /api/documents/{id}
POST /api/documents/{id}/revisions
POST /api/fragments
PATCH /api/fragments/{id}
POST /api/fragments/{id}/revisions
POST /api/tags
POST /api/documents/{id}/tags
DELETE /api/documents/{id}/tags/{tagId}
Reviewer endpoints
Allowed examples:
POST /api/documents/{id}/revisions/{revisionId}/reviews
POST /api/fragments/{id}/revisions/{revisionId}/reviews
Publisher endpoints
Allowed examples:
POST /api/documents/{id}/revisions/{revisionId}/publish
POST /api/fragments/{id}/revisions/{revisionId}/publish
Role combinations
In real deployments a user may hold more than one role.
Examples:
- editor + reviewer
- reviewer + publisher
- editor + reviewer + publisher
- administrator
The authorization model should evaluate the union of granted permissions while still enforcing explicit endpoint checks.
Governance implications
The separation between editor, reviewer, and publisher is important for governance.
This supports:
- separation of duties where required
- clearer approval flow
- traceable publication actions
- reduced risk of uncontrolled knowledge changes
Smaller environments may combine these roles operationally, but the underlying model should preserve the distinction.
Service account implications
Service accounts should not automatically receive broad human-style permissions.
Where service accounts interact with WEIC, they should receive only the minimum required capabilities for their workflow.
Examples:
- read-only content retrieval
- controlled document import
- limited publication or synchronization actions
Service account permissions should be explicit.
Future refinements
The matrix can later be expanded to support:
- document-level ownership checks
- scoped administrative roles
- environment-specific publication rights
- approval separation rules
- finer-grained permissions for workflow integrations
The initial matrix should remain understandable and enforceable.
Relationship to the Oryvin plan
The authorization matrix makes the identity model concrete at the WEIC service boundary.
authenticated identity
↓
role evaluation
↓
allowed WEIC action
↓
traceable governed knowledge change
This is one of the controls that turns WEIC from a simple editor into a governed knowledge platform.