Multi-Tenant Identity Cloud Replication Conflict Detection and Resolution
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing cloud-based identity management systems face challenges in securely managing access across multiple environments, including public and private clouds, and ensuring consistent security measures for various user types, leading to potential security breaches and data inconsistencies.
Innovation Solution
A multi-tenant, microservices-based identity cloud service (IDCS) that provides unified access management, supports hybrid cloud deployments, and implements a stateless architecture for scalable and secure access across devices and applications, using token-based security and real-time/near-real-time task handling to ensure consistent security policies.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If data is replicated across multiple data centers to ensure availability and consistency, then system reliability is improved, but data conflicts may occur leading to information loss
Solution Approach 1:
The system performs preliminary actions by establishing a clear master-slave data center architecture before conflicts occur. The master data center is designated as the source of truth, and the slave data center proactively replicates data in a controlled manner, preventing conflicts before they arise rather than reacting after conflicts occur.
Solution Approach 2:
The system introduces an intermediary conflict resolution mechanism that intercepts and resolves data conflicts between master and slave data centers. This mediator ensures that only valid, non-conflicting data updates are propagated, preventing information loss while maintaining replication benefits.
2Reliability
If change event messages are pushed to remote data centers via REST API calls, then data consistency is improved, but system complexity increases
Solution Approach 1:
The system segments the data replication process into distinct components: change event message generation at the master data center, message transmission via REST API calls, and localized processing at the slave data center. This segmentation simplifies the overall architecture by dividing complex replication tasks into manageable, independent modules.
Solution Approach 2:
The system uses copying mechanisms where the slave data center creates a copy of the master data center's data and processes changes locally. This copying approach simplifies the replication architecture by allowing independent processing at each data center while maintaining consistency through controlled data duplication.
3Reliability
If multiple data centers authenticate and replicate client resources, then access security is improved, but processing time increases
Solution Approach 1:
The system performs preliminary authentication actions at the master data center before data replication occurs. By validating client credentials and establishing security contexts in advance, the system reduces the time required for subsequent authentication operations at slave data centers, as they can leverage the pre-established security frameworks.
Solution Approach 2:
The system maintains continuous authentication and replication operations without interruption. The master data center continuously pushes change event messages to slave data centers, ensuring that security checks and data synchronization occur in an uninterrupted flow, reducing total processing time compared to batched or intermittent operations.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Embodiments include a multi-tenant cloud system with a first data center and a second remote data center. The first data center authenticates a first client and stores resources that correspond to the first client, and is in communication with the second data center. The second data center authenticates the first client and replicates the resources. The first data center receives a write request for the first client, writes the write request and generates change event messages in a first order. The first data center pushes the change event messages to the second data center via REST API calls. In response to receiving the change event messages, the second data center is configured to write the change event messages in the first order to its local database.