Authorization on sets of resources

Two related questions.

My django (REST) application will have internal “projects” created by users. Imagine we have ProjectA, ProjectB, ProjectC (Instances of “Project” Model). Each of these projects ‘contains’ model instances of ModelX and ModelY.

How should I setup permissions that allow a group to, for example, have READ/WRITE access to ProjectA’s both ModelX and ModelY instances, READ access to ProjectB’s ModelX instances, and no access to any object instances of ProjectC?

It seems like I’d need some form of object-level permissions on the Projects that somehow related to the model instances for those projects.

Ultimately, I’m imagining it needs to look something like:
ProjectA | Can read ModelX
ProjectA | Can write ModelX
ProjectB | Can read ModelX

Where, again, the Project’s are instances of a Projects model.

The other question is:
What’s the best way to get these out for RBAC of our frontend (react)

There are many different ways to handle object-level permissions. Django is extremely flexible in that area.

You can add code in your views to Limit access to users who pass a test as a starting point.

If you’re looking for something more pre-packaged, look at some of your options at Django Packages in the security section

Because you have no effective control over the client side, You’ll always want to enforce these restrictions on the server-side, either within your views or your models. (It doesn’t matter what you’re using to build the UI, there’s always a way for the end user to monkey with the data being submitted and so attempt to perform an operation that you want to prevent them from performing.)

Yep, I of course know that the front end is always insecure. Also, keep in mind that this is an API (no Django views). I’ve looked at all of the libraries, and have messed around with django-guardian, but it doesn’t seem to quite check the box I need checked.

Even an API (using, for example, DRF) is a “view”. At some point, Django is receiving an HTTP request and preparing a response. If you’re filtering or limiting models for display, that’s your hook into where you would apply your security model.

(Side note: We went with a strictly roll-your-own implementation solution because none of the supplied packages provided all the facilities we needed either.)