Towards Supporting Attribute-Based Access Control in Hyperledger Fabric Blockchain

Abstract

Hyperledger Fabric (HLF) is an open-source platform for deploying enterprise-level permissioned blockchains where users from multiple organizations can participate. Preventing unauthorized access to resources in such blockchains is of critical importance. Towards addressing this requirement, HLF supports different access control models. However, support for Attribute-Based Access Control (ABAC) in the current version of HLF is not comprehensive enough to address various requirements that arise when multiple organizations interact in an enterprise setting. To address those shortcomings, in this paper, we develop and present methods for providing full ABAC functionality in Hyperledger Fabric. Performance evaluation under different network configurations using the Hyperledger Caliper benchmarking tool shows that the proposed approach is quite efficient in practice.

1. Introduction

A blockchain is a distributed ledger built on top of a decentralized peer-to-peer network, providing mechanisms for secure transfer of assets among its participants without the need for any intermediary. Transparency of the ledger combined with a secure execution platform provided by smart contracts has led to a widespread adoption of the blockchain technology across multiple industries. It has resulted in the development of novel applications in several domains like IoT, healthcare, supply chain, e-governance, etc.

There is no central authority in blockchains for monitoring user actions within the network. Hence, an access control mechanism needs to be exercised for preventing unauthorized access to the network resources, especially in enterprises. Some of the recent work [10,14,16,23] propose enforcement of access control models such as Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) for public blockchains like Ethereum. It may be noted that a public blockchain has no restriction on peers in joining the network. Any user can create a peer node on the network and access the data on the blockchain.

Hyperledger Fabric (HLF) [2], on the other hand, is an open-source tool for deploying enterprise-level permissioned blockchains. Unlike its public counterpart, a private blockchain introduces an additional authentication layer to control the users joining the network. Even though the users are authenticated, it is necessary to restrict access to the network resources for certain users, thus enforcing confidentiality and integrity policies. While other access control models are supported, HLF does not have any specific feature for aiding the implementation of ABAC. The only current feature of HLF that can be used is the concept of client certificates generated by certifying authorities. Most of the recent literature like [12] and [18] use the HLF network as an intermediary data store between off-chain users and resources for maintaining authorization related components. Some of the other work [9] considers only limited features of ABAC,

In contrast to such existing approaches, we propose a method for utilizing the full capabilities of ABAC in HLF. We targets the cases where clients on the network act as users and resource owners, and resources are stored directly on the blockchain. The key contributions of this paper are summarized below:

1. We develop a novel approach for supporting attribute-based access control over the assets managed in any Hyperledger Fabric installation by appropriately designing its components on the decentralized network.

2. We build a complete Golang library for implementing the approach on a Hyperledger Fabric network. Performance tests are run on workloads under different configurations using the Hyperledger Caliper benchmarking tool.

3. We make both the library and the docker network for deploying an ABAC-enabled HLF instance publicly available through GitHub for reproducibility of our results and supporting the open source initiative.

The rest of the paper is organized as follows. Section 2 introduces the key concepts related to HLF and ABAC. In Sect. 3, we present our approach for supporting ABAC functionality in HLF along with the developed libraries and the workflow for system setup. The implementation details and experimental results are discussed in Sect. 4. Section 5 reviews related work in this field. Finally, Sect. 6 concludes the paper and provides directions for future research.

2. Preliminaries

In this section, we discuss some of the background concepts that would help in understanding our research contributions in the later part of the paper.

2.1. Hyperledger Fabric

Blockchain [22] is a distributed ledger spread over a completely decentralized peer-to-peer network without any hierarchy. As the name suggests, a blockchain maintains a chain of blocks on the ledger recorded in chronological order linked using cryptographic techniques. Hyperledger Fabric¹ [2] is a framework for deploying permissioned blockchains with a modular structure with pluggable components for consensus mechanism, datastore, etc. HLF runs the component services in docker containers to isolate the application layer from physical resources. Any node needs to be authorized to enter the network. Figure 1 shows the overall structure of a typical HLF network. The main components are described below.

• Chaincode - Chaincode is the HLF term for smart contracts originally introduced in the context of Ethereum. A smart contract refers to the business logic while a chaincode refers to the deployable entity enclosing this logic. Chaincodes are the only entry points for users or applications to access the ledger.

• Peer - Peers are the client nodes on the network. They host the ledger, chaincodes, create/sign transactions and blocks.

• Orderer - These are the special nodes that ensure block delivery across the network to all peers using a consensus protocol for ordering the transactions.

• Organization (Org) - An HLF network can span multiple organizations, each controlling its peers on the network. Different organizations can contribute their resources to the network.

• Membership Service Provider (MSP) - It uses certifying authorities (CAs) to create and manage identities for network members. An MSP generates necessary authentication material for all the participants to join the network that qualifies HLF as a permissioned network. Different Orgs can have independent MSPs.

• Channel - It is a private subnet of communication among a collection of peers. A channel can include peers from multiple organizations. Every channel has an individual ledger which is replicated among all the peers on that channel.

• Ledger - Ledger contains the data and transaction history in the HLF network. An HLF Ledger has two components - a) Blockchain, which contains blocks with transactions chained to previous blocks by including their hash values, and b) World State, which is a ledger database describing the current ledger state. Any update to this state database is recorded on the blockchain.

• Client - Clients belong to specific organizations and are registered using that organization’s MSP to generate necessary certificates and key pairs for authorization to invoke the chaincodes on the network.

Fig. 1.

Structure of a hyperledger fabric network

2.2. Attribute-Based Access Control

Attribute-based access control [4,8] is a fine-grained access control model that decides whether to give access based on the attributes (characteristics) of the user, object and environment, as well as the requested permission. Access granting decision is built upon the concept of an access control policy, which is a set of access rules that are comprised of logical combinations of the above-mentioned attributes and their values. When an access request is made, the rules are evaluated with respect to the pre-assigned attributes. ABAC subsumes several other access control models as they are considered to be special cases of ABAC with appropriately defined attribute sets. For example, RBAC [19] can be implemented by embedding user-role relations into a user attribute called role and role-permission relations into corresponding rules in the access control policy.

In its general form, an ABAC system consists of five components - UA, RA, EA, OP, POL, each of which is described below:

• UA - Represents the attributes of users like identity, name, and other application specific attributes.

• RA - Represents the attributes of a resource. It includes resource ID, owner, confidentiality level as well as other application specific attributes.

• EA - Refers to environment attributes. It is used to capture context information like time of access, IP address of the requester, etc., which enables a fine level of control to be built in the access logic.

• OP - Refers to the type of operation on the resource that a user is requesting. The operations can be resource-specific like read, update, delete, etc. This ensures different levels of user control on the resource.

• POL - Refers to the access control policy of an organization. It is comprised of a set of rules, each defined in terms of the above-mentioned components. Based on the rules in POL, an incoming access request is either granted or denied.

An ABAC reference monitor intercepts every user request. It then retrieves the required attributes and matches them with the available policy. The request is further processed only if there is at least one rule in the policy that is satisfied.

3. Enabling ABAC in Hyperledger Fabric

While planning for ABAC support in HLF, having a traditional centralized reference monitor would defeat the very purpose of using blockchain technology, i.e., decentralized operation, trust independence, transparency and immutability. It would require a trusted third party to maintain and administer the reference monitor, making it susceptible to attacks, raising trust concerns and forming a source of single-point of failure in an otherwise distributed system. Hence, the access decision needs to be made in a distributed manner, involving all the network nodes and considering the majority decision. We take advantage of the inherent capabilities of HLF in obviating the above issues. It is felt that the blockchain ledger itself can be used to maintain necessary information related to access control including the complete history of access requests and their decisions. This is because the ledger is immutable and distributed across every peer, with consistency ensured by the consensus protocols. Such a design also provides a natural means for auditing, a desirable property of any reference monitor.

Besides designing the reference monitor, another major challenge from the perspective of supporting ABAC in HLF is how and where to securely configure the ABAC components, resources on the blockchain. After exploring various alternatives with their potential merits and demerits, we address this challenge by storing public attributes and policy on the ledger, while the sensitive-attributes and resources on certificates and private collections. It may be noted that directly implementing the policy logic in chaincodes would necessitate re-installation on all nodes for even a minor change in the policy. Instead, in the proposed design, a policy can be modified on the ledger without any overhead at other nodes.

Our approach focuses on designing a generalized access control framework for a set of organizations participating in the private blockchain. The users are all on-network peers and the resources are also stored on the network managed by owners internal to the network. A resource can be any type of asset supported by the blockchain. No external entity is involved at any step.

3.1. Configuring ABAC Components

We first explain how to configure and store different ABAC components on the HLF network. These can then be accessed and used for access decisions during a request. The proposed configuration for each component is described below.

Resource.

A resource can be of any type that can be stored on the blockchain, e.g., a restricted URL, file data, images, etc. While registering a resource on the channel state, the transaction contains its key-value information along with the timestamp. If this transaction is packed into a block and stored on the ledger, any user on the network would then be able to query the ledger to get this transaction and hence, the resource. To guard against such disclosure, we use a feature of HLF called private data that enables us to securely store the resource.

Private Data Collection -

It is a database maintained separately from the state database. This data is replicated through a gossip protocol only to the peers of respective organizations specified in the collection configuration. The ledger state at each peer for two representative organizations Org1 and Org2 is shown in Fig. 2. Any input data is stored in a transient storage at the anchor peers till it is successfully copied to all the peers. After replication, the hash value of the input data is written to the transaction on the ledger. This is useful while accessing actual data to validate that it is not tampered with. The resource data is available only to the peers of the respective organization. At least one node from the resource’s organization should be available to retrieve the resource. These collections can be accessed using the STUB API of HLF.

Fig. 2.

Ledger states for multiple organizations

A resource in the private collection is structured as a JSON object. When multiple MSPs are involved for different organizations, the same ID might get assigned to different clients across these MSPs. To circumvent the problem, we maintain the owner’s public key in the resource for resolving any ambiguity.

User Attributes.

We divide the user attributes (UA) into two subsets, namely (i) public attributes, denoted by UA_pub, that are shared among all the network users and (ii) sensitive attributes, denoted by UA_priv, that other network users cannot access. Attributes in UA_priv are stored on the client X.509 certificate generated by the MSP during enrollment. These X.509 certificates contain client ID, MSP ID, a public key and other subject related information. The generated client ID is unique within an MSP. We can also mention attribute-value pairs to be stored on the certificate during enrollment with MSP. These certificates are accessible to chaincodes through a CID library. In contrast, UA_pub attributes are stored on the channel state in the JSON format. They also have a pub-key field for resolving ambiguity when multiple MSPs are involved.

Resource Attributes.

We divide the RA also into two subsets, namely, (i) public resource attributes, denoted by RA_pub, that consist of visible attributes and (ii) private resource attributes, denoted by RA_priv, that consist of sensitive attributes. Attributes in RA_pub are stored on the channel state in JSON format similar to UA_pub. RA_pub also has a pub-key field for the same reason as mentioned above. As an alternative, the client ID and MSP ID pair from the certificate can also be used for verification since the combination is unique for every client. RA_priv has a similar format but is stored on the Org private collection, similar to resources, instead of the channel state. This is to maintain the required additional privacy to keep them hidden to users on the network.

Environment Attributes.

The environment attributes (EA) can be very specific to a use case. They typically need to be inferred from the context during an access request mediation. Chaincodes can be programmed accordingly to retrieve these attributes considering the requester details and the present context.

Access Control Policy.

POL, the access policy, consists of several rules. At least one of these rules needs to be satisfied for a user to be granted the desired access when requested. These rules are stored on the ledger in JSON format and can be added/deleted/modified whenever necessary only by the Admin user. As the rules are attribute-based in ABAC, giving resource owners the right to add rules might result in inadvertently granting of unauthorized access to other resources having the same attribute values. Each rule is comprised of ID, necessary attributes and a set of access constraints on UA, RA, EA and OP. All these constraints need to be valid for the respective rule to be satisfied.

Decision Unit.

It is mandatory for every user request to be intercepted by a decision unit (DU) for performing the access check. In an HLF network, interacting with the ledger is possible only through chaincodes. So having the DU as a chaincode with the resource access methods will require every user request for any resource to be made using this chaincode. This chaincode can then retrieve all the respective attributes, policies and validate the request.

Consider an HLF network for academic resource sharing within a university. Faculty (owners) can save classified data (resource) in a private collection on the network, registering attributes like ID, department, domain, etc., on the ledger based on sensitivity. Student (users) attributes like student id, department and year of study are registered on the certificates or ledger accordingly. When a student requests a resource, these attribute values are matched against the access constraints (e.g., same department, year of study >= 3, etc.), and the access decision is recorded on the ledger that can be audited if necessary.

3.2. Managing ABAC Components

To manage the ABAC components on the HLF network as proposed in Sect. 3.1, we have developed a Golang library and made it publicly available with detailed documentation². Table 1 lists all the available methods in this library. These methods can be used directly in the chaincodes by importing the library. To ensure that only an authorized client can carry out an activity, she has to digitally sign her identity in the request, which can be verified using her public key. Few methods are detailed in the following algorithms. The rest are also developed along similar lines and hence not repeated here for the sake of brevity.

Table 1.

Golang library methods

ABAC component	Related methods
Resource	addResource(), updateResource(), getResource()
User attributes	registerUAPub(), updateUAPub(), getUAPub() getUAPriv()
Resource attributes	registerRAPriv(), updateRAPriv(), getRAPriv() registerRAPub(), updateRAPub(), getRAPub()
Access policies	registerPolicy(), updatePolicy(), getPolicy(), getPolicySet()
Decision unit	getContext(), validateAccess()

Algorithm 1 takes resource ID, owner ID with digital signature ($\overline{\mathit{\text{owner}}ID}=\text{Hash}\left[\text{owner}\text{ID},\text{owner}\text{Private}\text{Key}\right]$), and updated private attributes (key-value pairs) for the resource as input and updates the RA_priv on the private collection. Here we refer to the client maintaining the resource as its owner. CID and STUB libraries are provided by HLF for retrieving user details and interacting with the ledger respectively. Steps 2 and 3 check if RA_priv for that resource is already registered. If not, it is added to the private collection in Steps 4 to 9. Steps 5 and 10 verify if the requester is the actual owner of the resource. In Steps 12 to 14, the RA_priv is updated with given input attributes and then written to the private collection. The transaction hash gets recorded on the ledger.

Algorithm 2 takes as input the resource ID, digitally signed user ID ($\overline{\mathit{\text{user}}ID}=\text{Hash}\left[\text{user}\text{ID},\text{user}\text{Private}\text{Key}\right]$), operation on the resource and resource collection. Here, a client requesting the access is referred to as the user. All the required attributes and policies are retrieved in Steps 4 to 13. Step 6 verifies user credentials to ensure that UA_pub belongs to the invoking client. Steps 13 to 17 check if the attributes satisfy any of the rules. If so, the resource is obtained from the private collection and returned to the user. Else, access is denied.

3.3. Execution Workflow

We now describe the workflow of our proposed design of ABAC in Hyperledger Fabric from setup to access mediation using Fig. 4. The Step 0 mentioned in the figure for deploying the blockchain is detailed below:

1. First, configure the CA and MSP for all the organizations to generate the certificates and identities. Next, configure the peer and the orderer nodes, and pack the respective certificates to enroll on MSP. Then, generate certificates for Admin using CA for each organization and enroll them on the MSP.

2. Define a private collection on each organization to store its resources. Configure the settings for these collections according to the requirement.

3. Create a channel for all the peers and orderers from different organizations to join. Next, install the chaincodes on the peers and approve them from necessary peers to commit the chaincodes to the channel.

Fig. 4.

Proposed ABAC workflow

While configuring peer nodes, we can use different services for the state database. By default, HLF provides two database services, both of which were duly considered by us for their relative advantages and shortcomings. The first one is GoLevelDB, a simple key-value store database that is embedded into the peer process and runs on the same peer container. The other is CouchDB, an external database that runs alongside its peer on a separate container. CouchDB is also a key-value store and supports all the features of LevelDB. As a document object store, it can maintain data in JSON format and also support indexing. This facilitates execution of complex JSON queries on the value field apart from the key queries. Such a feature helps during the auditing and reporting process.

After the blockchain is deployed (Step 0), Steps 1 to 11 in Fig. 4 specify the subsequent tasks to be followed for exercising access mediation. The Admin enrolls required clients on the MSP and stores their public attributes on the blockchain. These clients can act as both users and resource owners. Owners now add resources to a private collection and store or update the resource attributes on the blockchain. Admin registers the access control rules on the blockchain. When the user makes a request, it is processed by the Decision Unit (a chain-code), and the requested resource is returned upon successful verification.

Our approach makes use of the security guarantees of the HLF itself. No additional security flaw is introduced. HLF architecture is natively secure in terms of design, confidentiality and privacy [3]. It also ensures secure storage and execution of any chaincode making HLF robust in preventing manipulation of business logic during execution. Peer-to-peer communications are secured using the transport layer security (TLS). The TLS certificates and key pairs issued by the CA for peers and orderers are included in their respective docker containers deployed on individual machines. When interacting with a peer container, these certificates are used for both client and server authentication during the TLS handshake, thus ensuring network integrity. Thus, security in terms of local enforcement depends on the security guarantees of Docker and in particular the isolation properties of Docker containers.

Note that the administration is responsible for issuing or modifying user attributes, policy rules, etc. Any change to these components requires invoking respective methods within DU chaincode. When a user makes an access request, it reaches all the nodes in the network. At each node, the access decision is made independently after processing the request using the DU chaincode. The orderer nodes use consensus protocols to create transactions on the ledger through a majority decision. Thus, even if an attacker modifies the DU on his own node to grant access, the consensus will still need to be reached for acceptance. Similarly, when an admin makes a register/modify request for attributes, policy, etc., it also reaches all the nodes and is processed individually. While these transactions are endorsed by all the peers by default considering the admin credentials, they are still recorded on the ledger simultaneously on all the peers and can be audited.

4. Implementation and Experimental Evaluation

In this section, we first present the implementation details of our proposed approach in Hyperledger Fabric followed by experimental results under different scenarios. The performance is measured with the help of the Hyperledger Caliper benchmarking tool.

4.1. Network Implementation

First, we deploy a custom HLF network to test our approach with the help of chaincodes. This docker network prototype is being made freely available by us to the research community along with the detailed steps for its deployment³. We use virtual instances on the Google Cloud Platform to deploy this HLF network and record the latency observed by an instance that functions as an individual node on the network. Hyperledger Explorer⁴, an open-source web-based tool for visualizing the activities on the underlying blockchain, is used for tracking the deployed peers, channel state, and the recorded transactions on the network.

We initially deploy a vanilla smart contract (call it Reference Chaincode), which is a chaincode to store and return a resource without any access check. Next, we deploy a second smart contract (call it Proposed Chaincode), which has the full functionality of the workflow described in Fig. 4. It uses the developed Golang library to record the attributes, policy, resources, etc., and exercise access check before returning the desired resource. The Reference Chaincode acts as a baseline against which the actual ABAC enhanced chaincode (Proposed Chain-code) is benchmarked. This is to eliminate any idiosyncrasy in the network or system behavior due to the hardware or software configurations. It also lets us focus our study on the actual performance of the proposed access mechanism rather than the entire network itself. Both these chaincodes are included in the docker network being made openly available.

4.2. Performance Evaluation

To evaluate our approach, we build a synthetic dataset for the ABAC system. This dataset contains randomly generated attributes for users, resources, environmental context, and rules defined on these attributes. To execute these transactions from the Proposed and Reference Chaincodes on the HLF network, we use the open-source benchmarking tool Hyperledger Caliper⁵. We use CouchDB for the state database and Raft consensus for the HLF network as default. We consider 100 users, 100 resources and 50 rules on the network by default.

Any access request is originated from a user as a transaction for operating on a system resource. These transactions call the validateAccess() method described in Algorithm 2. For an accurate estimation of the additional latency introduced due to the access check, we record the difference in latency between access transaction execution through the Proposed and the Reference Chaincodes.

Figure 5 shows the variation in ABAC-mediated access latency with increasing number of concurrent transactions in the entire network. The latency values are averaged over 10 transactions as recorded on one of the nodes. It is observed that there is an initial lowering of latency, which is due to an increase in the number of transactions being packed into a single block on the ledger, resulting in a decrease in the latency for each transaction. After the transaction count in a block reaches its limit, there is a need to add more than one block and hence, the latency starts slowly increasing due to higher network congestion.

Fig. 5.

Variation in latency with network traffic

The impact of the number of different ABAC components on latency is depicted in Figs. 6a and 6b. In these figures, cardinalities of the other components are set to default values except for the ones that were varied. It is observed that change in the number of rules in the policy (Fig. 6b) has a higher impact than the number of users or resources (Fig. 6a). This is because increasing the number of rules requires processing of more access constraints unlike for users and resources, which requires searching a larger state space. Also, an equal increase in the number of resources results in a slightly higher latency than for users as seen in Fig. 6a. This is because in the first case, two of the components, namely, resources and RA, are increased compared to only UA in the latter case. Overall, from Figs. 5 and 6, it is observed that there is not much increase in latency in any of the situations. This shows that the proposed authorization step using ABAC contributes very little additional processing time compared to the default network transmission and ledger interactions.

Fig. 6.

Variation in latency with the number of ABAC components

For studying the impact of alternative design choices as discussed in Sect. 3, we vary the database service used for both channel state and private collections as shown in Figs. 7(a) and (b). In each of these, the result of one choice is shown as a ratio of the other. From Fig. 7a, it observed that GoLevelDB outperforms CouchDB mainly for access transactions in a general use case. This is because LevelDB runs on a peer, unlike CouchDB that executes in a separate container. As a result, the rate of information transfer, which is greater in an access request, is higher. In general, if the entire policy is to be considered, LevelDB is a better choice since it has lower latency. But in specific cases where only a subset of rules need to be verified based on the attribute set, CouchDB can be effectively used since it is more robust, supports indexing, richer queries.

Fig. 7.

Additional latency for different design choices

Figure 7b shows the performance comparison between the design choices of having all the attributes as public vs private. For keeping them as private, the access request latency is 56% higher compared to public. The same for register requests is 34%. This is due to relatively more interactions with the private space for access requests compared to the register requests.

Figure 8 depicts the resource consumption averaged over all the peer, orderer nodes. For both, there is a nominal difference in resource usage between the Proposed and the Reference Chaincodes, implying that the overhead of introducing ABAC is quite low. The difference is lower at the orderer node since only the consensus protocol runs at the orderer nodes and access control has no impact. As the actual access request is processed on the peer nodes, there is a minor increase in resource usage at peer nodee. Comparing Figs. 8a and 8b, it is observed that memory consumption is greater for orderers because they collect decisions from all the peers for running the consensus protocol. In contrast, access requests are handled at the peers, thus needing greater processing power.

Fig. 8.

Resource consumption for access requests at 200 Txns/s

In real-world applications, the networks are usually highly scaled-up with multiple organizations and peers. Hence, peer-to-peer communication would result for the major part of the depicted latency. As long as the network scales up with the cardinality of the ABAC components, the percentage of additional latency introduced due to access check over the default transaction latency will remain similar to that in the experimental results reported above.

5. Related Work

With a rapid proliferation of permissioned blockchains in large organizations, research on access control in this domain is also gaining pace. In this section, we review some of the related work in the literature.

Rouhani et al. [17] survey various state-of-the-art access control mechanisms for both public and private blockchains. Iftekhar et al. [9] detail an HLF network setup and chaincode installation process for implementing access control in IoT networks. Only user attributes from client X.509 certificates are considered to write access logic in chaincodes with no support for the other ABAC elements. Another secure data transmission method for IoT devices was proposed by Liang et al. [11] to test the private blockchain network communication performance and security factors for its compatibility in real-world use cases. Liu et al. [12] propose using HLF as an intermediary unit between the users and the IoT device resources. They use three chaincodes to manage policies, resource URLs and access control, respectively. Attributes are, however, not stored on the ledger. Instead, they are received with the request and verified using cryptographic techniques. We compare our work with other existing approaches in Table 2.

Table 2.

Comparison with the current state-of-the-art

Features	Our model	Iftekar et al. [9]	Liu at al. [12]	Stamatellis et al. [20]	Rouhani et al. [18]
Domain	General AC	IOT	IOT	Healthcare	General AC
UA	Private, Public	Private	Private	Private (only ID)	Private
RA	Private, Public	Private	Public	Private (only ID)	Private
EA	Supported	-	-	-	-
Pol	On ledger	In chaincode	In chaincode	-	On Ledger
Users	Network peers	External	External	External	External
Resources	Private collection	Off chain	Off chain	Off chain	Off chain
Benchmark	Caliper	Caliper	-	-	Caliper

Stamatellis et al. [20] propose another similar healthcare framework using HLF where the user id from MSP is used for verification using Idemix to provide anonymity. However, these frameworks lack the ABAC logical access components. A chaincode based access control, specifically for RFID systems, was proposed by Figueroa et al. [7]. However, only UA from the MSP Certs are considered and RA are stored on the state database. Access logic is directly written in chaincode. Thus, any update to the access logic requires re-installing the access chaincode making it quite inflexible. There are also a few other domain-specific models for IoT [5,13], cloud federation [6], edge computing [21], etc., using HLF similar to the above solutions though with certain variations.

Akhtar et al. [1] develop a blockchain-based auditable access control mechanism for distributed business processes where the access policy is encoded within the smart contracts. Rouhani et al. [18] propose a distributed ABAC system using the HLF network. Users and resources are considered external to the network. Only their attributes and policies are stored on the ledger using chaincodes. An enforcement point intercepts the user requests and redirects them to HLF. There is, however, no support for user certificates as the requester is not a client on the network. Also, only the public attributes are considered. The HLF network is used merely as an intermediary for deciding access rights. Marcus et al. propose a decentralized ledger-based access control [15] tested using an HLF network. The owner stores hashed resource and its access policy containing the public keys of allowed users (similar to ACL) on the ledger. A ring signature scheme is used to verify the requester’s id and reconstruct the resource upon access verification.

A critical review of related work highlights an evident lack of generalized and full ABAC support for Hyperledger Fabric. Most of the proposed solutions are either domain-specific or consider only limited ABAC features. Our work fills this gap and improves upon all the previous work by exercising a highly flexible, dynamic, and fully functional ABAC for Hyperledger Fabric.

6. Conclusions

In this paper, we have proposed a novel approach for supporting complete attribute-based access control functionality in a HLF network. We have detailed the underlying architecture and workflow for exercising access control through this method. An extensive evaluation using the Caliper benchmarking tool shows that the performance of this approach for different use cases is very promising. The additional overhead is within reasonable limits considering that security is significantly enhanced through ABAC. We also make the network prototype and the Golang library available to the research community through Github.

Future work in this area would include supporting verifiable credentials for providing ad hoc access for a requester external to the network by using her VCs as UA for policy evaluation. Besides, we plan to include support for more EA in the Golang library. We also aim to extend the library for other chaincode languages supported by HLF. This architecture is also generalized enough to support ABAC in any permissioned blockchain irrespective of the platform.

Fig. 3.

Deployment locations of ABAC components