Zero-Trust Identity Management for Cloud Change Authorization

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional infrastructure as code models in cloud environments rely on high trust between components, concentrating risk and introducing burdens with IAM frameworks, such as preventing unauthorized changes, which complicates change authorization in CI/CD pipelines.

Innovation Solution

A method for identity and access management based on a zero-trust configuration, involving token retrieval from identity providers, change authorization from change management systems, and artifact retrieval from repositories, with a service broker executing changes within the cloud environment, using a control model for end-to-end evidence of pre-approval.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If conventional infrastructure as code models use high trust between components, then change authorization is simplified, but risk concentration increases and security control becomes burdensome

Engineering Contradiction:
Improvechange authorizationVSAvoidrisk concentration
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent segments the trust model by introducing multiple identity providers (IDPs) and distributed authorization mechanisms. Instead of relying on a single trusted component, the system divides authorization into discrete tokens issued by different IDPs, each validating specific aspects of change authorization independently. This segmentation distributes risk across multiple components rather than concentrating it in one authority.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces an intermediary layer of identity providers and token validation mechanisms between components. These intermediaries issue and validate cryptographic tokens that mediate trust relationships, allowing components to verify authorization without establishing direct high-trust relationships. This intermediary layer reduces risk concentration by preventing any single component from having absolute authority.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If IAM frameworks are used to prevent unauthorized changes, then security control is improved, but operational complexity and burdens increase

Engineering Contradiction:
Improvesecurity controlVSAvoidIAM framework complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements self-service mechanisms where components automatically validate cryptographic tokens and verify authorization through distributed IDPs without requiring complex centralized IAM framework management. The system performs self-validation of tokens and authorization credentials, eliminating the need for manual IAM policy management and reducing operational complexity while maintaining strong security control.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent replaces mechanical IAM framework controls with cryptographic token-based validation. Instead of relying on complex IAM policies, roles, and permissions that require manual management, the system uses cryptographic signatures and token validation mechanisms that automatically enforce security controls. This substitution reduces operational burden while maintaining or improving security effectiveness.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

Data Source

PatentUS12192360B2Method and system for facilitating identity and access management in a cloud environment
Publication Date: 2025.01.07 JPMORGAN CHASE BANK NA
  • US12192360B2 patent drawing
  • US12192360B2 patent drawing
  • US12192360B2 patent drawing

AI summary

A method for facilitating identity and access management in a cloud environment based on a zero-trust configuration is provided. The method includes retrieving, via a job, a token from a corresponding identity provider, the job including a unit of work and a unit of execution that corresponds to a change; retrieving, via the job, a change authorization from a change management system, the change authorization including a signed change authorization; retrieving, via the job, a change artifact from an artifact repository, the change artifact including a signed change artifact; requesting, via the job, a change orchestrator to execute the change, the request including the token, the change authorization, and the change artifact; instructing, via the change orchestrator, a service broker to execute the change; and executing, via the service broker, the change within the cloud environment.