Access Control in Enterprise Blockchain Solutions
Blockchain deployment in enterprise setups is much more than just the blockchain network itself. In an enterprise setup, multiple systems and data sources need to be integrated with the blockchain to get the desired results. A blockchain in enterprise systems is used to provide an additional verification and agreement layer, on top of existing systems, to reduce conflict and achieve data reconciliation without the need for audits.
Think of a supply chain system using a blockchain (there’s a reason I didn’t call it a supply chain blockchain) to reconcile data between a manufacturer, warehouse, and retailer. For this system to work, it would require integration of data sources, identity systems, middleware at each of these supply-chain partners with their blockchain node. The blockchain would then act as the agreement and settlement layer on top of the existing system. In general, there would be several employees in each of these organizations interacting with this system as users. Just like in any other enterprise system, there would be a need to control access permissions for these users in this blockchain-based system too.
When designing blockchain solutions, the goal is to maximize throughput while reducing complexity by putting the minimum amount of data on-chain. Ideally, only the data and logic critical to verification and settlement using blockchain should be put on-chain, and everything else should stay in the existing systems. With this design goal in mind, we should put only a critical subset of the access control logic and permissions on-chain. This blog post is mainly about identifying this subset of the access control logic and the reasons behind that. Let’s dive deeper.
Two Types of Permissions
In the context of an enterprise blockchain system with multiple organizations participating in the process, there are broadly two kinds of permissions that should be controlled. First of all, the user needs to prove whether they belong to the organization on behalf of which they are sending a transaction. Secondly, the organization needs to prove whether the transaction the user is sending is supposed to be sent from this organization or not.
Intra-Organization Permissions (off-chain)
The first kind of permissions where the user needs to prove that they belong to the organization or not can be done easily using conventional access control mechanisms. For example, if two users are working for the manufacturer then one of them may be allowed to use the system and the other not. It is up to the organization to decide who has access to the system on behalf of the organization. It could be achieved using the organization’s access control mechanism, something like Active Directory. When the user logs in, they will be authenticated and authorized to use the system based on the rules defined by the organization.
Inter-Organization Permissions (on-chain)
The second kind of access control that is needed to be done is for the blockchain to check whether the organization sending the transaction has a particular role/authority to send that transaction or not. For example, in the supply chain scenario, only the manufacturer organization and associated users and keys should be able to create a product on the blockchain. The warehouse and retailer organizations should not be allowed to create new products. They should only be allowed to change the state of a product from manufactured to shipped to sold. Now for this kind of inter-organization access control, these permissions are required to be stored on the chain. The reason being these organizations do not trust each other, and that’s why they are using blockchain in the first place. They also cannot rely on each other’s identity management system to have the cross-organization permissions too.
For example, let’s say the manufacturer’s Active Directory is responsible for access control for all organizations. In such a scenario the users from the retailer and the warehouse organizations will also need to pass through manufacturers' Active Directory for sending transactions to the blockchain. This clearly makes a single point of control and failure at the manufacturer’s side and hence these cross-organization permissions cannot be put in a centralized system. They must be on the chain.
To sum it up, there will be two kinds of permissions controlled in such an enterprise blockchain scenario. Intra-organization permissions will be stored in each organization’s access control or user management system, and the inter-organization permissions will be stored on the blockchain.
Example Scenario
The following figures depict such an enterprise blockchain scenario where both off-chain and on-chain access control is needed. For simplicity and continuity, I am using the same supply chain example with manufacturer, warehouse, and retailer as the organizations participating in the system.
Let’s assume the manufacturer organization uses Active Directory, the warehouse organization uses OpenLDAP, and the retailer organization uses Apache Directory Service as their access control systems. All three organizations use different access control systems for identity and user role management of their employees. Once an employee is granted access, they can then send transactions to the blockchain (and use other functions of the system) on behalf of their employer organization.
On the other hand, the blockchain will have the inter-organization permissions coded in smart contract logic (or as part of the state transition function). Initially, just like the users are set up in off-chain access control systems, the organizations' associated accounts (public keys) would be set up (mapped) in the smart contract logic for on-chain access control.
Lets elaborate on the same example - the manufacturer organization can only send transactions that can create or register new products. For this, there would be a specific function in the smart contract to register a new product or to create a new product instance. This smart contract logic will also check whether the transaction sender’s key/address should be allowed access to this function or not.
The last figure shows how an end-to-end solution would work with off-chain and on-chain access control.
To Conclude
The part where the permissions need to be checked for an organization by other organizations, that part stays on the chain and is fully decentralized. However, the part where the permissions are checked for users within an organization that part doesn’t have to be on the chain because it is an intra-organization decision to allow/deny users to use the system.
PS: Some of these thoughts/ideas came up while having a conversation with my colleague Steve Degosserie over a (virtual/online) drink on one of the lockdown evenings. Thanks, Steve.