Identity Cloud Authentication Bridge Redundancy for Hybrid Access

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing identity management systems struggle with secure access and unified security across hybrid cloud environments, including inconsistencies between on-premise and cloud-based applications, leading to potential security breaches and unauthorized access.

Innovation Solution

A multi-tenant identity cloud service with on-premise authentication integration, utilizing a microservices-based architecture and in-memory data grid cache callbacks to optimize request/response flows, implement high-availability, and support secure access across various channels and environments.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a single authentication bridge is used between on-premise active directory and cloud service, then system complexity is reduced, but system reliability and availability deteriorate due to single point of failure

Engineering Contradiction:
Improveauthentication service availabilityVSAvoidbridge configuration complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system segments the authentication bridge into multiple independent bridge instances (first bridge, second bridge, third bridge) that can operate autonomously. Each bridge is configured with the same on-premise active directory connection parameters, allowing any single bridge to fail without affecting the others. This segmentation resolves the contradiction by providing redundancy (improving reliability) while maintaining individual bridge simplicity (managing complexity through modular repetition rather than monolithic complexity).

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system changes the parameter of bridge quantity from one to multiple, and introduces a random selection mechanism for bridge routing. By varying the bridge selection parameter dynamically based on load or failure conditions, the system achieves high availability without requiring complex manual configuration of failover paths. The parameter change from single to multiple bridges with random selection resolves the reliability-complexity contradiction.

Inventive Principle:
Principle #35Parameter changes

2Reliability

If multiple bridges are used for on-premise active directory integration, then system reliability improves, but request processing time increases due to bridge selection and communication overhead

Engineering Contradiction:
Improveauthentication service availabilityVSAvoidauthentication request latency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs preliminary action by pre-configuring multiple bridges with identical on-premise active directory connection parameters before authentication requests arrive. The random selection of bridges is predetermined and configured in advance. This preliminary setup eliminates the need for real-time bridge selection logic during authentication, reducing processing time while maintaining the reliability benefits of multiple bridges.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system creates copies of the bridge configuration across multiple bridge instances, each with the same on-premise active directory connection parameters. This copying approach allows any bridge to handle any authentication request interchangeably, eliminating the need for complex load balancing or failover logic during runtime. The copied configurations enable fast, simple bridge selection (via random selection) while maintaining high availability.

Inventive Principle:
Principle #26Copying

3Productivity

If cache listener with filter is implemented to listen for target action response, then authentication performance improves through caching, but system complexity increases

Engineering Contradiction:
Improveauthentication request processing speedVSAvoidcache listener configuration complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The cache listener with filter implements self-service by automatically caching authentication responses and filtering requests based on predefined criteria. The system self-manages the caching mechanism without requiring external intervention or complex configuration. The filter automatically identifies which authentication requests should be cached based on their target action characteristics, eliminating the need for manual cache management while improving processing speed.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The cache listener implements feedback by monitoring authentication responses and using that information to optimize future request handling. The filter mechanism provides feedback about which requests benefit from caching, allowing the system to dynamically adjust its caching strategy. This feedback loop improves authentication performance while the automated feedback mechanism keeps the complexity manageable through intelligent rather than manual control.

Inventive Principle:
Principle #23Feedback

Data Source

PatentEP4029222B1Multi-tenant identity cloud service with on-premise authentication integration and bridge high availability
Publication Date: 2026.03.18 ORACLE INT CORP
  • EP4029222B1 patent drawingFigure 1
  • EP4029222B1 patent drawingFigure 2
  • EP4029222B1 patent drawingFigure 3

AI summary

Embodiments include a multi-tenant cloud system that receives a request for an authenticate action for a user. Embodiments create an authenticate target action and register a cache listener for a cache that includes a filter to listen for a target action response that is responsive to the authenticate target action, the filter listing a plurality of bridges assigned to an on-premise active directory. Embodiments randomly select one of the plurality of bridges and sends the authenticate target action to the active directory via the selected bridge. Embodiments wait for a cache callback and, at the cache callback, receive a target action response that includes a result of the authenticate action.