2021 IEEE 30th International Conference on Enabling Technologies: Infrastructure for Collaborative Enterprises
(WETICE)
2021 IEEE 30th International Conference on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE) | 978-1-6654-2789-0/21/$31.00 ©2021 IEEE | DOI: 10.1109/WETICE53228.2021.00020
Automatic Generation of Access Control for
Permissionless Blockchains: Ethereum Use Case
Insaf Achour Hanen IDOUDI
National School of Computer Sciences National School of Computer Sciences
University of Manouba University of Manouba
Manouba, Tunisia Manouba, Tunisia
insaf.achour@ensi-uma.tn hanen.idoudi@ensi-uma.tn
Abstract—Access control in Blockchain context is a crucial
step. During this process it is important to verify that users have
the right roles to get access to the protected resources. To model
its access control, the Ethereum Blockchain is based on RBAC
model. The whole process is written in a smart Contract imported
from The OpenZepplin Library [1]. However, the automatic gen-
eration of the access control policy still missing. This automation
can widely enhance and simplify the implementation of access
control for developers of blockchain based applications. In this
paper, we propose a new model for automatically generating the
access control smart contract. Our approach is based on the
Model Driven Engineering (MDE).
Index Terms—Smart Contract, Model Driven Engineering,
Blockchain, Access Control, Ethereum, Solidity.
I. I NTRODUCTION
B LOCKCHAIN was introduced by Satoshi Nakamoto in
2008 [2] to overcome the lack of trust in banks caused
by the financial crisis. So he presented the new cryptocurrency
Bitcoin. It allows the transfer of financial transactions with-
out the need of third-party. Blockchain guarantees security,
transparency and immutability of transactions.
In fact, Blockchain is used to store a verified and time
stumped transactions between participants in a peer-to-peer
network without going through a trusted third-party.
This technology is based on four mechanisms: (1) the
cryptography, (2) the distributed and decentralized ledger, (3)
the consensus and (4) the smart contracts. In this paper we
are interested in the smart contract mechanism, that appears
in 2011 to improve blockchain technology. The smart contract
defines the business process that includes the requirements,
conditions and events to execute a transaction. Smart contracts
can be created to manage the Business logic, the asset storage
and to grant more security for the transferred transactions.
Security includes many properties such as privacy, integrity,
authentication, authorization, etc.
In our work, we are interested in the access control property.
The access control is the mechanism that determines who has
permission to get access to the resources or the services in
a system. In the literature, many access control models exist.
However, in the Blockchain context the most used models are
RBAC (Role Based Access Control) and ABAC (Attribute-
based access control). The Ethereum Blockchain is based on
the RBAC model.
2641-8169/21/$31.00 ©2021 IEEE
DOI 10.1109/WETICE53228.2021.00020
zed licensed use limited to: MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE. Downloaded on April 16,2022 at 13:23:55 UTC from IEEE Xplore. Restriction
Samiha Ayed
University of Technology of Troyes
LIST3N-ERA, Troyes, France
samiha.ayed@utt.fr
In fact, the RBAC [3] model use roles to decide which users
are privileged to reach certain resources. Users can be users
having accounts in Ethereum Blockchain or they can also be
contracts. A secure contract must respond to this requirement:
only contracts and users with a privileged role can get access
to the verified contract.
To build a correct and a secure smart contract we must
do it from the beginning and from the design stage. The
integration of Model Driven Engineering in smart contracts de-
velopment has proven good results [4]. The approach consists
in generating smart contracts automatically. Thus, it reduces
the programming language understanding complexity. It also
allows the reuse of code and models through giving better
clarity of a system then a code. In this paper, our focus is made
on the Ethereum blockchain technology. The actual smart
contracts generation used within this technology is based on
the OpenZepplin library. The generation of the smart contracts
using this library is not including the generation of the access
control policy that may be included within a smart contract.
To complete this aspect, we propose a MDE approach to
automatically generate access control within the Ethereum
blockchain smart contracts. The contributions of this work are
as follows:
• We propose a model for the access control in Ethereum.
• We create a profile that includes the concepts of RBAC
model and the Solidity syntax.
• We implement a proof of concept of Solidity smart
contract generation.
The paper is organized in four sections. The related works
dealing with smart contract engineering and access control in
Ethereum Blockchain are discussed in the section II. In section
III, we present our model as well as the implementation of
our approach. Section IV concludes the paper and presents
the perspectives of our work.
II. R ELATED WORK
A. Smart contract engineering
A smart contract is a computer program that executes
transactions automatically in a Blockchain. Clack and al [5]
define a smart contract as "an automatable and enforceable
agreement. Automatable by computer, although some parts
45
 may require human input and control. Enforceable either by
legal enforcement of rights and obligations or via tamper-proof
execution of computer code".
As any software, smart contract has a development life cy-
cle. In [6] authors presented four steps: creation, deployment,
execution and completion. that we summarize as follows:
• Creation: to create a smart contract, the involved parties
must define the clauses of the contract by negotiating
the obligations, rights, prohibition and agreement. Then,
computer developers implement the contract with a com-
puter language and validate it. So this step is an iterative
procedure starting by designing the architecture, coding
and testing.
• Deployment: during this phase, the smart contract is de-
ployed in the Blockchain network and cannot be altered,
so any correction requires the generation of a new smart
contract.
• Execution: a transaction calls the execution of a smart
contract when all its conditions are satisfied. After that,
miners should validate the transaction.
• Completion: after the execution and the validation of a
transaction, assets are transferred to their new owners.
During this step, the states of the parties are updated and
the contract comes to its end.
The development of a smart contract is a complex task,
especially that smart contracts cannot be altered after the
deployment phase. So the code source of the smart contract
must be correct from the design. In fact many works proposed
the integration of Model Driven Engineering (MDE) for the
generation of smart contracts. The Model Driven Architecture
(MDA) is composed of four levels that are as follows: CIM
(Computational Independent Model), PIM (Platform Indepen-
dent model), PSM (Platform Specific Model) and the Code
generation [7].
In literature, three different approaches exist: works based
on BPMN, others on UML modeling and some works based a
the finite state machine. In this paper, we discuss, as example,
the most recent work from each category.
The use of BPMN was proposed in many works [8]-[9].
In [8], authors developed a tool named Lorikeet that allows
the code generation of Solidity smart contracts. This tool
is divided in three parts: the first one is the modeling step
which is split on modeling Business logic used BPMN 2.0
and modeling asset registry based on UML class diagram.
The second part is the code generation where they trans-
late the BPMN and UML models into Smart contract, the
attributes and registry types become fields, the operations are
translated to methods and the BPMN will be the instantiation
of these methods and their logic implementation. The last
part is addressed to the Blockchain interactions which are
communication, deployment and compilation.
Other approaches were based on UML methodology [10]-
[11]. In [10], the authors proposed a methodology based
on an UML modeling to create smart contracts for het-
erogeneous blockchains, using Resources-Event-Agent (REA)
ontology, commitment-based smart contracts and the MDA
46
zed licensed use limited to: MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE. Downloaded on April 16,2022 at 13:23:55 UTC from IEEE Xplore. Restriction
(model driven architecture) guidelines. There are, also, other
approaches that used finite state machines [11]-[12]. In [11]
authors presented an MDA for the solidity smart contracts.
For the CIM level, they used the agent-based approach with
the grammar of institutions. For the PIM level, the state
machine approach was applied. Finally, for the PSM level, they
transformed the Finite state machine (FSM) into a Solidity
smart contract skeleton. Authors in [12] have created a tool
for generating Solidity smart contract from the state machine
models.
Discussion: We have noticed that most of the works were
focusing on the Solidity smart contract. This choice is mainly
due to the Ethereum blockchain that can support public, private
and consortium deployment. Another finding is that code
generation is not totally automatic in most of works so we
need the intervention of smart contract developer to implement
some logic methods. The other finding is that the integration
of MDE is designed to handle Business logic and/or asset
storage and doesn’t focus on security aspects such as privacy,
integrity and access control. Considering these findings we
propose, in this paper, to model the access control in Ethereum
Blockchain.
B. Access Control in Ethereum
Ethereum is a public platform, it was created By Vita-
lik Buterin [13] to build applications and smart contracts.
This platform supports many programming languages such as
JavaScript, Python and Solidity. These languages are running
through The Ethereum Virtual Machine (EVM).
The Ethereum bockchain is based on the proof of stake
consensus and its actors are EOA (Externally Owned Ac-
count), contract and miners. The EOA interacts with the
Blockchain via sending a message to another account on the
network which forms the transaction that will be stored in the
Blockchain.
The transaction data are the signature of the sender, the
address of the recipient, the transferred amount, the start Gas
and Gas price values as well as other data. The start Gas is
the maximum of gas required to execute the code and the
Gas price is the amount that must be paid to perform the
transaction.
The access control in Ethereum Blockchain is based on
three models developed by the OpenZepplin library [1]: (1)
the "ownable" contract, (2) the "Role-Based Access Control"
contract and (3) the "AccessControlEnumerable" model. The
Ownable contract is the basic form of access control where
the account of the contract owner is the administrator and
he is the only owner of the contract. 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. The last model called " AccessControlEnumer-
able" is added to the second contract when enumerability is
required.
 In the literature, apart from Openzepplin library, [14] and
[15] have also implemented the access control in the Ethereum
Blockchain. The implementation in [14] is called RBAC-SC.
The aim of this work is to realize the RBAC mechanism and
to verify the user role assignments. Therefore, the authors pro-
posed a model composed of two main parts: a smart contract
and a challenge-response protocol. The smart contract (SC)
is used for the creation of the user-role assignments, which
are then published on the blockchain. The challenge-response
protocol is used for the authentication of the ownership of
roles and the verification of the user role assignment.
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 user who has already been added in the SC.
• removeEndorsee(eu.EOA) function that can only be exe-
cuted by a user to remove an endorser from the SC.
• changeStatus() function can only be executed by the SC
owner or creator to deactivate the SC.
The challenge-response protocol is triggered when a user
requests a service corresponding to his role. The protocol has
five steps:
• Declaration: in this step, they define the user who is the
EOA with a role corresponding to a service issued in the
first part.
• Information Check: the service provider checks the infor-
mation of the corresponding user dealing about his role
and checking if he is the owner of the EOA.
• Challenge: The service provider chooses an arbitrary data
and requests the user to sign in using this data.
• Response: the user signs with EOA and the private key.
• Response Verification: if the verification is successful,
then the service will be provided.
The second Implementation of the access control in
Ethereum is Smart Policies [15]. This work is based on the
ABAC model. The authors propose to write the policies on
XACML and to translate them into Solidity smart contract.
The components of XACML standard such as 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) are defined
on top of the blockchain technology. The Context handler
(CH) is split on the off chain component and the blockchain
protocol. This approach is divided in two steps:
• New policy creation: during this step, the resource owner
writes a 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.
47
zed licensed use limited to: MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE. Downloaded on April 16,2022 at 13:23:55 UTC from IEEE Xplore. Restriction
Discussion: For our work, we choose to model the OpenZep-
plin implementation. The first argument of our choice is that
OpenZepplin implementation is considered as a standard for
Ethereum and compared to RBAC-SC and Smart policy, it is
performed totally on the blockchain. Moreover, the process of
the permissions and roles allocation is transparent and there
is no risk of malicious handling. Another motivation for our
choice is that OpenZepplin contracts are more flexible since
they provide three types of access control according to the
policy of the access control.
III. AC ENGINEERING FOR E THEREUM
A. AC Modeling using SecureUML
There are two extensions to model security concepts with
UML: SecureUML and UMLsec. In fact, SecureUML [16]
is an extension of the class diagram with stereotypes, tagged
values and authentication constraint written in OCL. UMLsec
[17] is a UML profile using stereotypes, tagged and authenti-
cation constraints without identifying the constraint language.
The two extensions are designed for the RBAC model. Figure
1 presents the elements of the RBAC model. Users can be
persons or systems, roles are the functions in an organisation,
operations are the set of actions that can be performed on the
protected objects or resources and permissions are the access
rules of operations to objects. In the RBAC model there are
two relationships. The first one is the user assignment that
presents the mapping between users and roles. The second
one is the permission assignment relationship that defines the
set of privileges allocated to a role.
Fig. 1. RBAC Model[3]
The difference between SecureUML and UMLsec is in the
stereotype signification. SecureUML is a specific modeling
language of the RBAC model. It defines stereotypes, such as
«user» , «role», «permission», «actiontype», «secureresource».
This means that SecureUML extends mainly the profile of the
UML class diagrams. UMLsec extends the whole UML profile
by stereotypes that are applied at multiple UML diagrams. The
«rbac» stereotype is the only extension applied in the activity
diagram.
For our work, we have chosen the SecureUML because in
term of quality measures, SecureUML presents better quality
than UMLsec according to the study presented in [18]. In fact,
authors gave a comparative study between the two models and
measured the semantic quality, the syntactic quality and the
pragmatic quality. For example, the percentage of covering the
RBAC domain is 100% and the percentage of security related
statement is 100% in SecureUML.
 Our proposed model is based on SecureUML concepts
to model the "Role Based Access Control" contract from
OpenZepplin library. In fact, we extended the UML profile,
called UMLtoSolidity [19], with new stereotypes based on the
RBAC modeling using SecureUML. In figure 2, we present the
stereotype extension mechanism added to the meta classes of
the Solidity profile (highlighted in purple).
We divide our approach into three steps: (1) the policy
contract modeling, (2) the role allocation modeling and (3)
the Solidity code generation. We also propose to put the two
first processes in the same smart contract to facilitate its mon-
itoring. Then, we suggest to represent the policy and the role
allocation as packages. Therefore, for each creation of contract
policy, the package role allocation is imported automatically.
To do so, we suggest to combine the SecureUML model with
the Solidity concepts.
1) Policy contract modeling: in this package we build
a class diagram that contain roles, permissions and
resources.
2) Role allocation modeling: this package is also based
on class diagram. Actually, as defined in OpenZepplin
[1], each role has its administrator. 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. Thus, he can do the same tasks as role
administrator and also he can set the role administrator.
3) Solidity code generation: in this step, we extend the
syntax of Solidity with the SecureUML concepts. In the
table 1 we give the combined concepts from SecureUML
and Solidity profiles and its representation in UML.
TABLE I
M APPING BETWEEN S ECURE UML-UML-S OLIDITY
SecureUML UML Solidity
Object Class Contract
User Class Account
Role Class Variable Byte32
Permission Class Association Function (call hasRole
function)
Operation Action in class Permission Function associated to role
Authorization OCL Permission Function body
constraint
UML modeling part, we used Papyrus Editor [21] and we built
our profile named OZProfile that combine the SecureUML
Profile and the Solidity Profile. For the code generation part,
we used the Acceleo code generator [22] to create a template
that let the mapping between OZProfile stereotypes and the
solidity syntax.
To validate our model we give the example of an ERC20 to-
ken [23] (fungible asset) contract modeled with our model. In
the figure 3, we introduce the two packages. The first package
is for policy which contains the Token as a contract, minter
and burner as roles. The second package is the RoleAllocation
that models the allocation of roles to the user accounts.
In figure 4 and 5 we expose the generated Smart contracts
that result from the mapping between SecureUML concepts
and Solidity syntax. Figure 4 demonstrates the protected
resource contract (MyToken) and figure 5 shows the access-
Control contract that corresponds to the role allocation.
IV. C ONCLUSION
In this work, we presented a model for the "Role-Based
Access Control" contract from OpenZepplin library. Our ap-
proach is divided into three steps: policy definition, role
allocation and Solidity code generation based on the mapping
between SecureUML stereotypes and Solidity syntax. Our
approach is designed to help developers without background
on OpenZepplin access control contracts to easily understand
it and to automatically generate it. The main advantage of our
approach is the simple reuse of contract.
For future work, we will enrich our code generation to
produce more generated code and to support OCL. We also
plan to integrate a Solidity editor and compiler to check the
source code and to build a plugin of our generator. Another
future recommendation is to perform a set of tests on a
Blockchain simulator to compute the gas consumed by the
generated contracts.

The protected resource or the object in SecureUML is

the developed contract. Users in Ethereum, as mentioned
before, can be users accounts or contract accounts which are
represented by their address. The roles are represented as
a Byte32 variable in the contract. The operations, that are
the actions in the RBAC context, are modeled as operations
in the association class stereotyped as «Permission». The
authorization constraints are the body of the action function.

B. Code generation
For the validation and the evaluation of our approach, we
have developed a proof of concept implementation of an access
control model generated in Solidity code source. We have
implemented our model in Eclipse Environment [20]. For the

48

zed licensed use limited to: MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE. Downloaded on April 16,2022 at 13:23:55 UTC from IEEE Xplore. Restriction
 Fig. 2. Stereotype extension mechanism

Fig. 3. ERC20 Model

Fig. 4. Generated Token smart contract

49

zed licensed use limited to: MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE. Downloaded on April 16,2022 at 13:23:55 UTC from IEEE Xplore. Restriction
 Fig. 5. Generated RoleAllocation smart contract

R EFERENCES language for model-driven security. UML 2002 - The Unified Modeling
[1] https://github.com/openzeppelin/openzeppelin-contracts. Language: 5th International Conference, Dresden, Germany,, 2002.
[2] S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. White [17] J. Jürjens. Secure Systems Development with UML. 2004.
paper, 2008. [18] H. Lakk R. Matulevičius and M. Lepmets. An approach to assess and
[3] S. Gavrila D. Richard Kühn D. F. Ferraiolo, R. Sandhu and R. Chan- compare quality of security models. Computer Science and Information
dramouli. Proposed nist standard for role-based access bontrol. ACM Systems 2011 Volume 8, Issue 2, Pages: 447-476, 2011.
Transactions on Information and System Security (TISSEC), 4(3), 224– [19] https://github.com/urszeidler/uml2solidity .
274, 2001. [20] https://www.eclipse.org/ide/.
[4] A. Ponomarev and A. B. Tran. Model-driven engineering for [21] https://www.eclipse.org/papyrus/.
blockchain applications. Architecture for Blockchain Applications, [22] https://www.eclipse.org/acceleo/.
https://doi.org/10.1007/978-3-030-03035-38 , 2019. [23] https://docs.openzeppelin.com/contracts/3.x/erc20.
[5] B. VA C. CD and L. Braine. Smart contract templates: foun-
dations, design landscape and research directions. Available from:
https://arxiv.org/pdf/1608.00771.pdf, 2017.
[6] M. Alharby and A. V. Moorsel. Blockchain-based smart contracts:
A systematic mapping study. Fourth International Conference on
Computer Science and Information Technology (CSIT-2017), 2017.
[7] A. R. da Silva. Model-driven engineering: A survey supported by
the unified conceptual model. Elsevier Computer Languages, Systems
Structures Volume 43, October 2015, Pages 139-155, 2015.
[8] I. Weber H. O’Connor P. Rimba X. Xu Q. Lu, A. B. Tran, L. Zhu
M. Staples, and R. Jeffery. Integrated model-driven engineering of
blockchain applications for business processes and asset management.
Software: Practice and Experience, 2020.
[9] W.Ingo M. Staples A. B. Tran, X. Xu and P. Rimba1. Regerator:
a registry generator for blockchain. CAiSE’17, Forum Track (demo).
Essen, Germany: Springer:81-88., 2017.
[10] K.Boogaard. "a model-driven approach to smart contract development".
2018.
[11] A Mavridou. and A. Laszka. Designing secure ethereum smart contracts:
A finite state machine based approach. Financial Cryptography and
Data Security, 2018.
[12] Yakindu statechart tools. https://www.itemis. com/en/yakindu/state-
machine, Online.
[13] V. Buterin. A next-generation smart contract and decentralized
application platform. Ethereum White Paper. Available online at:
https://github.com/ethereum/wiki/wiki/White-Paper/, Accessed in 02-11-
2020.
[14] 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.
[15] P. Mori D. Di Francesco Maesa and L. Ricci. Blockchain based access
control services.
[16] D. Basin T. Lodderstedt and J. Doser. Secureuml: A uml-based modeling

50

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