Cross-Domain Service Authorization via Border Router Mediation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional systems do not efficiently facilitate interaction between service providers from different trust domains, leading to cumbersome user experiences and security concerns, such as requiring multiple logins and relying on signaling protocols like OAuth that necessitate specific client applications and multiple round-trip messages.
Innovation Solution
A service authorization system that uses primary and secondary tokens to enable access across trust domains, where primary tokens authenticate users within their trust domain and secondary tokens define access privileges for resources on other service providers, allowing seamless interaction between service providers in different trust domains.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional authorization systems are used between service providers in different trust domains, then security is maintained through strict domain boundaries, but interaction efficiency deteriorates requiring multiple logins and round-trip messages
Solution Approach 1:
The patent introduces a trust domain border router as an intermediary component that sits between different trust domains. This border router receives authorization requests from service providers in one trust domain, validates them against the home domain's authorization policies, and forwards appropriate requests to the home domain. This mediator enables cross-domain authorization without requiring direct trust relationships between all service providers, thus maintaining security while improving interaction efficiency.
Solution Approach 2:
The authorization system is segmented into distinct functional components: local domain service providers, border routers at domain boundaries, and home domain authorization servers. This segmentation allows each component to perform its specific function independently - service providers initiate requests, border routers manage cross-domain communication and initial validation, and home domains make final authorization decisions. This modular architecture improves efficiency by distributing authorization logic while maintaining security through clear separation of concerns.
2Reliability
If multiple logins are required for accessing resources across different service providers, then security credentials are verified at each domain, but user experience deteriorates with cumbersome authentication processes
Solution Approach 1:
The system performs preliminary authorization actions by establishing trust relationships and authorization policies in advance between home domains and foreign domains. When a user needs to access resources across domains, the border router has already pre-configured the authorization framework, allowing it to quickly validate and forward requests without requiring the user to perform multiple login actions. The authorization decision framework is prepared beforehand, enabling seamless cross-domain access.
3Adaptability or versatility
If signaling protocols like OAuth are used for cross-service authorization, then standardized authorization flows are established, but system complexity increases due to specific client application requirements and multiple message exchanges
Solution Approach 1:
The border router is designed as a universal component that can handle multiple types of authorization requests from different service providers and forward them to appropriate home domains. It implements a generic authorization framework that works across different trust domains without requiring domain-specific client applications. This multi-functional border router simplifies the system by providing a single, standardized interface for cross-domain authorization rather than requiring separate implementation for each service provider pair.
Data Source
AI summary
An approach is provided for authorizing one or more services from service providers in a communications network. The approach includes receiving a request from a first service provider, the request having an associated primary token and a secondary token identifier, the secondary token identifier relating to resources of a second service provider. Based, at least in part, on the secondary token identifier, a secondary token is identified; and then the secondary token is sent to the first service provider, wherein the first service provider and the second service provider belong to different trust domains and the first service provider can use the secondary token to access resources of the second service provider.