Distributed Bearer Token Redirect for Cloud Service Clusters

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing cloud service architectures face inefficiencies and reliability issues due to centralized authentication servers, which can lead to decreased responsiveness and single points of failure under high traffic loads, especially when users attempt to access different applications hosted on separate clusters.

Innovation Solution

Implementing a system where a first server system receives a bearer token for accessing the cloud service, determines if a resource is hosted by a different server system, and provides the token along with redirect information to the remote client, allowing the client to establish a session with the correct server system for accessing the resource, thereby distributing access requests across multiple server systems.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a centralized authentication server is used to authenticate users across multiple applications, then authentication coverage is improved, but system responsiveness deteriorates due to high traffic loads

Engineering Contradiction:
Improveauthentication coverageVSAvoidsystem responsiveness
Core Design Contradiction:
Adaptability or versatilityVSSpeed

Solution Approach 1:

The patent segments the centralized authentication server into multiple distributed authentication servers, each handling authentication for specific applications or clusters. This segmentation allows authentication traffic to be distributed across multiple servers, preventing any single server from becoming a bottleneck and thus maintaining system responsiveness while providing broad authentication coverage.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a new dimension to authentication architecture by implementing application-specific authentication routing. Instead of all authentication requests going through a single centralized server, the system adds a routing layer that directs authentication requests to appropriate distributed servers based on the application context, effectively distributing the load while maintaining comprehensive authentication coverage.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

2Adaptability or versatility

If a centralized authentication server is used to authenticate users across multiple applications, then authentication coverage is improved, but system reliability deteriorates due to single point of failure

Engineering Contradiction:
Improveauthentication coverageVSAvoidsystem reliability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent segments the centralized authentication server into multiple distributed authentication servers, each handling authentication for specific applications or clusters. This segmentation eliminates the single point of failure by distributing authentication functionality across multiple independent servers, so if one server fails, others continue to operate and maintain system reliability.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent changes the architectural parameter from centralized to distributed authentication server configuration. This parameter change transforms the system from having a single point of failure to having multiple redundant authentication servers, thereby improving reliability while maintaining comprehensive authentication coverage through the distributed architecture.

Inventive Principle:
Principle #35Parameter changes

3Speed

If different clusters host different applications with separate authentication, then system responsiveness is improved, but access versatility deteriorates as users cannot access applications on different clusters

Engineering Contradiction:
Improvesystem responsivenessVSAvoidaccess versatility
Core Design Contradiction:
SpeedVSAdaptability or versatility

Solution Approach 1:

The patent implements universal authentication tokens that can be used across multiple clusters and applications. Each authentication server issues tokens that are recognized by other clusters, enabling users to access applications on different clusters without re-authenticating. This multi-functionality maintains system responsiveness through distributed authentication while providing users with versatile cross-cluster access.

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

4Reliability

If authentication requests are distributed across multiple servers, then system reliability is improved, but system complexity increases

Engineering Contradiction:
Improvesystem reliabilityVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary component in the form of a directory service or token validation mechanism that coordinates communication between distributed authentication servers. This intermediary simplifies the system by providing standardized protocols for token validation and server coordination, reducing the complexity that would otherwise arise from direct peer-to-peer communication between multiple authentication servers while maintaining system reliability.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS9584615B2Redirecting access requests to an authorized server system for a cloud service
Publication Date: 2017.02.28 ADOBE INC
  • US9584615B2 patent drawing
  • US9584615B2 patent drawing
  • US9584615B2 patent drawing

AI summary

In some embodiments, a first server system of a cloud service can receive a bearer token for accessing the cloud service. The bearer token can be generated based on authenticating a remote client in communication with the first server system. The first server system can determine that a resource of the cloud service is hosted by a second server system of the cloud service rather than the first server system. The resource can be identified using the bearer token. The first server system can provide the bearer token to the remote client along with redirect information for accessing the second server system. The second server system can in respond to receiving the bearer token from the remote client by establishing a session with the remote client. The remote client can access the resource via the session with the second server system.