CN102792311A - Secure dynamic authority delegation - Google Patents

Abstract

In a communications network where a first computing device represents a resource owner and a second computing device represents a resource requester, the resource owner detects an event occurrence representing a request for access to said resource owner stored in a resource location One or more resources for . The resource owner sends an authorization token to the resource requestor in response to the occurrence of the event, the authorization token being used as proof of authorization delegated by the resource owner, the proof being issued by the resource request Presenting the resource requester to the resource location allows the resource requester to access one or more requested resources stored in the resource location.

Description

Secure Dynamic Power Delegation

technical field

The present invention relates generally to communication networks, and more particularly to techniques for use in communication networks for securely and dynamically delegating authorization for applications involving access to protected resources by entities other than resource owners.

Background technique

This section introduction may help to better understand aspects of the invention. Accordingly, the statements in this section are to be read for that purpose and should not be construed as admissions of prior art or non-prior art.

Various tools available via communication networks, such as the World Wide Web, allow users to create their own applications or web pages. One example is called a "mashup," which is a web page or application that uses or combines data or functionality from two or more sources to create a new service or application. However, a problem arises when a user is required to give his/her credentials (username and password) against different sources, exposing information between sources and giving one source full access to another. This may not be what the user expects.

A protocol called OAuth attempts to provide a solution to this problem. In general, the OAuth protocol (see http://oauth.net/) enables users to provide third-party access to their web resources without having to share their passwords. However, this protocol has several limitations and flaws. First, since the protocol is related to Hypertext Transfer Protocol (HTTP), it is not suitable for non-web applications. Second, because the protocol relies on the use of HTTP redirects, it is vulnerable to phishing attacks. This protocol also requires multiple round trips to obtain delegated authorization, and it is not optimal for application performance. Finally, since the protocol uses more than one proof of delegation and a proof mechanism involving repeated cryptographic signatures, it is overly complex. Accordingly, there is a need for an improved approach to delegation of rights that overcomes these and other shortcomings.

Contents of the invention

Embodiments of the present invention provide a generic, efficient and secure method for dynamically delegating authorization to enable applications (such as mashups and third-party applications) on communication networks (such as the World Wide Web or Next Generation Networks) involving Entity access to protected resources depends on the resource owner.

In a first aspect, a method comprises the following steps. In a communications network where a first computing device represents a resource owner and a second computing device represents a resource requester, the resource owner detects an event occurrence representing a request for access to a resource owner stored in a resource location One or more resources for . The resource owner sends an authorization token to the resource requester in response to the occurrence of the event, and the authorization token is used as proof of authorization delegated by the resource owner to be presented by the resource requester to the resource site in order for the resource request The user can access one or more requested resources stored in the resource location.

In one or more embodiments, the event occurrence may be a resource owner receiving a resource request from a resource requester (eg, a pull method). Optionally, the event occurrence may be the occurrence of a trigger event associated with the application program (eg push method). The resource location may be located in the third computing device or it may be located in the first computing device. The authorization token may have one or more verifiable structures, a limited lifetime, and specify a method for authenticating the resource requestor or a level of assurance for authenticating the resource requestor. The verifiable structure may include a digital signature of the resource owner. The authorization token may specify one or more actions that are permitted to be performed in accordance with the one or more requested resources. The resource requester can obtain an authorization token from the resource owner in one round trip. The mechanism for obtaining tokens can be bound to existing application protocols. Presenting an authorization token to gain access to one or more requested resources may also be tied to existing application protocols. Further, proof of authorization delegated by the resource owner may be communicated from the resource requester to at least one other resource requester such that the other resource requestor can present another authorization token to the resource site to allow the other resource The requestor accesses one or more requested resources stored in the resource location. Another authorization token obtained by the other resource requestor may specify an action permission scope that is a subset of the action authorization scope specified in the authorization token obtained by the resource requestor directly from the resource owner . In one embodiment, another authorization token obtained by the other resource requestor does not change the method used to authenticate the resource requestor or the level of assurance used to authenticate the resource requestor. Further, the other authorization token may be a modified version of the initially received authorization token and the previous resource requestor performed the modification before sending the modified version of the authorization token to the other resource requester.

Still further, the resource owner may authenticate the resource requestor before sending the authorization token to the resource requestor.

In a second aspect, a method includes the following steps. In a communications network in which a first computing device represents a resource owner and a second computing device represents a resource requester, and the resource owner detects an event occurrence representing a request for access to the resource owner's information stored in the resource location One or more resources, the resource requester receives an authorization token sent by the resource owner in response to the occurrence of the event, the authorization token is used as proof of authorization delegated by the resource owner, the proof is to be issued by the resource The requester presents the resource location to enable the resource requester to access one or more requested resources stored in the resource location.

In one or more embodiments, the resource residency may authenticate the resource requestor before the resource requestor presents an authorization token to the resource residency. The resource residency validates the authorization token presented by the resource requester before acting on the requested resource or resources. Further, the resource location may authenticate the resource requester after the resource requester presents the authorization token to the resource location. The resource requester may also communicate proof of authorization delegated by the resource owner to at least one other resource requester. Such transmission may include the resource requester sending another authorization token to the other resource requester so that the other resource requester can present the other authorization token to the resource location to grant the other resource requestor Access one or more requested resources stored in the resource location.

In a third aspect, a method includes the following steps. In a communications network in which a first computing device represents a resource owner and a second computing device represents a resource requester, and the resource owner detects an event occurrence representing a request for access to the resource owner's information stored in a resource location and the resource requester receives the authorization token sent by the resource owner in response to the occurrence of the event, the resource location receives the authorization token, and the authorization token is used by the resource owner Proof of authorization delegated to the resource requestor to grant the resource requestor access to one or more requested resources stored in the resource location.

Advantageously, the dynamic authorization delegation technique of the present invention is applicable to both web and non-web applications. The technique of the present invention does not rely on the use of HTTP redirection and does not require multiple round trips to obtain delegated authorization. Further, the techniques of the present invention are less complex than existing authorization delegation schemes.

Description of drawings

These and other objects, features and advantages of the present invention will become apparent by reading the following detailed description of illustrative embodiments, with reference to the accompanying drawings, in which:

FIG. 1 shows entities participating in secure dynamic authorization delegation according to an embodiment of the present invention;

Figure 2 shows the basic structure of an authorization token according to one embodiment of the present invention;

FIG. 3 shows a method for requesting an authorization token performed by a resource requester according to one embodiment of the present invention;

Figure 4 illustrates a method performed by a resource owner in response to a request for an authorization token, according to one embodiment of the invention;

5A and 5B illustrate a method performed by a resource requester for accessing a protected resource according to one embodiment of the present invention;

6A and 6B illustrate a method performed by a resource locus in response to a request to access a protected resource, according to one embodiment of the invention;

Figure 7 shows the structure of another authorization token according to one embodiment of the present invention;

FIG. 8 shows a hardware structure of a communication network suitable for implementing secure dynamic authorization delegation according to an embodiment of the present invention.

Detailed ways

The present invention will be described below in conjunction with exemplary communication networks and exemplary applications. It should be understood, however, that the present invention is not limited to use with any particular type of communication network or application. The disclosed technology is suitable for use with a wide variety of communication networks, including web-based and non-web-based networks, and a variety of applications. Indeed, the disclosed techniques may be implemented with any suitable application in any suitable communications network where it is desirable to provide dynamic delegation of authorization for access to protected resources by entities other than the resource owner over the communications network. Applications.

As used herein, "authorization delegation" generally means that a party with access to an item allows another party to access the item. As an example, in the following embodiment, a resource owner allows a resource requester to access a resource using an authorization token. The operation is said to be "dynamic" in the sense that delegation is performed on demand in real time rather than by provision.

As used herein, "token" generally refers to a data object or structure representing access control criteria and operations that are verifiable or capable of being authenticated. As used herein, "resource" generally refers to any item, data, information, etc. that can be accessed over a communication network.

As used herein, an "application" generally refers to computer software designed to assist a user or entity in one or more specified tasks.

As will be explained herein, the illustrative embodiments of the present invention provide techniques that enable resource requesters to dynamically obtain permission to access resources in their resource locus directly from resource owners. "Location" as used herein generally refers to a storage location accessible via a communication network. A resource requester is able to access a protected resource in the resource's location by presenting proof of authorization delegated by the resource owner. This proof (i.e., the authorization token) has a verifiable structure and a finite lifetime, and also specifies the method and level of assurance used to authenticate the resource requestor. Resource requesters can dynamically obtain authorization tokens from resource owners in one round trip through a request-response based mechanism that can be bound to existing application protocols. For example, a resource token request/response can be carried over HTTP or Session Initiation Protocol (SIP) as part of a message header or body or both. The mechanism for presenting resource tokens to gain access to protected resources is request-response based and can be bound to existing application protocols. For example, tokens can be carried over HTTP or SIP as part of a message header or body.

Figure 1 shows a system 100 in which entities participate in secure dynamic delegation of authorization according to one embodiment of the present invention. As shown, the system involves three actors: resource owners 102 , resource requesters 104 , and resource residencies 106 . It should be appreciated that each of these three actors can be implemented as one or more computing devices, as will be explained further below.

Resource owner 102 can be embodied as a user agent (in the case of an end user) or an authorization server (in the case of a service provider or organization). Similarly, the resource requester 104 can be embodied as a user agent (in the case of an end user) or an application server (in the case of a service provider or organization). In the use case where "Alice" (operating computing device A) requests a photo printing service provider to print her photos stored in a server while traveling in Moscow, the resource owner 102 (Alice) will be represented by the user agent ( For example, a web browser program executing on computing device A) will be represented, while resource requester 104 (photo printing service provider) will be represented by an application server. In another use case, where "Bob" (operating computing device B) is a user of an online movie service, resource owner 102 (online movie service provider) would be represented by an authorization server, and resource requester 104 (Bob ) will be represented by a user agent (eg, a web browser program executing on computing device B).

In order to gain access to a particular protected resource in the resource residency 106, the resource requester 104 needs to obtain an authorization token directly from the resource owner 102, which has a basic structure as shown in Figure 2 (discussed further below) 200. For this, two approaches are possible: pull and push. In the pull method, resource requester 104 and resource owner 102 exchange requests and responses. A token request will at least identify the requestor as well as the target resource and associated action. Figures 3 and 4, which will be explained below, illustrate the pull method from the perspective of the resource requester 104 and the resource owner 102, respectively. In the push method, the resource owner 102 can issue an authorization token to the resource requester 104 as a result of an application trigger rather than as a result of an explicit request from the resource requester.

FIG. 3 shows a pull method 300 on the side of a resource requester (eg, 104 in FIG. 1 ) for requesting a basic authorization token. In step 302, the resource requester generates and sends an authorization token request to the resource owner. In step 304, the resource requester examines the first response received from the resource owner and determines in step 306 whether the first response includes an authentication request (thereby the resource owner requests authentication of the resource owner before sending an authorization token to the requestor. requester) or if this first response includes an authorization token.

If the first response from the resource owner is not an authentication request but includes an authorization token, and thus step 308 (i.e. receipt of a check failure token response described below) yields a negative result, the requester saves the authorization in step 310 Token (to be sent to the resource location later).

However, if the first response from the resource owner is an authentication request, then in step 312 the resource requester generates and sends an authentication response to the resource owner. In step 314, the resource requester examines the second response received from the resource owner and determines whether the second response includes an authorization token (thus assuming the authentication was successful). If so, step 308 (fail token response) yields a negative result, and the requester saves the authorization token in step 310 (to be later sent to the resource location). However, if the authentication fails, the second response received from the resource owner is a failure token response, ie this means that the resource owner will not issue an authorization token to the requester. It should be understood that the techniques used to authenticate the requestor may include any conventional authentication techniques.

FIG. 4 shows a pull method 400 on the side of a resource owner (eg, 102 in FIG. 1 ) for processing token requests. In step 402, the resource owner checks whether the resource requester (from which the resource token was received) has been authenticated. If not, then in step 404 the resource owner generates an authentication request and sends it to the resource requester. In step 406, the resource owner checks the authentication response received from the resource requester. At step 408, a check is made to determine if the authentication was successful. If unsuccessful, the resource owner sends a failure token response to the requester at step 410 (ie, does not send an authorization token to the requester). However, if the authentication is successful, the owner determines in step 412 whether the requester should be allowed to access the owner's resources, and if so, generates an authorization token in step 414 and sends it to the requester. However, if access is denied, then in step 410 a failure token response is sent.

In possession of the authorization token, the resource requester 104 is thus able to request access to a protected resource in the resource location 106 . When receiving a resource request (see FIG. 1 ), the resource residency 106 takes the following actions:

1. Verify that the digital signature associated with the request is valid based on the digital signature method specified in the token;

2. Verify that the token has not expired in terms of time and maximum usage;

3. Verify that the requested resource and the action to be performed are part of the list of associated permissions and resources specified in the token;

4. Verify that the resource requester's name matches the requester's name in the token; and

5. Authenticate the resource requestor using the method or strength level method specified in the token.

Figures 5A and 5B illustrate a resource requester's (eg, 104 in Figure 1) side for accessing a protected resource held by a resource location (eg, 106 in Figure 1) (without having to include authorization in the initial request) token) method 500.

In step 502, the resource requester generates and sends a resource request to the resource location. In step 504, the resource requester examines the first response received from the resource residency and determines in step 506 whether the first response includes an authentication request (thus the resource residency requests that the requestor be authenticated before allowing the requestor to access the resource) or Whether this first response requests an authorization token.

If the first response from the resource location is not an authentication request but a request for an authorization token (514 described below), and thus step 508 (i.e. receipt of a check failure response described below) yields a negative result, then the requester sends Authorization token (516 described below).

However, if the first response from the resource site is an authentication request, then in step 510 the resource requester generates and sends an authentication response to the resource site. In step 512, the resource requester examines the second response received from the resource location and determines whether the second response is a failure response (508) or a request for an authorization token (514), thus assuming that the authentication was successful. If the latter, the requester sends in step 516 an authorization token (received from the resource owner according to the protocol described above in the context of FIGS. 3 and 4 ).

In step 518, the resource requester examines the third response received from the resource site and determines whether the third response is another authentication request, a request for the next authentication by the resource site to ensure that the requester utilizes the method is authenticated. That is, for enhanced security, the resource residency may need to re-authenticate the requester each time a token is received. If so, steps 524, 526 and 528 are performed, which are similar to steps 510, 512 and 508 described above. In step 530, the requester processes the response, which typically contains the requested resource.

6A and 6B illustrate a method 600 at a resource location (eg, 106 in FIG. 1 ) side for processing a resource request from a resource requester (eg, 104 in FIG. 1 ). In step 602, the resource location checks whether the resource requester has been authenticated. If so, then in step 604, the resource residency confirms whether the requester is the resource owner (in which case, the requester does not need an authorization token). If so, then in step 606 the resource locus applies the appropriate resource action and sends a response (eg, providing access to the requested resource).

However, returning to step 602, if the requestor has not been authenticated and the authorization token has not been provided by the requestor (step 608), then in steps 610 (generate and send request to requestor), 612 (check authentication response) and 614 (Confirm authentication success) Execute the authentication process. If unsuccessful, then at step 616 a failure response is sent to the requester. However, if the authentication is successful, step 604 is performed (check if the requester is the owner), and if yes, step 606 is performed (apply resource action and send response). However, after successful authentication (in step 614) and verification (in step 604) of whether the requester is the owner, the resource residency requests an authorization token from the requester in step 618 and checks it in step 620 Is it provided by the requester. If not, in step 616 a failure response is sent.

Once the token is received, the resource location validates the token at step 622 . For example, validation is performed to determine that the token signature is valid, that the requester name in the request matches the token, that the token has not yet expired, that the requested resource and action are in scope (i.e. for the requester and/or all what is allowed for the requested resource). It should be understood that, depending on the structure of the token, less or more validation may be performed on the token and its contents. If one or more aspects of the token cannot be verified, a failure response is sent to the requester in step 624, and thus the resource is not available to the requester. However, if all aspects of the token received are authenticated, another authentication process may be requested by the resource site, depending on the authentication needs (in terms of method or level of assurance) specified in the token. This is done by steps 626 , 628 , 630 and 632 , which are similar to steps 610 , 612 and 614 . Assuming the second authentication was successful, in step 634 the resource action is applied and a response is sent (ie access to the allowed resource). If unsuccessful, a failure response is sent in step 624 .

Returning again to Figure 2, the basic structure of an authorization token consists of a list of fields (in terms of name-value pairs) and the issuer's signature 202 using a signature algorithm 210 specified based on the issuer's private key or shared secret key (eg RSA-SHA1 and HMAC-SHA256) are computed on the field. A unique token identifier 204 can be constructed by concatenating an issuer name 206 and a timestamp. The issuer's chain of certificates or certificate pointers 208 is specified in the token. Note that this field only needs to be included to improve overall performance when the algorithm used to compute the issuer's signature is based on a private key. Field 212 specifies the name (identity) of the resource requester. Field 214 specifies the method used to authenticate the requester or the strength of the method. Field 216 specifies the name (identity) of the recipient, ie, the device or server serving as the resource's location.

The combined field 218 of the list of resources and permissions, the expiration time 220 and the maximum number of usages 222 sets the scope of the entire delegation. The transferability level 224 indicates the level at which a token issued by a resource owner can be forwarded down to a set of token requestors starting with the original requester. A non-negative integer value may be assumed. Transferability level zero tokens cannot be forwarded. An Nth level token of transferability can be transferred by an initial token requester to a second token requester, to a third token requester, and so on, up to the Nth token requester.

After obtaining a transferable token, the requester can issue a new token to a new requester based on the old token. As shown in FIG. 7 , the new token 700 specifies the identity of a new requestor 708 (which will be authenticated by the same method as before), and possibly a downgraded delegation scope 710 . In one embodiment, the new token 700 also includes the old token 704 (ie, the token structure shown in FIG. 2 ), and the certificate chain or certificate pointer chain 706 of the previous requester (now the issuer). The issuer's signature 702 is computed over the field using a signature algorithm (which may be the same as the one specified in the old token) based on the issuer's private or shared key.

When validating forwarded tokens, the resource location also needs to check:

1. The transferability class is greater than the number of new requesters present;

2. All signatures are valid; and

3. The range does not widen as the token is forwarded along the path.

A use case for a transferable token is as follows: Alice publishes certain content on a content server and makes the associated content manager act as her proxy for other people's access to her content. Note that resource locations need to maintain state in order to support tokens that are transferable or have a limited number of uses.

Finally, Fig. 8 shows a generalized hardware structure of a communication network 800 suitable for realizing secure dynamic delegation of authorization according to the above principles of the present invention.

As shown, computing device 810 of the resource owner (eg, 102 in FIG. 1 ), computing device 820 of the resource site (eg, 106 in FIG. 1 ), and computing device 830 of the resource requester (eg, 104 in FIG. 1 ). is operatively coupled via a communications network medium 850 . A network medium can be any network medium over which a computing device desires to communicate. As examples, the network medium is capable of carrying IP packets end-to-end and may involve UMTS (Universal Mobile Telecommunications Network) or WiFi or DSL (Digital Subscriber Line) in access networks, Ethernet in metropolitan area networks, and MPLS (Multiprotocol Label Switching). However, the invention is not limited to a particular type of network media. In general, each computing device can function as a client machine or a server machine, depending on the authorization delegation scenario being performed. It should also be understood that although the resource location is shown as a separate computing device, it may be part of the same computing device as the owner or requester. Likewise, although resource owner, requester, and location are each shown in Figure 8 as being implemented by one technical device, it should be understood that each may be implemented by more than one such computing device. As will be apparent to those skilled in the art, a computing device can be implemented as a programmed computer operating under the control of computer program code. The computer program code is executed by the processor of the computer. Given the present disclosure, a person skilled in the art can readily produce suitable computer program code to implement the protocols described herein.

However, FIG. 8 generally illustrates an exemplary structure for each device communicating over a network medium. As shown, resource owner 810 includes I/O devices 812 , processor 814 and memory 816 . Resource residencies 820 include I/O devices 822 , processors 824 , and memory 826 . Resource requestor 830 includes I/O devices 832 , processor 834 and memory 836 .

It should be understood that the term "processor" as used herein is intended to include one or more processing devices, including a central processing unit (CPU) or other processing circuitry, including but not limited to one or more signal processors, one or more integrated circuits and so on. Also, the term "memory" as used herein is intended to include memory associated with a processor or CPU, such as RAM, ROM, fixed storage such as a hard drive, or removable storage such as a magnetic disk or CDROM. Furthermore, the term "I/O device" as used herein is intended to include one or more input devices (e.g., keyboard, mouse) for inputting data into the processing unit, as well as one or more input devices for providing results associated with the processing unit. an output device (such as a CRT monitor).

Accordingly, software instructions or code for carrying out the inventive methods described herein may be stored in one or more associated storage devices, such as ROM, fixed or removable memory, and loaded when ready to be used RAM and is executed by the CPU. That is, each computing device ( 810 , 820 , and 830 ) shown in FIG. 8 can be individually programmed to perform their respective protocol steps shown in FIGS. 1 and 7 .

Although illustrative embodiments of the present invention have been described herein with reference to the drawings, it should be understood that the invention is not limited to these specific embodiments, and that various modifications can be made by those skilled in the art without departing from the scope or spirit of the invention. various changes and modifications.

Claims (10)

1. A method comprising: - In a communication network in which the first computing device represents a resource owner and the second computing device represents a resource requester, the resource owner detects the occurrence of an event representing a request for access to said resource owner stored in the resource location one or more resources of the author; - the resource owner sends an authorization token to the resource requestor in response to the occurrence of the event, the authorization token serving as proof of authorization delegated by the resource owner, the proof being issued by the resource The requester presents the resource location to allow the resource requester to access one or more requested resources stored in the resource location. 2. The method of claim 1, wherein the event occurs when the resource owner receives a resource request from the resource requester such that the resource requester and the resource owner can exchange via a pull communication method request and response. 3. The method of claim 1, wherein the event occurrence is an occurrence of a trigger event associated with an application such that the communication method between the resource requester and the resource owner is a push communication method. 4. The method of claim 1, wherein proof of authorization delegated by the resource owner is transferable from the resource requestor to at least one other resource requestor such that the other resource A requestor can present another authorization token to the resource repositories to allow the other resource requester to access one or more requested resources stored in the resource repositories. 5. The method of claim 1, wherein obtaining the authorization token and presenting the authorization token to gain access to the one or more requested resources is bound to an existing application protocol. 6. An apparatus for implementing a first computing device representing a resource owner, the apparatus comprising a memory and a processor coupled to the memory and configured to perform the steps of claim 1. 7. A method comprising: - In a communication network, wherein the first computing device represents a resource owner and the second computing device represents a resource requester, and wherein the resource owner detects an event occurrence and the event occurrence represents a request for access to the resource stored in the resource location One or more resources of the resource owner; - the resource requestor receives an authorization token sent by the resource owner in response to the occurrence of the event, the authorization token serving as proof of an authorization delegated by the resource owner, which is issued by the A resource requester presents to the resource location to allow the resource requester to access one or more requested resources stored in the resource location. 8. The method of claim 7, further comprising the resource residency authenticating the resource requestor in at least one of the following circumstances: before the resource requestor presents the authorization token to the resource residency, and After the resource requester presents the authorization token to the resource location. 9. The method of claim 7, further comprising the resource residency validating the authorization token presented by the resource requester prior to acting on the one or more requested resources. 10. A method comprising: - In a communication network, wherein the first computing device represents a resource owner and the second computing device represents a resource requester, and wherein the resource owner detects an event occurrence and the event occurrence represents a request for access to the resource stored in the resource location one or more resources of a resource owner, and wherein the resource requestor receives an authorization token sent by the resource owner in response to the occurrence of the event; - the resource residency receives the authorization token, which is used as proof of the authorization delegated by the resource owner to the resource requester to allow the resource requestor to access a or more of the requested resources.

Images