Roles & Permissions
Minimal follows a Linux-style user and group model for access control. Roles are not managed by Minimal — they are managed entirely by your existing auth system and passed to Minimal as headers on every request.
Minimal operates in a trusted subsystem model. It does not authenticate users, issue tokens, validate sessions, or maintain a user database. It fully trusts the headers your gateway injects and acts on them directly.
Trusted Subsystem Model
Your Auth System → validates the user, assigns roles
Your Gateway → injects identity headers
Minimal → trusts the headers, enforces role check
Minimal sits behind your gateway and never sees the original token or credential. Your gateway is the trust boundary — Minimal assumes everything it receives has already been authenticated.
You already have an auth system. Minimal does not force you to migrate to a new one, learn a new permission model, or duplicate user management. Bring your own auth — Minimal works with whatever you have.
Scope
Every request to the Auto API is scoped across six dimensions — all passed as headers:
Organization (X-Org-Id)
└── Project (X-Project-Id)
└── Space (X-Space-Id)
└── User (X-User-Id)
└── Role (X-User-Roles)
| Header | Example | Description |
|---|---|---|
X-Org-Id | 01KG1G4H4FNHRP7HQRHDGEYAC9 | Which organization this request belongs to |
X-Project-Id | 01KHR34M1XTX0CH43MASDG9ZC8 | Which project (database config) to use |
X-Space-Id | 01KBY3K8RQ9GS1VD9XYXHZ92QT | Which workspace within the project |
X-User-Id | 01KBY3K9NDC5XW523M2V1Z0373 | The authenticated user making the request |
X-User-Roles | admin, users | Comma-separated roles assigned to the user |
All five are mandatory on every Auto API request. Missing any one returns 400 Bad Request.
Roles
Minimal recognises two roles out of the box:
| Role | Access |
|---|---|
admin | |
users |
Roles are configured in config.yml under auto_api.roles:
auto_api:
roles: [admin, users]
Only roles listed here are permitted. Any request carrying a role not in this list is rejected with 403 Forbidden.
admin and users are defaults — rename them to match your existing auth system.
Whatever names you configure in auto_api.roles must match exactly what your gateway sends in X-User-Roles.
Multiple Roles Per User
A user can carry more than one role — pass them comma-separated:
X-User-Roles: admin, users
Minimal grants the highest privilege among all roles provided.
Your Responsibilities
Minimal does not manage any of the following — these are entirely owned by your auth system and gateway:
- User identities and accounts
- Role assignment per user
- Which users can access which org, project, or space
- Token issuance and validation
- Session management
- Validate the incoming user token — JWT, session cookie, API key, whatever your system uses
- Resolve the user's org, project, space, and roles
- Inject all five headers before forwarding to Minimal
- Never forward unauthenticated requests to Minimal
Minimal only ever sees the injected headers — it never sees the original credential.
Example — Admin privilege
curl 'https://your-domain.com/minimal/api/rest/auto/v1/ms/demo_db/users?pg=0&ps=10' \
--header 'X-Org-Id: 01KG1G4H4FNHRP7HQRHDGEYAC9' \
--header 'X-Project-Id: 01KHR34M1XTX0CH43MASDG9ZC8' \
--header 'X-Space-Id: 01KBY3K8RQ9GS1VD9XYXHZ92QT' \
--header 'X-User-Id: 01KBY3K9NDC5XW523M2V1Z0373' \
--header 'X-User-Roles: admin'
Full access — GET, POST, PUT, DELETE all permitted.
Common Errors
| Code | Cause | Fix |
|---|---|---|
400 Bad Request | One or more of the five required headers are missing | Ensure your gateway injects all five headers on every request |
401 Unauthorized | X-User-Id is missing | Always pass X-User-Id — Minimal requires it on every request |
403 Forbidden | Role not permitted for this HTTP method | Check X-User-Roles matches a role in auto_api.roles and has permission for the operation |