Browse Prior Art Database

Microservice Data Parameter Validation Using Blockchain Disclosure Number: IPCOM000251195D
Publication Date: 2017-Oct-25
Document File: 2 page(s) / 11K

Publishing Venue

The Prior Art Database

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Microservice Data Parameter Validation Using Blockchain

In a microservices architecture, when a user interacts with an application via it's user interface it can result in an arbitrary number of microservice invocations as the desired operation is completed. For example, you have a banking application with which you want to transfer money from account 123 (which is yours) to account 789 (your friend's). After logging in to the system, you initiate the funds transfer, at which point these data items (account numbers and amounts) are passed through a number of microservices, ultimately resulting in the money being transferred from one account to another. However, only the first microservice has direct knowledge of the identity of the user, subsequent services only talk to other services and there needs to be mechanisms by which you can ensure the data is not altered or manipulated as it passes through services e.g. changing the amount or account numbers.

Two solutions in use today attempt to solve this problem. Signed JWTs: Uses public/private key technology to ensure that a JSON data structure

has not been altered. The problem with this solution is that it requires participants to share, and trust, the same PKI system in order to be able to validate that the data has not been altered. It is also not possible to add to the data structure without invalidating it or creating nested structures that all require validating. Even if validation is possible, then that will require additional network calls to check the key for revocation and then to validate the signature.

API Keys/HMAC: A mechanism by which trust is established between two microservices via a shared secret. It works by hashing the parameters/headers that are being sent from one service to another, and then encrypting that hash with the shared secret. Whilst this system avoids the need, and overhead of a shared PKI infrastructure, it does not stop a malicious service changing the data. It only guarantees that data between two services has not changed, not that it is valid data in the first place.

This article proposes that as each microservice is invoked, the data used for that invocation (headers, parameters etc.) are written to a blockchain. Any parameters that the service then provides when invoking a subsequent service are then also recorded as a blockchain entry. At any point in time, if a service wishes to ensure that parameters have not been altered e.g. the bank account specified in the first service invocation, then the blockchain is verified before proceeding. Data dictionaries and mappings can be used where necessary to map incoming and outgoing data items e.g. service one uses a parameter called ‘accnt’ and service two a parameter called ‘account’ - the mapping can tell the service that these are the same data item.

This article addresses the problems with the current solutions as: 1. The blockcha...