The RBAC proposal #45 creates several tables for the purpose of the app, and has a fairly loose connection to the models that it applies for. Relationships are typically GenericForeignKey type (in its most bound form) which manage things like cascade deletion at the application level (if at all).

Because of this, there should be no fundamental blocker to managing RBAC for a model that doesn't exist on the local server, and instead exists in a remote server. The only problem is that we have to run some querysets in order to support features like resource permission inheritance. Solutions could be:

1. sync a representational entry for every object in the remote system to the local system so that the RoleEvaluation entries can be filled in, and object-level access can be shown
2. don't bother with object-level access of remote objects, and just skip all re-computation logic for external objects

Right now I think I prefer (2), which still has some implementation challenges because of source-of-truth issues, but I looked at that before and believed that an acceptable solution would be possible.

Of course the big missing piece is a replacement for the content type model which can include entries for non-local models. The RBAC system should be flexible enough to customize the content type... DAB probably needs to provide at least an abstract model since certain extra fields will be needed, like an indicator that a type is external, and probably a representation of which external system it exists in.