Adding ACL rules or Claims to Dexie.cloud

[TinyLightBold]

@dfahlander hear me out on this one:

I am building an application where it would be handy to be able to have claims added to the system.
Say you are the SuperVisor of all the things going on in the app, and want multiple Companies coupled to it.
Where they can have roles based on the realms, but should not be able to have a private or create their own realm.

if claims would be added to the system, and maybe even manageble from within manager.dexie.cloud.
You can give the email adres with the one that is SuperVisor say if used from cli:

npx dexie-cloud access-level your@email.com --claims '{"superVisor":true}'

Which gives the backend always the base of truth and gives on the frontend possibilities to have 1 application, with a check isSuperVisor for UX purposes, and that person(s) based on emails are the only ones who can do everything based on how rules are set.
Create realms, add companies to it, customers maybe even. And a company itself can login and see the realm that has been maded available by the SuperVisor.

Would be really nice if this would be possible. Or maybe you have a even better way or access to handle this :)

Or able to add custom claims to the user in manager.dexie.cloud like this:

1. Log in to your Dexie Cloud Dashboard (e.g., https://cloud.dexie.com or your custom URL).
2. Go to Users (or Authentication).
3. Find the user with your email address (the one you just created via OTP).
4. Click on the user to see the details.
5. Find the Claims field (sometimes under "Metadata" or "Advanced").
6. Add a JSON object:

{
"superVisor": true
}

[TinyLightBold]

or by having the ability to add Access Control Rules in Dashboard Access Control for example:

{ "version": 1, "tables": { "companies": { "create": [ { "rule": "claims.supervisor == true", "description": "Only Supervisors are allowed to create new companies (realms)" } ], "read": [ { "rule": "claims.supervisor == true", "description": "Supervisors can view all companies" }, { "rule": "owner == auth.user.id", "description": "Owners can view their own company" }, { "rule": "memberships.userId == auth.user.id", "description": "Members can view their own company (via memberships table)" } ], "update": [ { "rule": "claims.supervisor == true || owner == auth.user.id", "description": "Supervisors or Owners are allowed to update company details" } ], "delete": [ { "rule": "claims.supervisor == true", "description": "Only Supervisors are allowed to delete companies" } ] }, "memberships": { "create": [ { "rule": "claims.supervisor == true || (owner == auth.user.id && claims.supervisor != true)", "description": "Supervisors or Company Owners are allowed to invite members" } ], "read": [ { "rule": "userId == auth.user.id || claims.supervisor == true", "description": "Users can view their own membership; Supervisors can view all memberships" } ] } } }

[dfahlander]

Thanks for suggestion! I'll look into it. I confirm that we've got similar FRs from other customers.

Please ping me again to remind if I leave this with no further response for some days, but hopefully a response on Monday

[TinyLightBold]

@dfahlander have you had any update on the idea :)

[dfahlander]

Thanks! I've discussed this internally, taking other demands into account. A pure claims-based ACL system would work best if also having a very flexible rule-set for how to bind claims to legal actions. Currently, the most aching thing we see is the lack of a normal user to create members without requiring an invite flow. You also point out a demand to prohibit normal users from even creating a realm (or to create members with invite: true).

I tend to start off light and see if we can do something that solves the known requirements you and other had, by introducing new concept System Roles (in contrast to Roles that are applied local on each realm).

Roles

Roles are defined globally using npx dexie-cloud import but are applied per realm and only defines actions within the realm.

System Roles (new)

New section in dexie cloud manager. Everyone is a built-in System Role with default settings but possible to uncheck/check them. Supervisor is something that someone can add (dynamically possible to add system roles in case the rule set get extended)

Everyone

• Add new realms (default true)
• Add members, bystepping invite (default false)

Supervisor

• Add new realms
• Add members, bystepping invite

User Manager

When managing users (via REST or in the manager app), system roles can be applied as an attribute on each user. The systemRoles attribute would also be a claim in the JWT.

---

If going for something like a configured System Roles like this, would it solve your use case or is it a too simplistic approach?

[TinyLightBold]

@dfahlander that looks really interesting indeed 🤔.
that could make it work too.
So then When logged in it can check if you have the proper rights overall.
That could also easily be extended in the future with more options for global ruling.

I like it :)