I’m looking for an example or best practices for a RBAC system with two parameters. Rather than simply having a user associated with a role, and that role associated with a group of permissions; a user can be associated with a role “for a specific project,” and the user can then have the permissions of that role for that project only (or for other projects that the user holds that role for). A user can have a specific role on one project, and a different role on another project; the permissions granted to a role are consistent for every project; and a user’s permissions for a project are based on what role that user has on the project.
(If it makes any difference, I’m trying to limit page access where the page content is developed via a URL query parameter that sets the project id through a GET statement.)
ABAC looks promising, but I’m having trouble wrapping my head around it. My understanding is that a user’s attribute dictates whether the user has the role (and/or permissions). In my case it seems like I might consider the project to be the “user,” and my user as an attribute of the project (true, if my user holds the role for that project or false, if not)
If you want to stick to the RBAC standard, then you will have to use different roles for different projects. For example, if the role "admin" is used in projects "P1" and "P2", you can create a role"P1:admin" and another role "P2:admin".
ABAC is indeed another possibility. However, if I understand you correctly, it isn't correct to say that "a user's attribute dictates whether the user has the role (and/or permissions)". There are only attributes in ABAC (in the sense that roles are attributes), which affords more flexibility than RBAC. In a request, you could have an attribute representing the project ("P1" or "P2"), and another attribute representing the role for that particular project ("admin"). A correctly specified policy will be able to recognise that you are referring to the "admin" role as part of the "P1" project, for example.