2021 International Conference on Innovation and Intelligence for Informatics, Computing, and Technologies (3ICT)

On the Implementation of Access Control in

2021 International Conference on Innovation and Intelligence for Informatics, Computing, and Technologies (3ICT) | 978-1-6654-4032-5/21/$31.00 ©2021 IEEE | DOI: 10.1109/3ICT53449.2021.9581591

Ethereum Blockchain
Insaf Achour
National School of Computer Sciences
University of Manouba
Manouba, Tunisia
insaf.achour@ensi-uma.tn
Samiha Ayed
University of Technology of Troyes
University of Troyes
Troyes, France
samiha.ayed@utt.fr
Hanen Idoudi
National School of Computer Sciences
University of Manouba
Manouba, Tunisia
hanen.idoudi@ensi-uma.tn

Abstract—Access control is a main component in Blockchain
systems. It is usually implemented in smart contracts and defines
the security policy, in other words, it determines who can access
a protected resource in the network. In this paper, we present
a review of the major implementations of access control in
Ethereum platform. The latter is based on RBAC model (Role-
Based Access Control). Implementations require to take into
account the whole RBAC process, that is, user role assignment
and permission assignment. Three implementations currently
exist and are described and compared in this work according
to several features : RBAC-SC, Smart policies and OpenZepplin
contracts.
Index Terms—Blockchain, Smart Contract, Ethereum, Solidity,
Access Control, RBAC.
I. I NTRODUCTION
URING recent years, Blockchain attracted great interest
D due to the need of a trusted and a secure network
allowing transactions to be shared in a transparent and in a
secure way. Introduced in 2008 by Satoshi Nakamoto [1] with
the rise of Bitcoin cryptocurrency, Blockchain is a distributed
and decentralized ledger used to store transactions perma-
nently between nodes in a peer to peer network. The strength
of the Blockchain technology is based on the cryptography
mechanism that connects blocks to each other in a secure way.
Then each block contains the hash of the previous block.
In a Blockchain network, transactions are executed via smart
contracts which are a self executing programs determining
the conditions and the requirements of the achievement of a
transaction [2]. Then developers create the code by defining
the input logic of the agreement. Smart contracts are deployed
into Blockchain network and when the defined conditions are
satisfied, transactions will be executed automatically and assets
will be transferred to the new owner. Finally, states of different
parties and of assets will be updated and contracts take end.
Blockchain network involves three types of participants or
nodes: (1) Users or clients consult and request the addition of
information to the Blockchain via an intermediate node, (2)
ordinary nodes which request the addition of information to the
Blockchain, consult the Blockchain but do not participate in its
construction, (3) miners which are the nodes that participate
in the process of creating the blocks, validating and adding
new transactions to the ledger [3].
Transactions are verified and validated by applying a con-
sensus protocol [4]. We can mention the Byzantian fault of
tolerance which is a state machine replication protocol that
tolerates "byzantine" faults. It provides a controlled resistance
to faults. One of the most common faults is the arbitrary
malicious behavior (byzantine faults) of one or more nodes
(minors). Proof of work is a consensus protocol based on
the calculation of a Nounce which requires very powerful
calculation operations. This puts miners in competition to
perform transactions on the network and then be rewarded.
Despite being a large energy consumer, this protocol has
shown its reliability. It is the basic protocol of Bitcoin. Another
known consensus protocol is the proof of stake. Its principle
is not to show an effort of calculation but to possess a certain
quantity of money. This allows the miner with the most assets
not to cheat.
The attacker must have more than 50% of the available
currency to succeed in a double spend, The difficulty depends
on the number of cryptocurrencies of the miner and their age
(CoinAge). The difficulty reduces in percentage according to
the number of CoinAge the miner has. This forces users to
hold the network currency.
Blockchain was used first for cryptocurrency exchange and
then it was extended to multiple applications. The use of
Blokchain in insurance can reduce the human error and save
time. Smart contracts can perform error checking, routing,
and approval workflows, and calculates payout based on the
type of claim and underlying policy. In healthcare domain,
Blockchain is used for electronic medical record manage-
ment and pharmaceuticals products traceability. In supply
chain management, Blockchain allows tracking goods from
production to distribution. Another interesting application of
Blockchain is its integration with the Internet of things (IoT).
IoT systems are often based on centralized access control
systems, which leads to the problem of single point of failure
and also to privacy issues. These are the major motivations to
use Blockchain for the access control in IoT applications [5]
[6].
Moreover, access control is an important process in many
Blockchains. There are multiple access control models in
the literature, however, the most used for Blockchains are
RBAC (Role Based Access Control) and ABAC (Attribute-

zed licensed use limited 978-1-6654-4032-5/21/$31.00

to: MINISTERE DE L'ENSEIGNEMENT©2021 483 SCIENTIFIQUE. Downloaded on April 16,2022 at 13:54:33 UTC from IEEE Xplore. Restriction
IEEEET DE LA RECHERCHE
SUPERIEUR
 2021 International Conference on Innovation and Intelligence for Informatics, Computing, and Technologies (3ICT)
based access control).
In this paper, we focus on access control in Ethereum
which is mainly based on the RBAC model. All the policies
of access control are implemented in a smart contract. Our
objective in this paper is to introduce a review of the access
control implementations in Ethereum and not the Blockchain
based access control applications namely FAirAccess [7] or
MedRec [8].Our overview doesn’t study the challenges of
access control systems and the need of blockchain to pass them
like the survey in [9] where authors introduce access control
works by domain and platform.In our work, we compare
the three major existing access control implementations. This
comparison can help smart contracts developers to choose the
suitable implementations for their applications.
This paper is organized in three sections. In section I, we
give a brief description of the main concepts used in this
work. We introduce the implementations of access control in
Ethereum in section II and we compare them according to
several identified features. In section III, we conclude the paper
and present the perspectives of our work.
II. BACKGROUND
A. Ethereum platform
There are many Blockchain platforms supporting smart
contracts. In this work, we are interested about Ethereum
platform.
Ethereum is permissionless platform, introduced by Vitalik
in 2014[10]. Smart contracts in Ethereum are written in
Solidity, Python, Go or C++, they are Turing complete and
are running in the Ethereum Virtual Machine (EVM). The
EVM is used to facilitate the execution of smart contracts
and to perform consensus. In this platform the Proof of
Stake consensus is adopted to validate transactions. Ethereum
introduces the ETHR cryptocurrency that is used to pay the
execution of code in the network which is called a gas.
Therefore any node who needs to execute a transaction must
pay. Ethereum has two types of accounts: Externally Owned
Account (EOA) and Contract Account. An EOA takes the form
of an address. It has a private key and ether balance, can
exchange transactions and doesn’t have a code. A contract
account has an ether balance and has a code.
B. Solidity smart contracts
In 1997, Nick Szabo [11] introduced the smart contracts as
programs or protocols that define the obligation, prohibition,
permission and optional terms. These programs can be exe-
cuted without the need of third party. This is maintained by
the consensus protocols.
With the emerging of Blockchain, smart contracts have
taken another direction which is self executing programs. Then
developers create the code by defining the input logic of the
agreement. Smart contracts will be deployed into Blockchain
and when the defined conditions are satisfied, transactions will
be executed automatically and assets will be transferred to the
new owners. Finally, states of different parties and of assets
will be updated and contracts take end.
484 SCIENTIFIQUE. Downloaded on April 16,2022 at 13:54:33 UTC from IEEE Xplore. Restriction
zed licensed use limited to: MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE
Smart contracts in Ethereum are implemented in Solidity.
Contracts can import other contracts or libraries. Each contract
contains variables, functions and constructor. Solidity allows
the inheritance mechanism and uses events to notify about a
state change. There is also the concept of modifier that is used
to replace a function body. Modifiers are so used in the access
control context [12].
C. Access control
The access control is an important mechanism for database
systems, information systems and recently for Blockchain
technology. Actually, Access control is a method to allocate
or to deny a permission to a user according to his request
to execute an action on a protected resource or object. For
example, in ERC20 contract access control defines who can
mint and burn tokens. Many models of access control are
defined [13], such as:
• DAC (Discretionary Access Control): it attributes autho-
rization based on the users’ authentication.
• MDAC (Mandatory Access Control): it is handled by an
administrator that assigns labels to sensitive data to secure
it.
• RBAC: it is used for multiple users and multiples ap-
plications. Main components of the RBAC model [14],
are users, roles, operations or actions executed on the
protected objects or resources and permissions. Users are
assigned to roles and permissions are attributed to each
role.
• ABAC (Attribute based Access Control): In contrast
of RBAC, it is based on the attributes of the subject,
resource, action, and environment in an access scenario.
III. I MPLEMENTATION OF ACCESS C ONTROL IN
E THEREUM
In this section we describe the existing implementations of
access control in Ethereum and we compare them.
A. Access control implementations
1) RBAC-SC: In [15] authors introduced RBAC-SC as
an Access Control implementation for Solidity Smart Con-
tracts.The objective of this work is to apply the RBAC
mechanism and to verify the user role assignments. The project
is hosted on Github. [16]
The proposed implementation is composed of two main
parts as shown in Fig.1: (1) a smart contract and (2) a
challenge-response protocol. The smart contract (SC) deter-
mines the user-role assignments, that will be deployed on the
blockchain network. The RBAC-SC has an administrator who
is the initial deployer of the smart contract. It stores users and
their roles. The RBAC-SC implements the following functions:
• addUser(u.EOA, u.role, u.notes) and removeUser(u.EOA)
that can only be executed by the SC owner or creator.
• addEndorsee(eu.EOA, eu.notes) function that can only be
executed by a registered user.
• removeEndorsee(eu.EOA) function that lets a user remove
an endorser from the SC.
 2021 International Conference on Innovation and Intelligence for Informatics, Computing, and Technologies (3ICT)
• changeStatus() function that allows the SC owner or
creator to deactivate the SC.
The challenge-response protocol is an off-chain process and
it is performed when a user requests a service corresponding
to his role. The authentication of the ownership of roles and
the verification of the user role assignment are applied in the
challenge-response protocol following these five steps:
• Declaration: it defines the user who is the EOA with a
role corresponding to a service issued in the SC.
• Information Check: the service provider checks user
information: role and owner of the EOA.
• Challenge: the user must signs using data chosen by the
service provider.
• Response: the user signs with EOA and his private key.
• Response Verification: when the verification succeeded
the service will be provided to his requester.
] only one owner and he is the administrator of the contract. This
Fig. 1. RBAC-SC implementation[15]
2) Smart policies: The second implementation of the ac-
cess control in Ethereum is Smart Policies [17]. In this
work, authors adopted the ABAC model. First, they write
the policies on XACML (eXtensible Access Control Markup
Language) and translate it into Solidity smart contract. On top
of the Blockchain technology, they defined the components of
XACML standard namely the Policy Enforcement Point (PEP),
the Policy Administration Point (PAP), the Attribute Managers
(AMs), the Policy Information Points (PIPs) and the Policy
Decision Point (PDP). The Context handler (CH) is split on
the off chain component and the Blockchain protocol. This
approach is divided in two steps as illustrated in Fig.2:
485 SCIENTIFIQUE. Downloaded on April 16,2022 at 13:54:33 UTC from IEEE Xplore. Restriction
zed licensed use limited to: MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE
• New policy creation: the resource owner writes an
XACML policy and sends it to the PAP to be stored in the
Blockchain. Then the PAP translates the XACML policy
into a smart contract called "the SMART POLICY". After
that, the initial CH deploys the contract in the Blockchain
and will be stored once it is accepted.
• Access request time: after the creation of the contract
"Smart Policy", the Blockchain Access Control service
will respond to the access requests.
Fig. 2. Smart Policy implementation[17]
3) OpenZepplin: OpenZeppelin is an open source library
published on Github [18], it implements multiple Solidity
contracts and different libraries to be reused. One of these
implementations is access control based on RBAC model.
The access control in Ethereum Blockchain is based on three
models developed by the OpenZepplin library [19]: (1) the
ownable contract, (2) the Role-Based Access Control contract
and (3) the "AccessControlEnumerable" model.
The first contract is the Ownable.sol contract where there is
contract is based on the use of modifiers "onlyOwner" before
each protected function. This contract offers the possibility
to transfer Ownership from the owner account to a new one
and to renounce Ownership for the owner to relinquish this
administrative privilege.
The second model is called AccessControl.sol. The Role-
Based Access Control is designed for contracts requiring
different levels of authorization. Then, this contract is based on
RBAC where it defines multiple roles with a set of permissions
and it also implements rules for how accounts can be granted
or revoked to/from a role. Moreover, each role has its admin-
istrator. An administrator can grant and revoke roles to others
accounts. There is a default administrator role who is the initial
administrator of all the roles. Therefore, he can do the same
 2021 International Conference on Innovation and Intelligence for Informatics, Computing, and Technologies (3ICT)
tasks as administrator role and he can set it. Similarly, this
contract use modifiers "onlyRole" to the protected function.
Also it defines a set of administrator functions [20]that give
him more flexibility to allocate privileges, this includes:
• hasRole(role, account): Returns true if account has been
granted role.
• checkRole(role, account): Revert with a standard message
if account is missing role.
• getRoleAdmin(role): Returns the admin role that controls
role.
• grantRole(role, account): Grants role to account.
• revokeRole(role, account): Revokes role from account.
• renounceRole(role, account): Revokes role from the call-
ing account.
• setupRole(role, account): Grants role to account.
• setRoleAdmin(role, adminRole): Sets adminRole as role’s
admin role.
The last model called AccessControlEnumerable.sol is an
extension to the second contract when enumerating members
of each role is required. It contains the same functions as the
"AccessControl.sol" and adds two functions [20]:
• getRoleMember(role, index): returns one of the accounts
that have role.
• getRoleMemberCount(role): returns the number of ac-
counts that have role.
B. Discussion and comparison
In this section we compare the three implementations in
terms of used access control model, reusability, flexibility,
operating mode and authentication. Then we discuss the use
cases of each implementations.
Comparison: First of all, RBAC-SC and OpenZepplin
smart contracts are based on RBAC models and the smart
policies contracts have implemented the ABAC model.
Smart contracts in RBAC-SC are used in a specific problem,
in spite of OpenZepplin which are reusable especially that
it takes the form of libraries so they are simply imported
by other contracts. Because smart policies are performed off
chain, that makes it not suitable for reuse. Another point
is that the role allocation is more flexible for OpenZepplin
smart contracts rather than RBAC-SC. In fact, in the RBAC-
SC implementation, if a user loses his private key, the system
doesn’t update the role allocation or if the owner is transferred
all role attributions will be deleted. Also the flexibility of
OpenZepplin smart contract is explained by the fact that it
offers three models of access control, so it can be used for
complex applications that require multiple roles, for example.
The Smart policies contracts are flexible in term of using
XACML rather than modifiers.
The other criterion of comparison is the operating mode,
smart policies apply the access control off chain but the two
others implementations are on chain. The advantage of per-
forming access control on chain is to hold more transparency
to the contract.
In addition to access control, RBAC-SC contracts perform
authentication mechanism via the challenge response process.
486 SCIENTIFIQUE. Downloaded on April 16,2022 at 13:54:33 UTC from IEEE Xplore. Restriction
zed licensed use limited to: MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE
For OpenZepplin contracts the authentication is done by the
constant msg.sender.
In table 1, we give a brief comparison between the three
implementation of access control in Ethereum using the 5
features discussed above.
TABLE I
C OMPARISON BETWEEN RBAC-SC, S MART POLICIES AND O PEN Z EPPLIN
ACCESS CONTROL
Features RBAC- Smart OpenZepplin
SC[15] policies[17] [18]
Access control RBAC ABAC RBAC
Model
Reusability no no yes
Flexibility no yes yes
Operating on chain off chain on chain
mode
Authentfication yes no yes
Discussion: The OpenZepplin access control smart con-
tracts are the most used one because they are considered as a
standard for Ethereum. In fact, OpenZepplin implementations
can be used in many cases: (1) In case of a unique owner of
an asset, the Ownable contract is the most suitable one. (2)
In case of multiple roles, the AccessControl contract is used.
(3) When counting the members or giving the members of a
specific role are needed. The RBAC-SC is used in a specific
case which is a trans-organizational RBAC, that means that
an organization provides a service to a user who has role that
was attributed by a another organization. The smart policies
contracts are flexible and can be used in multiple cases such
OpenZepplin contracts, but they are not performed totally on
the blockchain, which means the lack of transparency in the
process of permissions and roles allocation.
IV. C ONCLUSION
In this paper, we presented a brief review on access control
implementations for Ethereum Blockchain. Automating access
control in Blockchains is rather a new concern which explains
the scarcity of works dealing with this issue. To our best
knowledge, only 3 implementations of access control for
Etherum smart contract exist : 1) the RBAC-SC that imple-
ments the RBAC model using Solidity smart contract, 2) the
smart policies which are contracts generated by the translation
of access control policy based on ABAC model from XACML
to Solidity and, finaly, 3) the OpenZepplin access control smart
contracts which implement one of these models: ownable,
RBAC access control or Enumerable RBAC access control.
Actually the last implementation is the well known and the
more used and it is now a standard for Ethereum platform.
This is due to its great flexibility and reusability comparing to
the others.
For future works, we intend to review the access control
implementation in other platforms rather than Ethereum and
to compare between them to find the commonalities and the
differences.
 2021 International Conference on Innovation and Intelligence for Informatics, Computing, and Technologies (3ICT)

R EFERENCES
[1] S. Nakamoto. "bitcoin: A peer-to-peer electronic cash system". White
paper, 2008.
[2] Y. Yuan X. Ni X. Han S. Wang, L. Ouyang and F. Y. Wang. "blockchain-
enabled smart contracts: Architecture, applications, and future trends".
IEEE Transactions On Systems, Man, And Cybernetics: Systems, 2019.
[3] M. Risius and K. Spohrer. " a blockchain research framework what we
(don’t) know, where we go from here, and how we will get there". Bus
Inf Syst Eng 59(6):385–409 (2017) https://doi.org/10.1007/s12599-017-
0506-0, 2017.
[4] S. Zhang and J.H Lee. "analysis of the main consensus protocols of
blockchain". ICT Express, Volume 6, Issue 2, June 2020, Pages 93-97,
2020.
[5] M. Sangeetha P. Patil and V. Bhaskar. "blockchain for iot access control,
security and privacy: A review". Wireless Pers Commun 117, 1815–1834.
https://doi.org/10.1007/s11277-020-07947-2, 2021.
[6] G. P. Gupta R. Tripathi T. R. Gadekallu N. Xiong P. Kumar, R. Kumar
G. Srivastava. "ppsf: A privacy-preserving and secure framework using
blockchain-based machine-learning for iot-driven smart cities". IEEE
Transactions on Network Science and Engineering PP(99):1-1, 2021.
[7] A. Abou Elkalam A. Ouaddah and A. Ait Ouahman. "fairaccess: a new
blockchain-based access controlframework for the internet of thing".
Secur. Commun. Netw. 9, 5943–5964., 2016.
[8] T. Vieira A. Azaria, A. Ekblaw and A. Lippman. "medrec: Using
blockchain for medical data access and permission management". 2nd
International Conference on Open and Big Data, 2016.
[9] R. Deters S. Rouhani. "blockchain based access control systems: State of
the art and challenges". In Proceedings of IEEE/WIC/ACM International
Conference on Web Intelligence (Web Intelligence ’19). ACM, New York,
NY, USA, 6 pages, 2019.
[10] V. Buterin. "a next-generation smart contract and decentralized ap-
plication platform". Ethereum White Paper. Available online at:
https://github.com/ethereum/wiki/wiki/White-Paper/, Accessed in 02-11-
2020.
[11] N. Szabo. "the idea of smart contracts. nick szabo’s papers and concise
tutorials". 1997.
[12] https://docs.soliditylang.org/en/develop/. Accessed in 18-06-2021.
[13] K. Jambi K. Almarhabi A. I. Abdi, F. Elbouraey Eassa and A. S. AL-
Ghamdi. "blockchain platforms and access control classification for iot
systems". Symmetry 2020, 12, 1663; doi:10.3390/sym12101663, 2020.
[14] S. Gavrila D. Richard Kühn D. F. Ferraiolo, R. Sandhu and R. Chan-
dramouli. "proposed nist standard for role-based access bontrol". ACM
Transactions on Information and System Security (TISSEC), 4(3), 224–
274, 2001.
[15] Y. Kaji J. P. Cruz and N. Yanai. "rbac-sc: Role-based access control
using smart contract". IEEE Access: Special section on research
challenges and opportunities in security and privacy of blockchain
technologies, 2018.
[16] https://github.com/jpmcruz/rbac-sc/blob/master/rbacsc.sol. Accessed in
18-06-2021.
[17] P. Mori D. Di Francesco Maesa and L. Ricci. "blockchain based
access control services". The 2018 IEEE International Conference on
Blockchain (Blockchain-2018), 2018.
[18] https://github.com/openzeppelin/openzeppelin-contracts. Accessed in
18-06-2021.
[19] https://github.com/openzeppelin/openzeppelin-contracts. Accessed in
18-06-2021.
[20] https://docs.openzeppelin.com/contracts/4.x/api/access. Accessed in 18-
06-2021.

487 SCIENTIFIQUE. Downloaded on April 16,2022 at 13:54:33 UTC from IEEE Xplore. Restriction
zed licensed use limited to: MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE