From Role Base Access Control to a 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
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
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
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
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
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.
The outcome is to extend permissions to an addresses and group them by Roles Id.