Browse Prior Art Database

Distributed Cross System Authorization

IP.com Disclosure Number: IPCOM000241740D
Publication Date: 2015-May-27
Document File: 5 page(s) / 173K

Publishing Venue

The IP.com Prior Art Database

Abstract

This disclosure presents a system and method to share authorization information between several application systems. After accounts have already been associated with each other on the application system, resources between multiple accounts on different application systems can be shared. This system is distributed which means no central node is required. The resource sharing is processed by the application systems automatically without client participation. The duration of existence of the cross system authorization is configurable and sustainable.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 38% of the total text.

Page 01 of 5

Distributed Cross System Authorization

As cloud and big data technology develop, not only individuals but enterprises have stored their data and deploy their applications or services on different system. How to consolidate resources that are available to single user or share resources/services between different users become a problem.

An individual may have an account for a cloud storage service which holds the data and another accountfor an application service that can perform data analysis. Since the services are provided by different providers, the user has to authenticate with each service providers to access required service. For instance, if a user wants to analysis data that store on a cloud storage service, each service provider needs to authenticate the user before allow the service be accessed.

Consider the following scenario: There are two cloud service providers named as 'sys1' and 'sys2'. A user has account on both services which is 'user1' for 'sys1' (labeled as 'user1@sys1') and 'user2' for 'sys2' (labeled as 'user2@sys2'). This user wants to do some data analysis. However, the data analysis logic is deployed on 'sys2' and the target data is stored on 'sys1'. With existing system or technology, there are many methods to perform the work. Following are some examples:

1. The simplest and most straightforward method is user download target data from 'sys1' with the user account 'user1' to local. Then upload the data to 'sys2' with account 'user2'. After that the user can perform the data analysis logic on 'sys2'. The drawbacks of this method are both download and upload action are take time. If the data is extremely large and the connection to the cloud service is poor, it may take days and weeks to finish. If the data is consist with a large number of files, tables or any other kind of format, download and upload action need to perform as many times as the numbers.

2. There are services that provide data sharing capabilities. User can put data into shared mode and the cloud service will generate a unique URI for it. However, the URI doesn't associate with any accessible information which means anyone could access the shared data by this URI. During share action, user may define a password for the sharing. But this method isn't a sound security way to put the target data into an assessable mode.

3. User could expose the user account 'user1@sys1' and password to 'sys2'. Then 'sys2' could direct connect to 'sys1' with it. However, this will compromise user account security for 'sys1'. Most people don't trust to expose one user account for one system to another system.

4. If both services are provided by the same organization, there could be an SSO service for accessing different services. People couldn't expect only use service from one provider.

The disclosed invention proposes a distributed cross system authorization mechanism to overcome the difficulties. By associating 'user1@sys1' and'user2@sys2', user could direct...