Pluggable authorization layer — user RBAC is too coarse for multi-tenant/delegation scenarios

[joeblew999]

The current user model (Administrator/Editor/Author/Contributor) works for a single-site blog but won't scale to multi-tenant or permission-delegation use cases.

The plugin capability manifest system is well-designed for plugin authZ. The gap is in user/content authZ — e.g. "user A can edit posts in collection X but not Y", or "user A can delegate draft review to user B".

A Zanzibar-style tuple-based authZ model (subject, relation, object) maps cleanly onto D1 and would complement the existing session layer without replacing the authn design.

Proof of concept: zanzojs feat/better-auth-plugin

Question: is the authZ layer intended to be pluggable, or is the 4-role model a fixed design decision?

[ascorbic]

Moving this to a Discussion in Ideas -- per CONTRIBUTING.md, feature requests of this scope (RBAC redesign for multi-tenant) need a Discussion before any PR work, and Discussions are a better home for design conversations than the issue tracker.

[vikramrojo]

A concrete instance of this from the plugin side: every non-public route under /_emdash/api/plugins/{id}/... is hard-coded to plugins:read for GETs and plugins:manage for writes (packages/core/src/astro/routes/api/plugins/[pluginId]/[...path].ts), and adminPages inherit the same gate — so a plugin can't ship an author-tier surface inside the admin shell, e.g. a Stripe Connect screen where each AUTHOR saves their own acct_xxx, even though the plugin already knows the resource owner. The workarounds are to mark the route public: true and re-authenticate from scratch, or to move the surface off EmDash admin entirely, which fragments author UX. Two small additions would unlock most real cases without prejudging the Zanzibar question: a per-page/per-route minRole on the manifest, and an opt-in "plugin authorizes this itself" mode where the catch-all populates locals.user and runs CSRF but skips the plugins:* check, leaving role/ownership enforcement to the handler.

[danielmlr]

Hi — reviving this one from the practical end rather than the design end.

I build and run client sites on EmDash, and the thing that keeps coming up isn't multi-tenancy or delegation. It's much smaller: "our HR person should be able to edit Job Postings, and nothing else." Today the honest answer to a client is either "everyone who can edit can edit everything" or "you get a second EmDash instance."

The Zanzibar-shaped version in the original post is the right long-term answer, and I suspect that's also why this thread has been quiet since May — it's a big change and nobody wants to start it casually. So I'd like to put something much smaller on the table, and I'd genuinely like to hear whether the shape is acceptable before writing any code.

The idea: one optional minRole per collection

Everything already funnels through a single choke point. packages/auth/src/rbac.ts maps permissions to minimum roles, hasPermission() is just user.role >= Permissions[permission], and every state-changing content route goes through requirePerm() / requireOwnerPerm() in packages/core/src/api/authorize.ts. What's missing isn't a permission model — it's a second dimension on the one that already exists.

1. A nullable min_role INTEGER column on _emdash_collections. NULL = today's behaviour, byte for byte. Forward-only, no existing content becomes inaccessible.

2. A sibling to the existing helper:

   export function hasCollectionPermission(user, permission, collection) {
     return hasPermission(user, permission)
         && (collection.minRole == null || user.role >= collection.minRole);
   }

   plus a requireCollectionPerm() wrapper in authorize.ts for the content routes.

3. The admin filters the collection list by the same rule, so the sidebar and content list only show what you can act on. That part is UX; the API check stays the boundary. (Adjacent but different: feat(admin): allow hiding user-defined collections from admin sidebar #1131 hides collections from the sidebar — presentation, not enforcement.)

Set min_role: 50 on every collection except jobs, make the HR user an Editor, done. Coarse, but it covers the case people actually ask for — and it needs no new concepts, just one integer.

Deliberately out of scope

Per-item rules, field-level permissions, delegation and review workflows, new role tiers, a policy language, ACL tables. If those are wanted they belong in the larger design this thread opened with; I'd rather not drag them in through the back door.

Two things I checked before proposing this

• Query cost — fine, but placement is an open question. Every content handler already reads the collection row: collectionHasSeo() in packages/core/src/api/handlers/content.ts (line 81 on main, 776d65f) is a SELECT … FROM _emdash_collections WHERE slug = ?, called from list, get, create, update, duplicate, delete and restore. So min_role is one more column on a query the request already makes — no extra round trip. What I can't settle from the outside is where the check belongs: routes authorize before the handler runs, and at that point the row isn't loaded. Either the guard goes through getCollectionInfo() (request- and object-cached, packages/core/src/schema/query.ts) or the check moves to the handler boundary. I'd rather follow your preference than guess. Worth noting either way: none of this touches the logged-out hot path — I ran pnpm query-counts --target sqlite, and its fixture routes are all anonymous page renders.

• The MCP path is the easy way to ship a hole. packages/core/src/mcp/server.ts calls hasPermission() directly in several places — lines 412, 562, 812 and 940 on main, including the publish checks. Unless those route through the same helper, an agent token would sail straight past a collection restriction while the admin UI honours it. That needs to land in the same change, not as a follow-up.

Open questions

• One value per collection, or one per class (read / write / publish)? I'd start with a single value; the per-class variant stays additive later.
• I'd scope it to the authenticated management API only — published content stays publicly readable regardless of minRole. Does that match how you'd expect it to behave?
• Interaction with API token scopes: my instinct is that both apply and the stricter one wins. Worth stating explicitly in the docs either way.

Happy to do the work — migration, helper, call sites, admin filter, tests — if a maintainer thinks this shape is worth having, and equally happy to drop it if you'd rather keep the space clear for the full model. I just didn't want to open a PR into an open design question. 🙂