Complex Permissions: Hybrid ABAC -> RBAC

We have an in-app permissions setup, which is familiar to all of us, but does not seem to be as easy to config as one would hope.

Basically, it is permissions like you are used to with google drive, airtable, slack, your PM/task tools, etc … and that is that you give someone access to a certain type of asset, with a certain permissions level for that asset.
Additional, this permission is usually inherited to child assets in the hierarchy with the same permissions, unless a child has their permissions over-ridden as private, etc.

The access to these assets is based off the asset “type” being shared with other users, within a hierarchy, and for certain permissions (ie crud, etc) for each asset that is shared with the other user.

To us, this seems to be hybrid ABAC → RBAC … as in, the user gets permissions to a certain assetID and type, and for that assetID and type, they are granted certain roles, for that asset type.


For us, we have a number of assets within a hierarchy, such as:

  • organisation {one:many} child-organisation
  • project {one:many} child-project
  • dashboard {one:many} tile {many:many} data-connector, etc …

And for each asset type, we have certain roles. such as:

  • owner, manager, collaborator, guest-edit, guest-view, public, etc

This means that the OWNER of dashboardID9akje86874, within projectID987365, which is within orgID362, wishes to share that dashboard with userIDkjshu8r6783 and give them the permissions of a guest-view for ONLY dashboardID9akje86874.

userIDkjshu8r6783 can only view the dashboard, they are unable to see detail of the org or the project, unless it is displayed on the dashboard.
(like when someone shares a file or folder with you from google drive, you can see what is within that asset that is shared with you, but not the parent structure/assets).

That same OWNER has permissions to add someone else to projectID987365 with collaborator permissions on the project. They would then be able to see the project details and all the dashboards in the project.


We are currently investigating the following libraries, which seem to solidly support hybrid ABAC/RBAC permissions scenario:

Has anyone looked at these, and any thoughts on which may/may not work best with RedwoodJS ?

Thanks in advance for any thoughts, advice or assistance on how to approach.

Max


ps: have looked at other threads, but have not seen anything beyond a mention of CASL (which we looked at, but didn’t seem to extend far enough).
pps: we had been playing with blitz also, and there is no solution (less evolved than redwood) there without external libraries either. The approach in schema base only takes so far in both, and is easy to have this in the prisma2 structure (and prisma is great to help with this once you work it out), but the per asset, per type, then roles on tops of that being managed in a scalable way, then retrievable in the UI for a userID, or an assetID, and for sharing on individual asset in a hierarchy needs a bit more heavy lifting (and my be more than what we can spin up ourselves with any surety we haven’t stuffed it up).
Would love to work this out, as will help us a HUGE deal to move forward, as permissions is where we are blocked at the moment :frowning:


Refs:

1 Like

@MaxLynam

As you know, with most access control some common questions to solve are:

  • how to define the access permissions
  • how to store the access permissions
  • how to trust those permissions
  • how to fetch them
  • and how to enforce them

Depending on the authentication provider and other choices you can make when designing an app, those questions can be answered a number of different ways.

At the moment RedwoodJS supports several Auth providers and they in turn deliver a JWT (that can be verified) that can contain some bits of information. The access info is just that – info.

It determines that they are authenticated and for how long and some identifier that represents them.

In some cases, like with Netlify and Auth0 they can store some additional info on the user_metadata that indicates what roles or permissions they have. What those are can be for the app to decide.

The auth provider and token won’t do any enforcing – it will just give you info that can be used to enforce those rules.

The providers at the moment that RedwoodJS supports that has the most fine grained control that I have seen are Auth0 for the info on the JWT and Supabase for its data-level policies.

Auth0 can store and set both roles and permissions on the auth token. But, again you’ll have to enforce those rules either at the data store level or at the service level. That’s where your ABAC rules and “enforcers” can come in.

Supabase can provide policy-level control at the database level by enforcing read/write permissions based on a set of rules/queries.

image

This way you can determine who the user is via the JWT, match their roles, and enforce a policy when selecting data. Ie - don’t let this user access content they are not allowed to. Here you may be able to define your ABAC rules in SQL and enforce them. The nice thing about this is that it’s at the database level. However, in RedwoodJS case here it typically connects to the db via an admin account so one may have to use the Supabase SDK client to query or at least check permissions.

From my very very very quick scan at casbin, it looks similar to Supabase’s policies – you defines some read/write access to a model and there a function that returns a true/false based on some logic to determine access.

R/ABAC is non-trivial and my best suggestion is to create a small proof of concept app with 5 or so of your main uses cases and try out a few possible tools or techniques. And write test cases to make sure that you can reproduce the right access permissions each time as you try out each one.

You’ll get a quick sense of if it works for you, how difficult it is to maintain/manage, and if you like developing with it.

Let us know how you get on. Curious to know what you find out.

3 Likes

thanks heaps @dthyresson … it is definitely a beast and we are doing a few trials to see what seems to be doing what we need.

Will also follow on from your instructions and check Supabase … hadn’t seen that before and looks pretty cool :slight_smile:

Thanks heaps for the extra guidance.

1 Like