Key-based cross domain registration and authorization

The present invention generally relates to computer security, and more specifically, related to registration and authorization cross multiple domains. In an aspect, a computer-implemented method, computer-implemented system, and computer program product for cross domain registration by a source domain is provided. A request is sent by a source domain to register the source domain as a trusted domain of a target domain. An approval of the request is received by the source domain. The source domain issues a key to an application of the source domain for accessing the target domain.

BACKGROUND

The present invention generally relates to computer security, and more specifically, relates to registration and authorization across multiple domains.

SUMMARY

In an aspect, a computer-implemented method for cross domain registration by a source domain is provided. In this method, a request is sent for being registered as a trusted domain of a target domain. An approval of the request for being registered as the trusted domain is received. A key is issued to an application of the source domain for accessing the target domain.

In another aspect, a computer-implemented method for cross domain authorization by a target domain is provided. According to the method, a request to register a source domain as a trusted domain of the target domain is received by a target domain. The request to register the target domain is approved. The target domain receives both a key of an application of the source domain for accessing the target domain and a token identifying the source domain. The target domain checks validity of the key and the token. In response to both the key and the token being valid, the access from the application of the source domain is allowed.

In yet another aspect, a computer-implemented system for cross domain registration by a source domain is provided. The system comprises one or more processors, a memory coupled to at least one of the processors, and a set of computer program instructions stored in the memory and executed by at least one of the processors in order to perform a method comprising the steps of sending a request for being registered as a trusted domain of a target domain. An approval of the request for being registered as the trusted domain is received. A key is issued to an application of the source domain for accessing the target domain.

In yet another aspect, a computer-implemented system for cross domain authorization by a target domain is provided. The system comprises one or more processors, a memory coupled to at least one of the processors, and a set of computer program instructions stored in the memory and executed by at least one of the processors in order to perform a method comprising the steps of receiving a request to register a source domain as a trusted domain of the target domain by a target domain. The request to register the target domain is approved. The target domain receives both a key of an application of the source domain for accessing the target domain and a token identifying the source domain. The target domain checks validity of the key and the token. In response to both the key and the token being valid, the access from the application of the source domain is allowed.

The embodiments and aspects, including but not limited to computer program product, are described in detail herein and are considered a part of the claimed invention.

DETAILED DESCRIPTION

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows:

The presently disclosed invention discusses Cross Origin Resource Sharing. Cross Origin Resource Sharing is a W3C specification to define secure cross domain HTTP requests. Before CORS, cross domain requests are forbidden due to the security reason. With CORS, web browsers are allowed to send cross domain HTTP requests to get data from other remote sites with restriction of following the CORS specification.

A website can use CORS to build whitelist/blacklist allow/disallow list to selectively control incoming cross domain requests. For example, a source domain can add “origin” header in the HTTP request to access a target domain (a website for example). The target domain can then check the validity of the “origin” header to allow or disallow an access from the source domain. However, current CORS mechanism checking for trusted origins by simply checking URL of the source domain is not enough for some use cases. For example, a social media web site could host many applications: some are built by third parties, some are under testing/pilot status, etc. Those applications could have potential security risk. If all cross domain requests from the source domain are allowed, all applications can then take advantage of this, which could cause security exposure of the target domain. It is desired to adopt an application level management in the source domain to manage the number of applications which are permitted to access the target domain.

Based on existing CORS specification, the target domain can authorize the trusted source domain (for example a website) a secret domain token to represent the source website. According to an embodiment of this invention, the source domain can issue keys for applications which are running on the source domain and are eligible to access the target domain. As a result, the source domain can achieve fine-grained management regarding to it applications. The source domain could, therefore, make sure those eligible applications being able to pass the authorization process checked by the target domain hence being allowed to access the target domain.

According to an embodiment of this invention, on the target domain, in response to receiving CORS request from the source domain, checking will occur of both the token of the source domain and the key associated with the application of the source domain. Communication can only start when both the token and the key are valid.

FIG.4depicts a diagram of a system according to an embodiment of the present invention for application level registration/authorization. Both the source domain and the target domain can be implemented on a computer system/server12illustrated inFIG.1. The source domain includes multiple applications running thereon (such as application 1, application 2, application 3 as illustrated inFIG.4). Different applications can be stored or installed in physically different servers/computers, even the servers/computers apart from that of the source domain. Even different applications can be stored or installed on different servers/computers. All applications of source domain, however, could be subject to the same root of URL.

At step401, the source domain sends a request to register the source domain as a trusted domain of a target domain. For example, the source domain can send its URL (Uniform Resource Locator) to the target domain. In some embodiments, the request could be directly sent to the target domain, while in other embodiments, the request could be sent to a third party (like an agent, or a controller of the target domain, and so on).

At step402, the target domain approves the request from the source domain for being registered as a trusted domain. The target domain can determine by itself if it intends to approve or reject the request. If the source domain fails to be approved as a trusted domain, all applications running on the source domain should not be able to access the target domain. Both step401and402can be performed off-line (for example in the situation that there is no actual request from any application of source domain to access the target domain yet) or on-line (for example in the situation that there is a request actually initiated from an application of the source domain to access the target domain). The target domain may record the URL of the source domain as a token of the source domain locally, which is used to identify a trusted source domain. In some embodiments, the approval could be directly sent to the source domain, while in other embodiments, the approval could be sent to a third party (like an agent, or a controller of the source domain, and so on).

The source domain may issue a key to its application for accessing the target domain at step403. For example, but without any limitation to this invention, the source domain can issue a key to an application which it believes mature enough to be able to access the target domain. According to an embodiment of the present invention, the key could be issued in response to an application hosted on the source domain requesting to access the target domain (for example making a CORS request to the target domain), which could be understood as an on-line key issuing process. According to another embodiment of the present invention, the key could be issued before there is any actual request from the application intending to access the target domain (for example when an application is set up, it may not have immediate request to access the target domain, but it may have need to access the target domain in the future), which could be understood as an off-line key issuing process. Example of the issued key could be, but not limited to, URL of the application. In other embodiments, other values/characteristics/numbers/symbols, even a file (a certificate for example), etc. can also be used as an issued key. In some embodiments, the key of the application could (1) comprise the token of the source domain like what illustrated above, (2) be independent values/characteristics/numbers/symbols irrelevant to an expression of the token, or (3) be values/characteristics/numbers/symbols derived from the token but does not comprise the token in whole or in part (for example, the token is 1234, the key could be 2468, which represent 1234*2). In other embodiments, other methods to encode the key can be adopted as well.

The application which was issued a key could request to access the target domain at step404by for example, but not limited to, sending a CORS request to the target domain with its issued key. In some embodiments, if the key comprises the token of its source domain, then token does not need to be sent to the target domain separately, otherwise, if the key itself does not comprise the token, the application may send both the key as well as the token to the target domain.

The target domain could therefore check validity of the key and the token at step405. According to an example of the present invention, checking validity of the key by the target domain could comprise sending the key received from an application back to the source domain to verify whether the application associated with the key is allowed to access the target domain, or in other words, is trusted by the source domain to access the target domain, as illustrated by step520ofFIG.5C. The source domain could then verify validity of the key based on above received key to determine whether an application associated with the key is allowed to access the target domain or not, and provide a verification result to the target domain as illustrated by step521-523ofFIG.5C. The verification result could be for example, but not limited to, a “TRUE” or “FALSE” flag. In response to receiving a positive verification result from the source domain, the target domain allows the access from the application, otherwise, the target domain could reject the access from the application. By verifying the validity of the key one by one at the source domain, the source domain could establish well management of its applications and save the resources allocated in the target domain, in which case the target domain could fully rely on the verification result of the source domain. In an additional example, and illustrated by step515ofFIG.5B, to avoid frequently call back the source domain for checking validity of the key received from the application, the target domain could cache all verified key in a stored list, and leverage the stored list to determine whether the key received from an application has been approved before for the same application. In some embodiments, verified keys in the stored list can be appended with a validity period or expiration date.

According to another example of the present invention, checking validity of the key could comprise receiving an approach (a schema for example) from the source domain to determine validity of the key, as illustrated by step530-532ofFIG.5D. In this example, the source domain needs to inform the target domain an approach to determine validity of the key. The approach could be, for example, but not limited to, setting the key as a number two times of that of the token, e.g. the token is 1234, and the key could be 2468. There are various of algorithm could be used to calculate the key based on the token, therefore, this invention does not suggest any limitation regarding to any specific approach adopted.

According to yet another example of the present invention, checking validity of the key could comprise requesting an issued key associated with the application from the source domain by the target domain, and checking the validity of the key received by comparing it with the issued key requested, as illustrated by step530-532ofFIG.5D. In this example, the source domain needs to send the target domain an issued key associated with the application. And the target domain needs to spend computing resources to compare the key received from the application with the key requested from the source domain with regards to the specific application.

At step406, in response to both the key and the token being valid, the target domain allows the access from the application of the source domain. In some embodiments, the target domain will reject the access once either the key or the token is found invalid.

With reference now toFIG.5Awhich depicts a flowchart of a method according to an embodiment of the present invention for cross domain registration. The method starts at block501, in which the source domain sends a request for being registered as a trusted domain of a target domain. At block502, the source domain receives an approval of the request for being registered as the trusted domain. At block503, the source domain issues a key to an application of the source domain for accessing the target domain.

With reference now toFIG.5Bwhich depicts a flowchart of a method according to an embodiment of the present invention for cross domain authorization. The method inFIG.5Bmay be performed by the target domain for cross domain authorization. At block501, the target domain receives a request from the source domain to register the source domain as a trusted domain of the target domain. At block511, the target domain approves the request. At block512, the target domain receives both a key of an application of the source domain for accessing the target domain and a token identifying the source domain. At block513, the target domain checks validity of the key and the token. And at block514, in response to both the key and the token being valid, the target domain allows the access from the application of the source domain.