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.
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.