Microservice Trust Ledger for Decentralized Authorization

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In cloud computing environments, managing microservice trust relationships and ensuring secure inter-operation among distributed microservices is challenging due to the decentralized and dynamic nature of container deployments, which requires a robust and automated trust management system to prevent rogue services and ensure compliance.

Innovation Solution

A computer-implemented method that receives a microservice join request with trust relationship information, determines consensus among other microservices for authorization, and creates validated local run-time inter-operational trust relationship information, using a distributed microservices trust ledger for secure and automated trust management, enabling efficient inter-operation and real-time connectivity.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If decentralized trust management is implemented to allow dynamic microservice deployments, then adaptability is improved, but security and trust validation become more difficult to maintain

Engineering Contradiction:

Improvedynamic deployment flexibilityVSAvoidtrust validation consistency

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

Each microservice independently maintains and validates trust relationships using its own copy of the distributed ledger, autonomously verifying credentials and service description parameters without requiring centralized authorization, thus achieving both flexibility and consistent security validation

Inventive Principle:

Principle #25Self-service

Solution Approach 2:

The trust management system is segmented into distributed copies across multiple microservices, where each node maintains its own ledger of trust relationships. This segmentation allows independent trust validation while maintaining system-wide consistency through distributed consensus, resolving the contradiction between decentralized flexibility and security reliability

Inventive Principle:

Principle #1Segmentation

2Reliability

If real-time trust validation is performed for every microservice connection, then security is improved, but processing time and system performance deteriorate

Engineering Contradiction:

Improvesecurity validationVSAvoidconnection establishment time

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

Trust relationships are established and validated in advance before microservices need to inter-operate. The distributed ledger pre-stores validated trust information, allowing microservices to quickly reference and verify pre-established relationships without performing time-consuming real-time validation during actual connections

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The patent replaces complex real-time cryptographic validation mechanisms with simpler lookups of pre-validated trust information stored in the distributed ledger. Instead of performing intensive security checks at connection time, the system substitutes this with efficient retrieval of already-validated trust relationships, significantly reducing processing time while maintaining security

Inventive Principle:

Principle #28Mechanics substitution (Replace mechanical system)

3Reliability

If centralized trust management is used to ensure consistent security policies, then trust validation consistency is improved, but system complexity and single point of failure risks increase

Engineering Contradiction:

Improvetrust validation consistencyVSAvoidsystem architecture complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The centralized trust management function is segmented into distributed copies across multiple microservices. Each microservice maintains its own copy of the trust ledger, eliminating the single point of failure while preserving consistent security policies through distributed consensus and synchronized ledger updates

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

Instead of relying on a single centralized authority, the system creates and maintains multiple copies of the trust validation logic and data across the distributed microservice architecture. Each node holds a copy of the trust ledger, enabling parallel validation and eliminating dependency on a single central system, thus reducing complexity while maintaining consistency

Inventive Principle:

Principle #26Copying

Data Source

PatentUS11126697B2Microservices inter-operational trust management

Publication Date: 2021.09.21 INTERNATIONAL BUSINESS MACHINE CORPORATION

AI summary

A microservice join request is received by a first microservice from a second microservice within a microservices system. The microservice join request includes microservice trust relationship information of the second microservice that defines microservice credentials and service description parameters of the second microservice. Using the microservice trust relationship information, a determination is made as to whether a consensus exists among other microservices within the microservices system that the second microservice is authorized to inter-operate within the microservices system. In response to determining that the consensus exists, validated local run-time inter-operational microservice trust relationship information is created.