Skip to main content

Permissions model

Chrono One uses a hybrid permissions model.

Global roles​

Managed centrally by the shell backend and resolved on login (cached in Redis for 5 minutes, invalidated on assignment/revocation). They gate shell-level actions — e.g. only admin users can assign or revoke roles.

Examples: admin, viewer, product-a-manager, product-b-manager.

Product-specific permissions​

Each microfrontend's backend is the authority on what its permissions mean. The shell stores the raw grants (product_id, permission_key per user) but does not interpret them. A microfrontend fetches its own grants and enforces them internally:

MFE boots
  → GET /permissions/product-a (with ID token)
  → Shell API returns ['reports:read', 'settings:write']
  → MFE renders/hides its UI accordingly

API guardrails​

  • All routes except /health and /metrics require a valid Firebase ID token.
  • POST /roles/assign, DELETE /roles/:uid/:role, and product-permission grant/revoke routes require the admin global role.
  • Role and permission changes are written asynchronously to the audit log via BullMQ.