-AC (Access Control) is the process of ensuring that an authenticated user accesses only what he or she is authorized to do with respect to certain models and security policies. In business collaboration systems, services are designed to conduct actions requested by a customer, using service provider's infrastructure. In such context, the agreement on a conventional access management system is difficult because it will depend on different infrastructures and security policies implemented by each involved party. In this paper, we investigate the authorization process that manages permissions and rights of access to shared services in a federation of enterprises and we propose a solution based on the Ethereum Blockchain platform and the Attribute Based Access Control Model (ABAC) to define this authorization process.
Keywords— BlockChain, ABAC
Access
Control, collaboration,
Trust, I.
INTRODUCTION
Trust is a major factor in business collaboration. Managing trust involves complex and costly processes and brings its own risks to companies’ information systems because relying on trust often involves the presence of a “trusted” third party and may compromise the security. However, the lack of trust may lead to major business opportunities lose, for instance in “on the fly” collaboration. In such scenarios companies collaborate by conducting actions on each other’s’ system in order to achieve the common objective. One of the most interesting technologies that may resolve this dilemma is Blockchain. The Blockchain provides trust without a trusted third party. Blockchain is a technology that provides a decentralized “database” on a network that is scalable, secure, tamperproof, and accessible by each peer on the network. Thus, using Blockchain allows coping with both trust and data integrity issues. However, managing identity and access control in Blockchain based collaboration brings its own issues. Conventional methods to manage access control reach their limitations in such a context taking into consideration the constraints related to the Blockchain infrastructure on one side and the heterogeneous access control policies implemented by each involved party, on the other side. In this paper, we consider the authorization process that manages permissions and rights of access to shared services in a federation of enterprises. To do so, we propose a solution based on the Ethereum Blockchain platform and the Attribute Based Access Control Model (ABAC) to define this authorization process via smart contracts. To validate our proposal, we implement cross-organizations authorization process as a smart contract, which is deployed on the Testnet BlockChain of Ethereum.
The rest of the paper is organized as follows: in section II, we present the related works, mainly the different identity management models as well as the existent model of access management. In section III, we discuss the proposed solution and the motivation of the adopted models. The implementation of the proposed solution is presented in section IV where different scenarios are given also. Section V concludes this paper.
II.
The concept of virtual team or virtual company was born
in the 1990s to describe the new forms of management and
digital exchanges between teams or between companies. The
virtual organization is defined as "a temporary alliance of
independent, connected, geographically dispersed
organizations, institutions, industries, enterprises, etc.,
including a high level of trust, who collaborate and share
their resources and skills in order to respond to customer
requests "[
In this model, each service provider uses its own identity domain, that is, its own identity provider. A user must use a different ID and credential to authenticate with each domain. From the point of view of each identity provider, identity management is simpler. In addition, in case of identity corruption in an identity domain, the other service providers are not impacted. This model also allows to define a different level of security for credentials (length of the password, number of credentials to be presented, etc. . .) Indeed, the latter must repeat the steps of authentication and identification with each of the identity domains attached to the service providers. Therefore, he must manage and remember as many identifiers and information useful for authentication as services he must access. This increases the risk of forgetting or losing this information, especially for services that are rarely accessed. In addition, this situation can be a source of weak adherence to the organization's security policy, which will be deemed too restrictive.
Identity federation is defined as a set of agreements,
standards, and technologies that allow a group of service
providers to recognize credentials from other service
providers that belong to the federation [
In this model, only an identifier and a credential are used
by the service providers. Three examples of implementation
of this type of identity management [
In this model, a single entity acts as the identity provider for all service providers. The mode of operation is halfway between the isolated identity model and the federated identity model. With this type of implementation the single identity provider is a central and sensitive point for all service providers. Indeed, in the event of a failure or modification at the level of the identity domain, all the dependent entities are impacted.
The implementation of a meta-identity domain allows service providers to share information about identities.
The Single Sign-On approach is similar to an identity federation, but no identity match is required because there is only one identity provider. In this architecture, a user needs to authenticate only once (single sign-on) with a service provider. It is then authenticated de facto with other service providers. The Single Sign-On model can be associated with the identity federation model, allowing single-domain interdomain authentication.
For access management, the following model can be found in the literature and used in exciting systems.
1
The IBAC model [
In the case where the owner of an information system
should not be responsible for managing the underlying
security, MAC-type models can limit access based on the
sensitivity of the data. For this purpose, the target entities are
hierarchized in different levels of security called labels. Bell
and Level [
Unlike the IBAC model where entitlements are granted
directly to the user, in the RBAC model developed by the
National Institute of Standards and Technology (NIST),
permissions are assigned to roles. The management of
authorizations is then simplified. In addition, NIST proposes
several variants of the RBAC [
The model ABAC, defined in [
With the OrBAC model [
III.
PROPOSED SOLUTION
After reviewing the main identity and access management model, we focus on the requirements of our authorization process that manages permissions and rights of access to shared services in a federation of enterprises. The requirements include:
Providing trust between different members of the federation who do not know each other.
Denying any illegal access from outside the Federation, unauthorized access or no access agreement.
Decentralization of authorization process that prevents the risk of loss of access control that allows services to be stopped.
Today, one of the most important technologies used in the security field is the Blockchain. The Blockchain ensures trust without a trusted third party. Confidence is obtained by: • Validation of transactions added to blocks • For a transaction added to BlockChain, you cannot edit or delete.
Based on such technology, smart contracts are agreements between parties that are written in executable code on the Blockchain instead of being written in natural language,. The execution is then managed automatically by the BlockChain according to the conditions described in the contract.
We propose a solution based on the smart management system contracts. The idea behind this solution is to define an authorization process that manages permissions and access rights to shared services in a business federation. This process satisfies the requirements by providing trust between different members using Blockchain. It also denies any illegal access from outside the federation. With Blockchain, the decentralization of authorization process can be also done. All steps are done automatically from Smart Contracts, so no needs for a manager on the process.
Our solution is based on ABAC access management model explained earlier to define an authorization process that manages the permissions and rights of access to shared services in a business federation and the implementation is based on the Ethereum Blockchain platform.
Blockchain technology allows a distributed computing
architecture where the transactions are publicly announced
and the participants agree on a single history of these
transactions (or some kind of ledger) [
In this part we discuss and compare the access management models mentioned in related work section. In the IBAC model, access controls are based on an exhaustive list of entitlements for each authorized account. The complexity of ACLs increases according to the number of identities and the number of resources since it is necessary to exhaustively list the authorizations for each combination. The federation contains a large number of users so this model is not compatible with the federation of companies.
The RBAC model allows to reduce the list size of the authorizations. Access controls are performed on the roles assigned to the accounts. Application roles are granted based on the business profile. The difficulty lies in the completeness and the granularity of the roles. In fact, too broad roles admit too many rights and too small roles will increase the difficulty of administration. In the federation each user has a different right or permission so we did not use this template because of the granularity of the user roles. In the OrBAC model, permissions or prohibitions are based on contextual expressions defined according to the organizational structure of the institution. In our work, the federation defines the users that they have the right of access and we cannot define them in advance.
The MAC model relies on flow control. Constraints are defined on data and resources. The level of entitlement of an account then determines whether or not he has the right to access the information. In our process, we do not have constraints to define because the permission is provided according to the user.
In the ABAC model, access controls check the presence and value of application attributes defined at the account level. It is then possible to simulate the RBAC behavior by mapping the attributes on the definition of the roles. This model is the appropriate one for our process because according to the attributes of each user, access rights are given.
In 2013, Ethereum was proposed by Vitalik Buterin to create
a BlockChain-based distributed computing platform with the
capability of building and running decentralized applications
or smart contracts [
At the center of Ethereum is the Ethereum Virtual Machine (EVM), which can execute codes of arbitrary algorithmic complexity. Therefore, applications that are created using known programming languages, such as JavaScript, can be run on the EVM. To facilitate the execution of codes in the blockchain and to maintain consensus, the nodes of the network run the EVM and execute the same instructions. Computations in the EVM are payed in ether (ETH), which is the currency used in Ethereum.
Ethereum’s basic unit is the account. Ethereum uses two types of accounts: Externally Owned Account (EOA) and Contract Account. An EOA is controlled by a corresponding private key, has an ether balance, can send transactions (transfer ether to another account or trigger a contract code), and does not have an associated code. Similar to a Bitcoin address, an EOA is in the form of random numbers and letters, and therefore looks anonymous and can be shared publicly. A contract account (or simply called contract) has an ether balance and has an associated code. All actions in the blockchain are set in motion by the transactions created by EOAs. This means that the code in a contract is executed when it receives a transaction from an EOA, where the input parameters for the code execution are included in the transaction. Therefore, contracts can be considered as autonomous agents inside the EVM that execute a specific piece of code when poked by a transaction. Code execution in a contract can also be triggered by messages from other contracts (see the next subsection for detailed explanation on transactions and messages). In contrast to Bitcoins script, a contract performs Turing-complete computations and is typically written using some high-level language, such as Solidity, Serpent, and Lisp like Language. A contract's behavior is fully dependent on its code and on the transactions sent to it and therefore offers the possibility for creating decentralized and trusted systems.
An Ethereum transaction is a signed data package that stores
a message from an EOA to another account on the
blockchain. A transaction contains the Ethereum address of
the recipient, a signature that identifies the sender, the
amount of ether being transferred, an optional data field, and
startGas and gasPrice values. The startGas limits the
maximum amount of gas the code execution triggered by the
message can incur. And the gasPrice is the amount in ether
to be paid for one unit of gas consumed (see the next
subsection for detailed explanation on gas). When users
send transactions, they pay a small transaction fee in ether to
the network. This fee protects the blockchain from
malicious computational tasks, such as distributed
denial-ofservice (DDoS) attacks and infinite loops [
Ether (ETH) is Ethereum's native value token and is the
currency of the network. The sender of a transaction needs
to pay for the code it wants to execute, including
computation and data storage. When a code in a contract is
executed as a result of being triggered by a message or
transaction, every node in the network executes this code.
The cost of this execution is expressed in gas. Gas is
purchased for ether from the miners that execute the code
(miners are the nodes in the Ethereum network that receive,
propagate, verify, and execute transactions). Gas and ether
are decoupled because gas is supposed to be constant cost of
network utilization, whereas ether, and currencies in
general, is volatile. Therefore, even if the price of ether
increases, the gas price in terms of ether of executing a
function in a contract remains constant. Every
computational step that is executed in a contract or
transaction requires gas, and each transaction includes a gas
limit and a fee that it is willing to pay per gas. The price of
the gas is decided by the miners, and miners have the choice
of including the transaction and collecting the fee or not
(similar to the transaction fee in Bitcoin, wherein miners can
decide to get the fee or not). Ethereum clients automatically
purchase gas for the ether specified by the sender as
maximum expenditure for a transaction, and the excess gas
not used by the transaction execution is returned to the
sender in ether. Therefore, overspending on the gas is not an
issue because the user will only be charged for the gas
consumed by a transaction. Readers can refer to [
Transactions are grouped together in blocks, which are then added to the blockchain through the process called mining. The mining process uses a proof-of-work (PoW) system wherein miners all around the world use special software to solve mathematical problems. Blocks are connected and linked together to form a blockchain, where a new block is added to the block that came before it. Every block contains the hash of the previous block, and thus, creating a chain that connects the first block (genesis block) to the current block. The miner who solves a block is rewarded with ether (currently at 5 ETH). The cost of the gas used in the transactions that are mined, and an extra reward of 1/32 per uncle. Uncles are stale blocks with parents that are ancestors of the including block. Valid uncles are rewarded to increase the security of the network by neutralizing the effect of network lag on the dispersion of mining rewards. The PoW algorithm used in Ethereum is called Ethash (a modified version of the Dagger-Hashimoto algorithm) and requires a brute force solution i.e. miners scan and test for a nonce to find a solution that is below a certain difficulty threshold. The difficulty is adjusted accordingly so that it takes approximately 15 seconds to find a valid nonce. The Ethash PoW is a memory hard computational problem, that is, it is application-specific integrated circuit (ASIC) resistant and allows a more decentralized distribution of security (as compared to specialized hardware used by many mining pools that dominate the mining in Bitcoin). The security of the blockchain relies on this PoW system, which inherently means that a block cannot be modified without redoing the work spent on it, including the work spent on blocks chained after it. Therefore, an attacker will be outpaced by honest miners as long as majority of the overall computation power participating in the Ethereum network are controlled by honest miners. In this case, a block recorded in the blockchain is almost impossible to modify.
At the beginning, a necessary agreement by the entire federation member defines the rules for access to services and the requirement (attributes) by a user to obtain service access, this agreement is called Primary contract which is signed by all businesses.
First the attributes indicated in the agreement (main contract) are pre-loaded in the smart contracts, then each director (Local manager) records the users and their attributes. An access request is in the form of a Token request is created automatically after a comparison between the users attributes to the pre-loaded one. Token represents the permission and the right of access. The token contains the user's ID and address, date to expire, Token status, and delegation option fields. Depending on the attributes, the Token is created with different values. Different scenarios are given below.
• Scenario 1: Request a Service Access Token A user requests a Token to access a service. The Smart contract verifies the identity of the user from his ID and his address. The smart contract examines the attributes to give a request for access to the specific service from the pre-loaded conditions. If the attributes satisfy the conditions, a Token is created and returned to the user, otherwise the request is rejected. After having a Token, each access to the services is checked (verification of the expiration date and status of the Token).
• Scenario 2: Revoke an Access or User This is used to revoke an access of a user left the company or who changed status that does not allow preserving the old permissions. The local manager sends a revocation request containing "ID user" and Token to Smart contracts which in turn add the user and their Tokens to the revocation list.
• Scenario 3: Request service access To obtain a service provided in the Federation, an access request will be made by the user by presenting their "TOKEN ID" in the smart contract Verification which in turn verifies this Token (@user, ID user, expiry date and status of the Token) and returns access to the user. If the answer is negative the request is rejected.
• Scenario 4: Service Delegation If a user gives his Token to another user, when a service access request is made the Smart Contracts Verification Service takes the Token and the delegated user address and checks whether it is Token with delegation. If it is the case, the access to service is given.
• Component Diagram In our solution for this process, 5 components are proposed. Figure 2 illustrates the component diagram and relationships between components: • Service/Local User Manager: Its function is to add and identify all users of the company (ID, @, Attributes) and to manage add-on and revocations. • Owner Manager: Several people are authorized by the company to define the attributes for the creation of a Token and for the revocation conditions of the Token. • Smart contracts Add User: This Smart contract is preloaded by the data of all Users (ID, Attributes, address User). This Contract represents the core of the project because it includes the main database which allows any user to obtain access to the services. • Smart contracts Token: The intelligent contract allows the creation of Tokens by taking as input the Users ID. This Smart contract is pre-loaded with attributes (defined by Owner service). • Smart contracts Authentication/Service: it takes as input Token ID, then it checks if this Token exists in the BlockChain and if it is valid. If yes it provides the service otherwise the request is rejected. • Sequence diagram We show in Figure 3, the sequence diagram to present how the implementation functions and the different phases of our process are working. The process consists of 5 phase: 1. Loading policies phase to set the attributes in order to have an access service. 2. The second phase is to create User in order to add users of companies. 3. The third phase is create Token, which is responsible for giving users access to benefit from the services in the federation. 4. Access Service phase is the fourth to verify the token before giving the access. 5. Finally the revocations phase in order to revoke a user or expired token.
CONCLUSION
In this paper, we presented a new smart contract-based authorization management system. It manages permissions and rights of access to shared services in a federation of enterprises. We proposed a blockchain-based management system by adopting the ABAC access model. The blockchain is a machine used to ensure that the execution of transactions is carried out in strict accordance with previously established rules. So it's a kind of digital trust. According to the effectiveness of the platforms, we choose Ethereum as a platform for our solution. In the ABAC model, access control checks the presence and value of application attributes defined at the account level. In this solution, the confidence is obtained by: • Validation of transactions before being added to blocks • A transaction added to the Blockchain cannot be modified or deleted.
As future work, we will work to raise the level of security. More precisely, define other types of tokens and will come out of the general Token for all the service in a federation of companies in the specific Token at the same service level and develop this process to become more efficient.