BLOCKCHAIN BASED ACCESS CONTROL
Many startups have to justify why they need a blockchain for their idea. Why is there no other way? Why does it have to be this technology?
This question is being asked less and less because we have understood that in some cases the blockchain can be helpful for us. Blockchain gives us the ability to manage difficult business processes that were previously only possible through dirty and complicated workarounds. However, it is clear that this technology, despite its belief in it, is not a miracle tool for everything.
Many projects have (unfortunately sometimes very successfully) tried to sell old ideas and old products as new innovations by adding the blockchain data structure. In addition, they created a new problem that strangely could only be solved with their own token. But well, it’s kind of decentralized.
We don’t create problems, we solve them!
THE BASIC IDEA OF A PUBLIC BLOCKCHAIN NETWORK
The blockchain manages to store unique data and assets securely (with integrity) without the presence of a trusted third party such as a bank, even though an unspecified number of participants with unspecified confidentiality take part.
The (public) network of a blockchain is characterized by passing on signed transactions, which are accepted or rejected by consensus and confirmation of other participants. We make use of this mechanism.
Before I describe in more detail why Blockchain is the best choice for us, I would like to continue with a few key concepts to understand why our architecture is built that way.
ROLE BASED ACCESS CONTROL (RBAC)
Today’s systems often rely on Role Based Access Control (RBAC). The promise is to no longer bind authorizations to extremely static identities, but to dynamic roles, which in turn are assigned to identities, i.e. users.
The core concept is good, but not perfect, because it has been shown that the definitions of roles account for a large part of the effort, since they are the core elements. Users still get too many permissions through their roles and it is difficult to find a compliant and mostly automated solution based on (predefined) requirements.
USING RULES INSTEAD OF ROLES
You can use the Attribute Based Access Control (ABAC) for a more precise and predefined handling of authorizations through rules.
„Attribute-based access control (ABAC), also known as Policy-based access control, defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes etc.). This model supports Boolean logic, in which rules contain “IF, THEN” statements about who is making the request, the resource, and the action. For example: IF the requestor is a manager, THEN allow read/write access to sensitive data.
Unlike role-based access control (RBAC), which employs pre-defined roles that carry a specific set of privileges associated with them and to which subjects are assigned, the key difference with ABAC is the concept of policies that express a complex Boolean rule set that can evaluate many different attributes“1
We use a combination of a RBAC and ABAC solution: role-based to give users dynamic access to a resource and attribute-based to define what a modular permission can do with a resource (if needed). This brings highest flexibility. While it is possible to divide permissions into their modular parts, it is also possible to use standardized behavior patterns such as inheritance of permissions. The Intention, described by the concatenation of the operation and the object, is secured on the blockchain by an “intention-hash”, whereby a uniqueness of the authorization is ensured.
Authorizations (“permissions”) can be grouped into roles according to RBAC. Roles can contain subordinate roles. This allows us to quickly and efficiently assign a bundle of related authorizations (e.g. for a project or a specific position in a company). This avoids errors and optimizes processes, for example when onboarding new employees or entering new projects, for both internal and external employees.
AGAIN, WHY DO WE NEED BLOCKCHAIN FOR THIS? WHAT’S YOUR LOG?
By using the blockchain as a smart “Access Control List”, we are able to audit the list at any time while we can be sure of its data integrity. Today’s systems are not fully covered due to a lack of cross-platform functionality and manipulation-sensitive data structures. By iterating the blockchain transactions, it is also very easy to identify who had which authorizations at which times. Depending on the required security and privacy settings, any amount of information can be logged. For example, who accessed which resource at what time, or who passed on authorizations to whom. This complete protocol can never be manipulated and provides us a great added value for the auditing, while respecting data protection.
As inspired by the public network of a blockchain, which decentralizes responsibility and decision making and thus creates trust in a common and yet foreign network, we also want to decentralize the process for the allocation of authorizations (step by step). But what does that mean? Decentralizing administration?
This means that permissions can be requested by users and confirmed by other users. The difference is, they are not processed via a ticket system common today. The request is sent directly as a transaction into the blockchain network. For example, I (as an employee) need the permissions to configure a new Oracle ERP module or need to open the door of our meeting room because I booked it through our calendar. But completely independent of the data structure: Somebody needs to give me those authorizations, preferably as soon as possible. Who is able to do that? Of course, our admins! Why? We made them responsible because the processes did not allow a different workflow. However, today they do.
Now not only administrators have the possibility to answer these requests, instead any person who is really responsible for that can react. Those responsible can be different for various authorizations. For example, there may be project-specific or department-specific types of authorizations that should be managed by a project or department manager. Someone(s) are responsible for the Oracle ERP modules, another one(s) are responsible for smart locks of a department. Give shared access by shared responsibility. And also here the protocol comes into play, because every request and every confirmation is securely saved on the blockchain as a transaction.
How many and which confirmations are necessary for the successful assignment of authorizations can be determined by pre-defined requirements. These are conditions based on boolean facts like “certifier needs to own a specific attribute” (for example the abstract attribute “admin” or “projectmanager-project-x”). Smart automation (build by predefined smart contract code) can also be used to build trusted confirmations. This means, that smart contracts (on-chain execution) automate the process of assigning and revoking rights under specific conditions, which significantly reduces redundant and fault-prone work. The decision, if a condition (or a group of conditions) is fulfilled, is made distributed on blockchain so that no third party could compromise this process.
You see the blockchain can not only represent a smart Access Control List, but also a real “Access Network”. Shared access through shared responsibility based on an undeletable protocol, from which the current state of all authorizations can always be requested. — Isn’t that great?
WHAT BLOCKCHAIN DO YOU USE?
As Oracle Partner we build our first prototype on the Oracle Blockchain Platform. This is a Hyperledger Blockchain, which can be administered through the Oracle Cloud. Hyperledger makes it possible to create an enterprise blockchain network for your own company and beyond. It is a private/federated blockchain.
If you read the key concepts of Hyperledger, you will mention the “Certification Authority” (CA) and the “Membership Service Provider” (MSP) used to define and identify the approved members of the private or federated blockchain network. These CAs are mostly part of a company’s IT architecture and lets you easily integrate the Hyperledger in your personal environment.
1https://en.wikipedia.org/wiki/Attribute-based_access_control
header by unsplash.com/@belart84
icons by https://icons8.de
LET’S GET STARTED. BLOCKAXS TIME IS NOW.
