From Role Base Access Control to a Role & Permission Access Control on a Blockchain

Mauricio Fernandez
Coinmonks
Published in
4 min readOct 15, 2019

--

Role & Permission Access control on a Blockchain

Having read a great article “ Role Based Access Control for the Ethereum Blockchain” from Alberto Cuesta Cañada in Hackernoon.

I decided to embrace his advise and extend the capabilities in Alberto’s RBAC smart contract implementation, it was not an easy task and yet it was very joyful to understand further more details of solidity’s complexities related to the use of data structures (mappings, arrays, simple lists,…).

I have worked with solidity in the past to develop proof of concepts for my customers, had suffered the shortcomings of the language and yet find extremely difficult to find someone to explain things in an easy-to-understand manner; in this regard Julien Klepatch and his youtube channel was very useful for me to grasp the knowledge.

After spending time listening to the explanations and going back and forward between the videos and Alberto’s RBAC smart contract code; it became clear that I’d like to develop functions that allow to assign permissions to an address, and thus extending granular control over the addresses grouped by a role.

Needed further research on well known solidity patterns find very useful the followings:

Mapping with Struct

Template for a Mappings with Struct and functions.

Strengths

  • Random access by unique Id
  • Assurance of Id Uniqueness
  • Enclose arrays, mappings, structs within each “record”

Weaknesses

  • Unable to enumerate the keys
  • Unable to count the keys
  • Needs a manual check to distinguish a default from an explicitly “all 0” record

Mapped Structs with Index

Template for a Mappings with Index and functions.

Strengths

  • Random access by unique Id or row number
  • Assurance of Id uniqueness
  • Enclose arrays, mappings and structs within each “record”
  • List maintains order of declaration
  • Count the records
  • Enumerate the Ids
  • “Soft” delete an item by setting a boolean

Weaknesses

  • Uncontrolled growth of the list

Mapped Structs with Delete-enabled Index

Template for Mapped Structs with Delete-enabled Index and functions.

Strengths

  • Random access by unique Id or row number
  • Assurance of Id uniqueness
  • Enclose arrays, mapping and structs within each “record”
  • Count the records
  • Enumerate the ids
  • Logically control the size of the active list with delete function

Weaknesses

  • Marginally increased code complexity
  • Marginally higher storage costs
  • Key list is inherently unordered

Array of Structs with Unique Ids

Template for Array of Struct with unique Id and functions.

Strengths

  • Random access by Row number
  • Assurance of Id uniqueness
  • Enclose arrays, mappings and structs with each “record”

Weaknesses

  • No random access by Id
  • Uncontrolled growth of the list

The path was clear now and implemented the functions I’ve envisioned to work in Alberto’s RBAC smart contract ; put it together in a new smart contracts named RPAC.sol link

Struct Permission and iassgined, getCounterpermissionlist, newPermissionset, updatePermissions functions.
retrieveaccountpermissions, deletePermission functions.

The new smart contract is split into three contracts.

Contract Roles

Contract Permissions

Contract Addresses2Roles

The Addresses2Roles has inherited the functions of the Contract Roles and Permissions, although it’s recommended to implement your own interface to interact with the latters.

Contract Addresses2Roles

The outcome is to extend permissions to an addresses and group them by Roles Id.

Get Best Software Deals Directly In Your Inbox

--

--