Access Control (Beta)

Openzeppelin’s upcoming release v3.0 (currently in Beta) discontinues Roles library in favour of an abstract contract called AccessControl .

Note: It is not recommended that you use this solution in production applications whilst it is still in the testing phase.

Figure 5 shows the implementation of AccessControl .

Figure 5: AccessControl.sol (in Beta)

It exhibits much of the same functionality as Roles but removes the need for child contracts to implement a Roles.Role state variable for each role. Instead, each role implemented by the child contract is denoted by a bytes32 variable. AccessControl also defines DEFAULT_ADMIN_ROLE for a super administrator as seen in the implementation of a child contract in Figure 6.

Figure 6: Implementing AccessControl

The example provided in figure 6 is again static, but AccessControl provides the flexibility required to implement a dynamic version. Alberto Cuesta Cañada has an example contract called Hierarchy , implementing AccessControl , which enables the dynamic creation of roles at runtime. Figure 7 shows the Hierarchy contract code.

Figure 7: Hierarchy.sol

This goes some way to enabling dynamic access control, following RBAC standards. However, it is only half of the solution.

It enables roles to be set dynamically, but access levels of functions must still be hardcoded. For example, we have a smart contract called Settings which should only be called by users with the roles ‘ADMIN’ and ‘EDITOR’. The require statements in the Settings contract must be hardcoded along the lines of:

function aSettingsFunction() public onlyMember('ADMIN') onlyMember('EDITOR') {}

Therefore, the same problem remains. If the InfoSec administrator wants to dynamically add a new role which should have access to this function, a new definition must be written and shipped for this function.

Another route would be to assign multiple roles per user. So an administrator would be assigned the roles ‘ADMIN’, ‘EDITOR’ and ‘WRITER’. Assuming all administrators are also editors and writers, the above function could then be written like this:

function aSettingsFunction() public onlyMember('EDITOR') {}

But this doesn’t really follow RBAC, where each user has a single role, and in a hierarchical system, they inherit the permissions of the lower roles.

AND we still have the problem of being able to introduce new roles as they’re needed, and dynamically attributing them to functions.