Skip to content

Roles and RBAC

Shoehorn uses role-based access control (RBAC) powered by Cerbos to manage permissions. Roles determine what users can see and do in the platform.

RoleDescription
tenant:adminFull access to everything in the tenant
tenant:viewerRead-only access to all resources
RolePermissions
Entity
entity:viewerView and list entities
entity:editorCreate and update entities
entity:adminDelete entities
Workflow
workflow:viewerView and list workflows
workflow:executorCreate, execute, cancel own runs, retry own runs
workflow:adminDelete workflows, cancel/retry any run
Mold (Template)
mold:viewerView and list molds
mold:editorCreate and update own molds
mold:publisherPublish molds
mold:adminDelete molds
Operations
operations:viewerView workloads and services
operations:operatorUpdate operations resources
operations:adminDelete operations resources
Admin
admin:viewerRead-only admin: view settings and analytics
admin:operatorManage users, integrations, dashboards
Marketplace
marketplace:viewerBrowse marketplace
marketplace:editorInstall and configure items

Higher roles include all permissions of lower roles:

entity:admin -> entity:editor -> entity:viewer
workflow:admin -> workflow:executor -> workflow:viewer
mold:admin -> mold:publisher -> mold:editor -> mold:viewer
tenant:admin -> all resource roles
  1. Navigate to Admin > Users
  2. Select a user
  3. Click Add Role
  4. Select the role
  5. Click Save
Terminal window
# Add a role to a user
curl -X POST https://shoehorn.example.com/api/v1/admin/users/<user-id>/roles \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{"role": "entity:editor"}'
# Remove a role from a user
curl -X DELETE https://shoehorn.example.com/api/v1/admin/users/<user-id>/roles \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{"role": "entity:editor"}'
Terminal window
curl https://shoehorn.example.com/api/v1/admin/roles \
-H "Authorization: Bearer <token>"

Returns all role assignments with user details.

Some operations are restricted by ownership:

  • Workflow cancel/retry: workflow:executor can only cancel or retry their own runs
  • Mold update: mold:editor can only update molds they created
  • workflow:admin and mold:admin can operate on any resource
  1. User authenticates (OIDC session or API key)
  2. Middleware extracts user roles from the database
  3. For each request, Cerbos evaluates:
    • User’s roles
    • Target resource type and ID
    • Requested action
    • Tenant isolation (user’s tenant must match resource’s tenant)
  4. Access is granted or denied

API keys use scope-based authorization instead of roles. See API Keys.

If a user has no roles assigned, all requests return 403 Forbidden. There are no implicit permissions.

There is no audit-log view in the UI yet. If you need an audit trail, enable pgaudit on the platform’s Postgres and query it directly. Role assignments and removals run through the same SQL writes pgaudit captures: who, when, what changed.

A UI surface for this is on the roadmap.