You decide who does what with your smart contracts Historically, privacy was almost implicit, because it was hard to find and gather information. But in the digital world we need to have more explicit rules. — Bill Gates Introduction Role Based Access Control is a that are designed to be accessed by hundreds of users. While this need is commonly implemented in enterprise software and operating systems, not much has been done for the Ethereum Blockchain. security need for software systems This article aims to show how we implemented Role Based Access Control in Solidity for the Ethereum Blockchain, and to teach you to build your own. We also have made our code , please feel free to reuse it in any way or form. public When designing a we realised that we needed to determine dynamically who could add information to each node in the graph. From a real world perspective if you own a manufacturing facility you probably want all operators in the assembly line to record with their own account that they have assembled a part. Supply Chain as a Directed Acyclic Graph , which I use as the gold standard in solidity development, have a contract that they use to implement roles such as Minter and Burner in their . Unfortunately these implementations don’t allow to create new roles at runtime, which you need if you want to control access to each separate token using separate roles. OpenZeppelin Roles.sol ERC721.sol contracts This article aims to show how you can build a Role Based Access Control System for the Ethereum Blockchain. I ended just coding a from scratch according to our requirements, before finding an discontinued version of the from which had pretty much the very same methods. In the interest of reusability I refactored my code as much as I could to follow their nomenclature. RBAC contract same idea OpenZeppelin In the following sections I will describe: The design requirements for our access control system; the implementation as a smart contract; the test cases we considered; the gas usage of state changing methods and some finishing thoughts. Let’s dig in. Conceptual Design My idea for an RBAC system was simple. Roles would be identified by a numeric identifier like groups in unix. Roles could be created dynamically with just a description. Each role would store the addresses of users. Each role would have a second role associated, which would be the only one allowed to add or remove users. If you are using the and contracts from you need to be aware that only implements operations that take effect , while operations that happen are implemented in or the contracts, including the data structure to store roles as you create them. Roles.sol RBAC.sol OpenZeppelin Roles.sol inside a role outside the role RBAC.sol access/roles/*Role.sol I took a number of decisions tailored to our use case: In my implementation I include a description string inside the Role struct, with the structs themselves stored in an array. The position of each Role struct in the array is used as an identifier. There is a temptation to use a mapping to store the Roles, but I find it unnecessary here. Each role receives on instantiation the identifier of another role which we designate as its admin role and which cannot be modified after instantiation. This admin role is the only one that can add and remove bearers to this role. For security and consistency reasons you can remove a Bearer from a Role, but there is no method to remove a Role completely from the system. In my implementation I took a number of implementation decisions tailored to our use case. * An earlier version of this article used arrays to store the bearers in each role. That was changed into a mapping as a suggestion from Nico Vergauwen . The code is more efficient and clearer this way, even if auditing is more cumbersome. Implementation pragma solidity ^ ; contract RBAC {
  event RoleCreated(uint256 role);
  event BearerAdded(address account, uint256 role);
  event BearerRemoved(address account, uint256 role);
  uint256 constant NO_ROLE = ; struct Role {
    string description;
    uint256 admin;
    mapping ( bool) bearers;
  } Role[] public roles; () public {
    addRootRole( );
  } {
    uint256 role = addRole(_roleDescription, roles.length);
    roles[role].bearers[msg.sender] = ;
    emit BearerAdded(msg.sender, role);
  } { (_admin <= roles.length, );
    uint256 role = roles.push(
      Role({ : _roleDescription, : _admin
      })
    ) - ;
    emit RoleCreated(role); role;
  } { roles.length - ;
  } { _role < roles.length && roles[_role].bearers[_account];
  } { (
      _role < roles.length, ); (
      hasRole(msg.sender, roles[_role].admin), ); (
      !hasRole(_account, _role), );
    roles[_role].bearers[_account] = ;
    emit BearerAdded(_account, _role);
  } { (
      _role < roles.length, ); (
      hasRole(msg.sender, roles[_role].admin), ); (
      hasRole(_account, _role), ); roles[_role].bearers[_account];
    emit BearerRemoved(_account, _role);
  }
} 0.5 .0 /**
* @title RBAC
* @author Alberto Cuesta Canada
* @notice Implements runtime configurable Role Based Access Control.
*/ 0 /**
   * @notice A role, which will be used to group users.
   * @dev The role id is its position in the roles array.
   * @param description A description for the role.
   * @param admin The only role that can add or remove bearers from
   * this role. To have the role bearers to be also the role admins 
   * you should pass roles.length as the admin role.
   * @param bearers Addresses belonging to this role.
   */ => address /**
   * @notice All roles ever created.
   */ /**
   * @notice The contract constructor, empty as of now.
   */ constructor "NO_ROLE" /**
   * @notice Create a new role that has itself as an admin. 
   * msg.sender is added as a bearer.
   * @param _roleDescription The description of the role created.
   * @return The role id.
   */ ( ) ( ) function addRootRole string memory _roleDescription public returns uint256 true /**
   * @notice Create a new role.
   * @param _roleDescription The description of the role created.
   * @param _admin The role that is allowed to add and remove
   * bearers from the role being created.
   * @return The role id.
   */ ( ) ( ) function addRole string memory _roleDescription, uint256 _admin public returns uint256 require "Admin role doesn't exist." description admin 1 return /**
   * @notice Retrieve the number of roles in the contract.
   * @dev The zero position in the roles array is reserved for
   * NO_ROLE and doesn't count towards this total.
   */ ( ) ( ) function totalRoles public view returns uint256 return 1 /**
   * @notice Verify whether an account is a bearer of a role
   * @param _account The account to verify.
   * @param _role The role to look into.
   * @return Whether the account is a bearer of the role.
   */ ( ) ( ) function hasRole address _account, uint256 _role public view returns bool return /**
   * @notice A method to add a bearer to a role
   * @param _account The account to add as a bearer.
   * @param _role The role to add the bearer to.
   */ ( ) function addBearer address _account, uint256 _role public require "Role doesn't exist." require "User can't add bearers." require "Account is bearer of role." true /**
   * @notice A method to remove a bearer from a role
   * @param _account The account to remove as a bearer.
   * @param _role The role to remove the bearer from.
   */ ( ) function removeBearer address _account, uint256 _role public require "Role doesn't exist." require "User can't remove bearers." require "Account is not bearer of role." delete Testing I like to describe the tests passed when , both to show the edge cases and to provide some confidence as to the reliability of the code. making a contract public : RBAC ✓ creates a role.
✓ hasRole returns false for non existing roles.
✓ hasRole returns false for non existing ✓ msg.sender as ✓ doesn’t msg.sender with admin role.
✓ on non existing roles.
✓ on non authorized users.
✓ the to the role.
✓ a to a role.
✓ removeBearer on non existing roles.
✓ removeBearer on non authorized users.
✓ removeBearer the doesn Contract RBAC addRootRole bearerships. addRootRole adds bearer. addRole add addBearer reverts addBearer reverts addBearer reverts if bearer belongs addBearer adds bearer reverts reverts reverts if bearer 't belong to the role.
✓ removeBearer removes a bearer from a role. In response to previous feedback, I’m now including as well a gas usage report using eth-gas-reporter. Conclusion This article describes an implementation for a Smart Contract Role Based Access Control System, which has the following properties: Allows new roles to be created at runtime. Includes a concept of role administrator, which is allowed to add and remove members to the role. Allows to easily determine all existing roles and their bearers. Role Based Access Control is not necessarily complex to implement, but as this article shows there are a number of trade-offs and design decisions that need to be taken into account, which will be closely related to your users and the actions that they are allowed to perform. While I would be very pleased if you decide to of an RBAC system, I encourage you to look for and consider other options. reuse this implementation For a practical application of this RBAC contract, stay tuned for the next article in our series. Supply Chain

The Graph

Chain

Assembly

I was the Blockchain Architect for a dozen projects. This is what I learnt.

Fixed point math in Solidity

Ask me a question! 

Nominated for 2022 - HackerNoon Contributor of the Year - How To

Nominated for 2022 - HackerNoon Contributor of the Year - Smart Contracts

Nominated for 2022 - HackerNoon Contributor of the Year - Solidity

Too Long; Didn't Read

Role Based Access Control for the Ethereum Blockchain

Role Based Access Control for the Ethereum Blockchain

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A Linked List Implementation for Ethereum [Deep Dive]

(1/100) Crypto Countdown: Golem

A Research Report on the Trader $JOE DeFi Platform

07/03/2018: Biggest Stories in the Cryptosphere

05/02/2018: Biggest Stories in the Cryptosphere

01/06/2018: Biggest Stories in the Cryptosphere

A Linked List Implementation for Ethereum [Deep Dive]

(1/100) Crypto Countdown: Golem

A Research Report on the Trader $JOE DeFi Platform

07/03/2018: Biggest Stories in the Cryptosphere

05/02/2018: Biggest Stories in the Cryptosphere

01/06/2018: Biggest Stories in the Cryptosphere

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps