Keywords

1 Introduction

Access control plays an important role in the digital world. In any organization, including web service providers, not everybody has access to every piece of sensitive data. Rather, security rules are kept in place that allow only a select few to be given access to a subset of the data required for carrying out authorized activities. If all such rules and associated artifacts are maintained in a single central server, it becomes a soft target for the attackers and can lead to compromise of possibly sensitive data. Moreover, in some situations, the nature of the application is such that the credentials required for making an access decision are inherently distributed and bringing them together in a central location is neither feasible nor desirable.

As an example, a public library can subscribe to various journals, e-books and research databases using tax payer’s money. In return, valid state or city residents need to be given access to such e-resources. The access control rules in this case would specify which type of residents will have access to which kinds of e-resources. For instance, state resident university students may be given on-line access to journals while local school district students are allowed to access e-text books. It may be noted that it is infeasible for the library to store a priori the details of each member of the public at large. Rather it has to get the credentials certified by appropriate authorities at the time of making an access decision. Other pertinent example use cases would include providers of healthcare services where attributes of patients, primary care physicians, specialist doctors, insurance companies, etc., can be authorized on-line by various participating organizations for determining access to patient electronic health records (EHRs). This is especially true in Covid-19 like pandemic situations where physical verification of attributes is not feasible or even advisable.

While several alternatives have been developed over the last few decades, in this work, we consider recently proposed Attribute-based Access Control (ABAC) as the authorization model [1]. The reason for this choice is three-fold. First, it supports fine-grained access control. Second, it allows access to ad hoc users without any need for creating their login credentials in order to provide access, and third, ABAC subsumes almost all of the other existing access control models. Hence, the ability to support the ABAC model would establish the capability of supporting any other access control model.

ABAC processes access requests based on the notion of attributes. There are broadly four components in ABAC, namely subject (human user or agent making an access request), object (resource to be accessed like file, e-book, journal paper), environment (conditions under which an access request is being made) and operation (action that the subject attempts to apply on the object). Typical examples of operation include read, write, execute, open file, print. On the other hand, environmental conditions capture various operating conditions like time of access, location of origin of the request captured through the IP address, etc.

The most important characteristic of ABAC is that the subjects (interchangeably called users) are not given access on objects (interchangeably called resources) based on individual identities. Instead, a set of attributes and their possible values are associated with each of these. ABAC verifies the attributes against a set of rules (collectively called a policy) when a request is made by a subject to carry out a certain operation on an object in a particular environmental condition. The rules are also specified in terms of the attributes and not on identities. If there is a rule matching the attributes, access is granted to the subject to perform the desired action on the object; otherwise, it is denied.

In the context of a library service as mentioned above, an access request might come from a university student attempting to download a journal paper subscribed by the library and the request is originated from inside the university VLAN (Virtual LAN). Here subject is the student, object is the particular journal paper, operation is downloading and the environmental condition is the source of the access request identified as the university-specific VLAN.

As is evident from the above discussions, the various credentials (attribute values in ABAC terminology) of the users would typically be available with disparate authorities. It is also only these authorities who can certify the same for the user making the access request to a service provider. In the library use case, for example, the Department of Transportation (DOT) keeps track of the address of an individual from the information captured during issuance of driver’s license or state id. On the other hand, the university maintains the details of all on-roll students. Hence, the residency status attribute can be certified by the Department of Transportation (DOT) while the student status can be certified by the university. The service provider (in this example, the library) can get these attributes certified in a decentralized manner by the concerned authorities and then depending on its ABAC security policy, will determine whether to grant access.

With multiple parties thus involved in making the access decision, it is important that the decentralized authorization information is maintained in a manner that cannot be repudiated and also there cannot be any scope for wrongful denial of service. We propose to use a public blockchain, namely Ethereum, for handling authorization in ABAC based web services. A blockchain provides a decentralized means for storing information. It differs from traditional databases by storing the data in the form of blocks that are chained together. This decentralization plays a vital role in ensuring security of data as no single person or group can garner full control over it. Decentralized data stored on the blockchain is also immutable, which means changes made are recorded after verification that cannot be deleted or modified without everybody’s knowledge.

To the best of our knowledge, there is no work in the literature that precisely addresses this point, i.e., supporting decentralized certification of ABAC attributes for web services. In the proposed architecture, one or more organizations can assign attribute values for subjects belonging to itself. Over a period of time, these values can also be modified by the same organization. For example, the on-roll status of a student would change after graduation. On the other hand, it is the web service provider organization that serves as the custodian for all the objects under access control and hence, is responsible for assigning attribute values to the objects. The same organization also defines the set of rules or the ABAC policy against which all requested accesses are checked.

Besides proposing an architecture for blockchain based decentralized authorization in ABAC, we have also made a prototype implementation of the same on the Rinkeby test network of Ethereum. Efficient smart contracts were developed using Solidity for executing the various functions. Experiments have been carried out on the deployed system and the results are encouraging.

The rest of the paper is organized as follows. Section 2 reviews existing literature. In Sect. 3, we describe the design aspects of our proposed architecture. Section 4 discusses the implementation details along with an illustrative example. In Sect. 5, we present the results of extensive experimental evaluation of our prototype implementation. Finally, Sect. 6 concludes the paper.

2 Related Work

Unlike other models like Discretionary Access Control (DAC) [17, 18] and Role-based Access Control (RBAC) [19,20,21] which have been around for decades, proliferation of ABAC is yet to attain the same level of spread and maturity. However, there have been some attempts at its efficient implementation. The most straightforward approach from the point of view of ease of deployment is to store the attribute values of subjects, objects and environment along with the ABAC policy in a central database server that can be accessed only by a set of privileged administrative users [3,4,5]. This method is not sufficiently robust against attacks as it can potentially be compromised by sustained attempts from hackers. Once the attack is successful, the entire data can be stolen or modified in an unauthorized manner. Furthermore, verifying the correctness of the data also becomes difficult as the server logs can as well be overwritten.

Some of the state-of-the-art solutions advocate storing the ABAC system attributes and rules on the cloud. While physically distributed, logically it is not [2]. The cloud might provide a level of security from possible attackers, but its security is inherently limited to a single point of attack and therefore it is vulnerable to sophisticated attacks including insider attacks within the cloud.

Attempts have recently been made to make use of the unique characteristics of blockchains in bolstering existing access control systems. In one such method, the authors use Bitcoin-like blockchain [26] to create an access control scheme for smart home applications [7]. Each home has its own policy list that tells whether an internal or external person has access to the desired device. Even then in each individual home, access control is effectively centralized. While this approach may work well in this context, it is not suitable for large decentralized implementations of ABAC where any form of centralization is undesirable.

In addition to the above-mentioned approaches towards implementation of access control systems, there are also a few schemes where Ethereum smart contracts [6] are used to implement ABAC. A fairly recent work proposes an attribute based access control system using Ethereum where a smart contract is deployed for each subject-object pair to store the attributes, and implement an ABAC policy relating the specific subjects and objects [8]. When a subject needs to access an object, she initiates a transaction to the specific smart contract governing the subject and the object.

There also exist some blockchain based access control systems for extremely custom built applications, which make them difficult for general use [10,11,12]. In one such implementation, the URL of the policies is stored in the blockchain and a smart contract is used to receive the subject URL before processing the access control request [9]. However, in such an approach, the trustworthiness of the attributes cannot be maintained as these are stored in an external database.

In another alternative access control implementation using Ethereum and smart contracts, the object attributes are completely ignored as it is implemented for only multiple users-single object scenarios [13]. In a related but different context, [14] proves the correctness of smart contracts and deals with various verification methods for blockchain based smart contracts. In contrast to all of the above approaches, the architecture proposed in our work uses the idea of processing access requests and returning the corresponding decision to the user in such a way that the user gets this response instantly. Only after a few access requests have been processed, they are added to the blockchain [15]. A prototype has been implemented that use Solidity for writing smart contracts [16].

3 System Design and Features

The architecture of our proposed system is shown in Fig. 1. The design has several components including the service hosted by the organization maintaining the objects, multiple attribute authorities which verify the attributes of the users as well as the decentralized blockchain infrastructure. In the figure, the blue lines show the flow of adding attributes to objects, pink lines show the flow of adding rules, red lines show the flow of adding attributes to subjects while the dashed lines show the flow of access requests. The numbers given alongside different lines denote the sequential order of flow of transactions.

As seen in Fig. 1, objects and rules are added and modified by the object owner organization administrator using the object smart contract in the Ethereum cloud. At the same time, logs of the object and rule addition or modification are added to the blockchain for verification. Similarly, subjects are added and modified by the user organization administrator using the attribute authority smart contract in Ethereum while logs are added to the blockchain for verification. Next, as subjects send access requests through client applications, access requests are processed by the object smart contract. The object smart contract checks all the rules and determines whether to grant access or not. In the following sub-sections, we describe the complete system architecture by illustrating the four core working principles of this service.

3.1 Initial Deployment of ABAC Components

The web service provider, i.e., the organization that maintains the resources, first needs to identify the attributes and possible values of those attributes for all of its objects. Once this step has been completed, they can deploy their smart contract. This contract has an option to add new objects, remove objects, modify object attribute values, as well as add or modify ABAC policy rules. It also supports addition and modification of attribute authorities, i.e., other organizations who can verify the attributes of users attempting to access the objects hosted by the web service provider.

An attribute certifying authority uses its own smart contract running on the blockchain where it stores the attribute values of all the subjects registered under it. Since our architecture supports the presence of multiple such attribute authorities, each of them has its own smart contract deployed in Ethereum. These contracts are written in Remix using Solidity. Once deployed, anyone can access them using their deployment address. Blockchain also allows these contracts to communicate and share information among themselves. This feature enables implementation of the current structure with multiple attribute authorities that are independent but can communicate with the object organization to authorize the subject. As the actions are performed on the blockchain, an immutable chain of transactions is created which stores the information of every operation.

3.2 Processing Access Requests

A user who wants to initiate any access request, first authenticates herself to the system. She then chooses the set of objects and the actions to be performed on those. Next, she submits the request to the organization owning the objects through an appropriate smart contract. Once the smart contract of the object organization receives the request it first checks if it contains the object that the subject had requested to access. Next, the organization’s smart contract proceeds to verify the user attributes. As the different attributes can potentially have different and independent attribute certifying authorities, the object owner organization’s smart contract invokes the smart contracts of the appropriate attribute authorities to verify all the attributes of the user.

These verified subject attributes are then concatenated with the attributes of the objects that the user wants to access. Thereafter, the object owner organization’s smart contract checks if there is an ABAC rule that grants the desired access to the user. Based on the results of such rule evaluation, the user is notified if her access request is granted or denied. Blockchain plays an important role in this process as once an access request has been made, the request along with its outcome is logged in the blockchain. Since such records are immutable, the organization can always audit all the requests it has processed. Furthermore, the subjects will also know why they were denied access as all the attributes are also verifiable on the blockchain, thus, enhancing transparency in the whole process.

Fig. 1.
figure 1

System architecture

Full size image

3.3 Auditability and Verifiability

A blockchain is a distributed ledger consisting of a set of blocks chained together and stored in the nodes of the participating entities. Each block contains a cryptographic hash of the previous block and a set of transactions that represent the information to be written in the new block. Computation of the cryptographic hash is an involved process consuming both time as well as resources. If a transaction is altered with malicious intent, all the hash values of the subsequent blocks also will be changed on all the nodes present in the blockchain. This makes it computationally infeasible to alter blocks in the chain making a blockchain tamper-resistant. For decentralized authorization of ABAC attribute values by independent external entities, it is imperative that we protect the system against intentional denial of service while ensuring non-repudiation.

By writing the attribute value pairs of users into the blockchain, a certifying authority cannot later deny that it had indeed verified the corresponding user. Any potential granting of access arising out of such transactions would be solely the responsibility of the certifier. Also, inadvertent accesses can be easily detected and corrected through appropriate updating of the user attribute values. On the other hand, the service provider cannot deny access to a legitimate user without public knowledge since all the attribute values as well as the rules and the access decision (grant or deny) are written on the blockchain for public scrutiny at any point of time. We provide a functionality for such verification in a user friendly manner. Thus, any denial of service attack can be prevented in our approach. At the same time, if there is any unintentional denial of access happens, the same gets detected and necessary corrective actions can be taken by the service provider organization to update its ABAC rules.

Even though we store the attributes and policies as variables in the smart contracts, we use the emit function of Solidity [24] to make sure that every change is indeed logged in Ethereum. This native feature of Ethereum ensures that no access requests, rule and attribute modifications can be done without public knowledge. These logs consist of the event signature (Keccak256 hash of the event name including the data types of its parameters) and the topics (parameters) of the event. We add appropriate code in the smart-contract that logs all the transactions (subject additions, object additions, access requests and rule additions or removals). Once the transactions have been logged, these can be verified by a Python code using the Python library Web3 to iterate though all the logged transactions belonging to the organization’s smart-contract. These logs can also be filtered using the event signature to identify the ones specific to access requests, rule additions or subject additions.

3.4 Flexibility, Scalability and Privacy

Two of the principal advantages of the proposed architecture are its flexibility and scalability. For the users to be given access, there is no need to add them beforehand. Instead, the smart contract lets the administrators add the users even after the contract is deployed in the system. Furthermore, the user attributes can be modified later if required, and the set of objects available for access to that user may get appropriately updated based on the ABAC rules covering the original set of attribute values and the new set. The same structure applies to the smart contracts storing the object attributes and hence provides similar advantages. There is also the option of adding new attribute authorities in a rapidly evolving environment like the healthcare system in a pandemic situation. This way we ensure that the system can be expanded indefinitely.

On the other hand, since our architecture does not store the details of all the users from all the organizations desirous of using the service provided by the web services hosting entity, it is highly scalable. The web services host only needs to maintain attribute information of its own resources and the ABAC rules. Similarly, the subscribing organizations keep authentication information of their respective users. Finally, the attribute certifying authorities are concerned only with the particular user attribute they are certifying and not all the other attributes used for access control. It may be noted that most of these pieces of information managed by each of the entities are anyway available with them and are not added as an overhead for supporting the decentralized authorization process facilitated by blockchain in the proposed architecture. Hence, the system is scalable by design.

It may be noted that we store the attributes directly in Ethereum. Since it is a public blockchain and anyone can see its information, the attributes issued by the authorities are visible to everyone in the blockchain. These credentials often contain personal information like driver license, voter id., and hence, can lead to privacy leakage. For ensuring privacy, instead of directly storing attributes, attribute hashes can be stored with an appropriate verification mechanism.

4 Prototype Implementation

We next describe the details of a prototype implementation of our proposed architecture as presented in the previous section.

4.1 Implementation Details

We first coded the smart contracts of the service provider organization and also of the attribute certifying authorities in Solidity, which is a high-level programming language for writing and developing smart contracts on Ethereum. The basic functionality such as the ability of the service provider organization contract to connect with the attribute certifying authority and read the attribute value pairs accurately was next tested in Ganache by running the test cases using Mocha. Once all the test cases were successfully executed, the smart contracts were deployed in the Rinkeby test network [23], which has the complete functionality of the Ethereum main network, using the online Solidity compiler called Remix [22]. Deploying the smart contracts on Rinkeby enabled us to get real time test results such as the average time taken to process an access request.

Next we proceeded to connect to the Rinkeby network for reading the transaction information stored in its blocks. This is necessary for building the capability of transaction verification in case disputes arise, thus achieving non-repudiation and defense against denial of service attacks. To accomplish this, we use Infura [27], a service that allows to connect with the Ethereum blockchain without requiring setting up one’s own nodes.

Finally, to verify all the transactions (rule additions, attribute value modifications as well as access request decisions), we use a Python library named Web3 [25]. It facilitates interaction with the blockchain, going through the list of all the blocks stored in the nodes, and filtering out the transactions related to our contracts.

4.2 Illustrative Example

In this sub-section, we take an illustrative example to explain the functioning of the complete system developed by us.

Consider there is a shared library that provides on-line document access services to two universities/institutes. The library maintains a collection of electronic documents (journal papers, e-books, etc.) as files and hence, these serve as the objects in the context of an ABAC model. The library also has a set of rules defining the access control policy for these objects. Let the two institutes be named as Institute 1 and Institute 2, having their own independent set of users serving as subjects in the ABAC system. For the sake of brevity, we consider a limited number of values for each ABAC component as enumerated below.

Each user is assigned three user attributes, namely (i) Unique identifier of a user in her own institute like 1A, 1B, 2A, 2B (ii) Designation like Student, Teacher and (iii) Department like CSE, ECE, ME, EE. Each file is assigned three object attributes, namely (i) File Name, (ii) File Type like Journal Paper, E-book, Conference Paper and (iii) Sensitivity of the file like 1, 2 and 3. Each rule is comprised of four attributes, i.e., Designation, Department, File Type and Sensitivity.

There are two smart contracts used to deploy this system - one for the library service provider and one for the institutes. First, the institutes deploy their own institute smart contract to add users and their attributes. It has two main functions, namely (i) users along with their attributes and (ii) Modify attributes of users. For simplicity, we consider four users each in Institute 1 and Institute 2. For each such user, her attributes are given by the corresponding institute administrator using the institute smart contract. Representative values of the users and their attributes are shown in Table 1.

Table 1. Users of two institutes and their attribute values
Full size table

The library service provider deploys the library smart contract to add files and their attributes along with the set of rules (ABAC policy). The library smart contract has four core functions as enumerated below.

i. Add files along with their attributes

ii. Modify file attributes

iii. Add rules for accessing files

iv. Process incoming access request of users

Table 2. Objects and their attribute values
Full size table

We consider three files in the library. For each file, the attributes are assigned by the library administrator using the library smart contract. These are shown in Table 2. Notice that the journal paper, i.e., File 1, has been given a higher sensitivity value as compared to the e-book or the conference paper, while the conference paper File 2 has higher sensitivity compared to File 3. The library administrator also lists a set of rules specifying who should be given access to these files and adds them to the ABAC security policy. A policy of six rules is shown in Table 3. These rules are designed as per the current requirements of the library and may be modified as the need changes. The library is now ready to handle access requests originating from the users of both the institutes. A few access requests processed by the library smart contract along with their results are shown in Table 4.

Table 3. ABAC security policy with a set of six rules
Full size table
Table 4. Results of access requests along with rule number that grants the access
Full size table

In the first row of the table, the user 1A, who is a student of the ECE department of Institute 1 (Refer to Table 1) is requesting access to read File 2, which is a conference paper with sensitivity 2 (Refer to Table 2). Since, Rule 2 (Refer to Table 3) specifies that all students of ECE department can read any conference paper with sensitivity level 2, the access is granted and the rule responsible is Rule 2. On the other hand, in the second row, when a user 1A from Institute 1 is requesting access to read File 1 with sensitivity 3, there is no rule giving such a permission in Table 3. Hence, the access is denied. The corresponding rule is denoted as Not Applicable (NA) in the table.

Other access requests are also similarly processed by the designated smart contract. Here we considered only a limited number of attributes of users and files, as well as a few rules and two institutes for illustration. In a realistic environment, there will be multiple attributes for users and objects and several institutes can share the library resources using this decentralized system. Since the logs of all the modifications are stored in the Ethereum blockchain as transactions, we can audit the access requests, modification of user and file attributes as well as rules, making the operations secure.

5 Experimental Results

After deploying the prototype implementation of our architecture on the Rinkeby test network of Ethereum, we carried out an extensive set of experiments to evaluate its performance. Specifically, we studied the Gas cost associated with the execution of the contracts and execution time for each type of request that can be invoked in the system. Priced in small fractions (called gwei or naneth) of the Ethereum cryptocurrency ether, gas is used for allocating resources of the Ethereum Virtual Machine (EVM). It enables smart contracts to execute in a secured yet decentralized fashion.

Table 5 shows the gas cost and the time taken to deploy the contracts for the library service provider (Object Owning Organization) and the institute (Attribute Certifying Authority). It may be noted that these are one time costs as they are incurred only during the initial deployment of the smart contracts. Even then, the time taken is of the order of a few seconds. It demonstrates the ease with which the contracts can be deployed.

Table 5. Gas cost and execution time for initial contract deployment
Full size table
Table 6. Gas cost of transactions made in the Institute smart contract
Full size table

Tables 6, 7 and 8 show the gas costs associated with the functions of the institute and library smart contracts while Table 9 shows the corresponding execution time. It is observed that adding attributes for the first time for user or file takes more gas compared to changing the attributes later. The elapsed time between a user requesting for access and receiving the result is denoted as the execution time, which is approximately 0.20 s as seen in Table 9. Thus, on an average, 5 access requests per second, i.e., 300 access requests per minute can be processed by the prototype library smart contract. Table 10 shows the verification time for each of the actions performed in the system, It is defined as the time required to go through the blocks and verify the changes done in each action. We iterate from block 0 to the latest block to verify the transactions. This can be further sped up by iterating from the block which contains the transaction of the contracts being created.

Table 7. Gas cost of transactions made in the Library smart contract
Full size table
Table 8. Access request decision and corresponding gas costs
Full size table
Table 9. Results on execution time
Full size table
Table 10. Results on verification time
Full size table

6 Conclusion and Future Directions

This paper proposed an ABAC based framework for web service provider organizations to maintain objects and get user attribute verification done by several sources in a transparent and immutable manner using a public blockchain, namely, Ethereum. We have implemented a prototype of the system on the Rinkeby test network demonstrating how the executed transactions can be verified if a need arises. Detailed experiments show quite encouraging results.

Our ongoing and future work will be focused along multiple aspects of enhancing the blockchain supported decentralized authorization framework. The first goal is to reduce the total cost of implementing the service by optimizing all the functions through a reduction in the total gas cost. Secondly, in the current architecture, we store the data in the cloud storage allocated to a smart contract and the logs in the blockchain. An alternative possibility to explore is how to store data directly in the blockchain for additional security. A third possibility is to store the data elsewhere (instead of in the Ethereum cloud) and the logs or the hashes of the data in the blockchain. This can help to further reduce the cost as significantly less space would be used in Ethereum.

A privacy enhancement that can be done is that, if the attribute issuing authority and the web service provider are part of a consortium, they can build an access control system restricted to themselves. Rather than being part of a public blockchain, they can join a permissioned blockchain created for themselves. This would improve performance and access handling throughput.