An exciting new addition to RegRep 4 ebRIM specification is the ability to do Contextual Role Based Access Control (CRBAC) on resources managed by the registry. This new feature is layered on top of XACML 2.0 specifications.
Most of us are familiar with "simple" RBAC where access to resources is controlled based upon the roles associated with the requestor (the subject). Different roles enable different access control privileges to the subject.
The Problem With Simple RBAC
The problem with simple RBAC is that it does not directly support restricting a role to specific usage contexts. For example, under simple, RBAC Farrukh may be assigned the role of SoftwareDeveloper which gives him the privilege to commit code to a source control repository. But Farrukh works on several software projects at the same time and has different roles within each project (SoftwareDeveloper, ProjectAdmin, DocumentationWriter, SoftwareTester etc.). In this example, what simple RBAC lacks is the ability to provide a project context for a project role.
When is CRBAC Needed Most?
In simple deployments where there is a single organization simple
RBAC may be sufficient. However, in a more complex deployment involving
multiple organizations CRBAC becomes indispensable. Imagine a federated RegRep 4 deployment with multiple registries each managing resources and users from many different organizations. Such deployments are becoming more common now and thus the need for CRBAC is being felt in the present by the RegRep user community.
How CRBAC Addresses the Problem
In our previous example, CRBAC provides the ability to define the various project roles with an explicit project context. So Farrukh can now have a role of SoftwareDeveloper in the context of project A and have a role of ProjectAdmin in the context of project B. Each such role also supports the notion of role inheritance such that a ProjectAdmin role inherits all privileges from the ProjectDeveloper role by virtue of being its sub-role.
Different Types of CRBAC Contexts
CRBAC in RegRep 4 supports any number of contexts within a role definition. In our example, in addition to a project context, a role could also have other contexts such as an organizational context. So Farrukh's roles may be further contextualized by the organization within which Farrukh is performing a project role. For example, Farrukh may be a SoftwareDeveloper within the context of project A at Organization SourceForge and also be a ProjectLead within the context of Project B at Organization GoogleCode.
Although RegRep 4 CRBAC supports any type of context, some typical example of different types of context in a RegRep deployment are:
- Organization context
- Register context
- Registry context
So Where Is the RegRep 4 CRBAC spec?
The latest draft of RegRep 4 is Working Draft 6. Chapter 11 of regrep-ebrim.pdf document within the zip file defines the CRBAC specification.