Microservice Execution Order Enforcement via Chained Data Structures

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing microservice architectures face challenges in securing access to microservices, as each microservice provides multiple endpoints that are potentially vulnerable to attacks, and conventional security techniques may not effectively prevent unauthorized access even with service level tokens.

Innovation Solution

The proposed solution involves generating a session identifier for requests associated with executing microservices, identifying and maintaining execution plans that specify the order of microservice execution, and using chained data structures to track and enforce this order, thereby preventing unauthorized execution of microservices.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If conventional security techniques with service level tokens are used to access microservices, then access control is provided, but unauthorized access cannot be effectively prevented due to multiple vulnerable endpoints

Engineering Contradiction:
ImprovesecurityVSAvoidvulnerable endpoints
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The system performs preliminary actions by generating an execution plan that specifies the correct execution order of microservices before the actual service calls are made. This execution plan is created in advance and stored, allowing the system to verify subsequent service calls against the predetermined plan, thereby preventing unauthorized access before it can occur.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system implements feedback by tracking the actual execution order of microservices and comparing it against the predetermined execution plan. When a service call is made, the system checks whether it matches the expected order in the execution plan, providing continuous verification and blocking any deviations that would indicate unauthorized access attempts.

Inventive Principle:
Principle #23Feedback

2Adaptability or versatility

If each microservice provides multiple endpoints for access, then service functionality is enhanced, but security is weakened due to increased attack surfaces

Engineering Contradiction:
Improveservice functionalityVSAvoidattack surface
Core Design Contradiction:
Adaptability or versatilityVSObject-affected harmful factors

Solution Approach 1:

The execution plan mechanism serves multiple functions simultaneously: it defines the execution order, tracks service calls, verifies authorization, and blocks unauthorized access. This single multi-functional approach handles security for multiple endpoints without requiring separate security mechanisms for each endpoint, thereby maintaining service functionality while reducing the effective attack surface.

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Reliability

If execution order tracking is implemented using chained data structures, then unauthorized access is prevented, but system complexity increases

Engineering Contradiction:
Improveaccess controlVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system uses a nested data structure where each execution plan contains an array of service calls, and each service call is an object with properties including the service identifier and an index. This nested structure allows the system to track execution order efficiently by simply incrementing an index counter, avoiding the need for complex tracking mechanisms while maintaining reliable access control.

Inventive Principle:
Principle #7Nested doll (Nesting)

Data Source

PatentUS12212566B2Secure execution of microservices
Publication Date: 2025.01.28 DELL PROD LP
  • US12212566B2 patent drawing
  • US12212566B2 patent drawing
  • US12212566B2 patent drawing

AI summary

Methods, apparatus, and processor-readable storage media for securely executing microservices are described herein. An example computer-implemented method includes: generating a session identifier for a request associated with executing one or more microservices in a microservice architecture; identifying an execution plan for the request based at least in part on a plan identifier specified for a first one of the microservices, wherein the execution plan indicates a specified order for executing the microservices for the request; maintaining a set of chained data structures to track an execution order of the microservices based on the session identifier; detecting, based at least in part on the set of chained data structures, that the execution order of the identified execution plan does not match the specified order for at least a given one of the of the one or more microservices; and in response to the detecting, preventing at least the given microservice from being executed.