Context-Based Access Tokens for Fine-Grained Multi-Tenant Data Control

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing role-based access control (RBAC) systems in cloud computing environments lack fine granularity control over data access and usage, especially in multi-tenant systems, leading to inefficiencies and manual, disjointed processes due to static permissions and platform incompatibilities.

Innovation Solution

A three-phase context-based authorization process that generates context-based access tokens, converts them to cloud-neutral tokens, and then to cloud-specific tokens, dynamically creating temporary roles and policies for seamless data access across multiple platforms, ensuring fine-grained control and automation of permission management.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Manufacturing precision

If role-based access control (RBAC) is used to control data access, then data access control is implemented, but fine granularity control of data usage cannot be enforced

Engineering Contradiction:
Improvegranularity controlVSAvoiddata usage control
Core Design Contradiction:
Manufacturing precisionVSEase of operation

Solution Approach 1:

The patent segments access control into multiple phases (authorization phase, authentication phase, and usage control phase) rather than treating it as a single monolithic process. This segmentation allows fine-grained control at each stage, enabling precise control over data usage purposes while maintaining operational simplicity through automated phase transitions.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements dynamic access tokens that are automatically generated, updated, and revoked based on real-time context and usage conditions. These dynamic tokens replace static RBAC roles, allowing the system to adapt access permissions continuously without manual intervention, thus achieving fine-grained control without operational complexity.

Inventive Principle:
Principle #15Dynamics

2Manufacturing precision

If manual role changing is performed to enforce data usage purpose, then usage control is achieved, but the process is tedious and cannot scale

Engineering Contradiction:
Improveusage purpose controlVSAvoidscaling capability
Core Design Contradiction:
Manufacturing precisionVSProductivity

Solution Approach 1:

The system automatically manages access tokens through self-service mechanisms including automated generation, validation, and revocation based on predefined policies and real-time monitoring. This eliminates the need for manual role changes while maintaining precise usage control, allowing the system to scale without additional operational overhead.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent implements continuous feedback loops that monitor data usage in real-time and automatically adjust access permissions accordingly. When usage deviates from authorized purposes, the system detects this through feedback mechanisms and automatically revokes or modifies tokens, enabling scalable enforcement of usage policies without manual intervention.

Inventive Principle:
Principle #23Feedback

3Adaptability or versatility

If access control is configured for multiple cloud platforms, then platform compatibility is achieved, but system complexity increases

Engineering Contradiction:
Improvemulti-platform compatibilityVSAvoidaccess control configuration
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent creates a universal access token framework that functions across multiple cloud platforms (AWS, Azure, GCP) without requiring platform-specific configurations. The same token structure and validation logic work universally across different platforms, achieving multi-platform compatibility while minimizing system complexity through standardized interfaces.

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

Solution Approach 2:

The system introduces an intermediary layer (the standardized access token mechanism) that sits between the application logic and various cloud platform authentication systems. This intermediary handles platform-specific adaptations internally while presenting a unified interface to users, thereby achieving multi-platform support without exposing complexity to end users or application developers.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Ease of operation

If static permissions are granted via RBAC, then data access is enabled, but permissions cannot be dynamically adjusted for changing purposes

Engineering Contradiction:
Improvedata accessVSAvoiddynamic permission adjustment
Core Design Contradiction:
Ease of operationVSAdaptability or versatility

Solution Approach 1:

The patent replaces static RBAC permissions with dynamic access tokens that are automatically regenerated and updated based on changing usage contexts. These tokens have embedded expiration times and scope limitations that adapt to evolving requirements, allowing easy data access initially while maintaining the ability to dynamically adjust permissions without reconfiguration.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS12537824B2Fine granularity control of data access and usage across multi-tenant systems
Publication Date: 2026.01.27 SALESFORCE INC
  • US12537824B2 patent drawing
  • US12537824B2 patent drawing
  • US12537824B2 patent drawing

AI summary

System and method for fine granularity control of data access and usage for across multi-tenant systems. A user makes a request to access a particular set of data from a particular remote data source for a specific purpose. The system authorizes the user to validate whether the user is qualified to make the request. The data source is checked to see if the particular data has been granted access for that particular purpose. A cloud neutral token is created and converted into a cloud specific token upon reaching the remote data source. The cloud specific token is used to create a temporary IAM role and IAM policy with a predetermined time to live. After the time to live expires, the IAM role and IAM policy are deleted.