Information processing system, resource management device, resource management method and program

Abstract

According to the present invention, an information processing system includes: a resource management device that manages a certain resource; an access device that accesses the resource; and an authorization device that, when delegation of access authority for the resource has been permitted by the owner of the resource, issues an access token that corresponds to the access authority to the access device. The resource management device has: an acquisition unit that, in response to an access request for the resource from the access device that is accompanied by the access token, acquires, as information that indicates the scope of the access authority that corresponds to the access token, information in which a qualifier has been added to access authority pre-released by the authorization device; and an execution unit that executes processing that corresponds to the access request within the scope of the access authority as limited by the qualifier. The present invention thereby improves the flexibility of the scope of authority delegated to others.

Description

[Technical field]

[0001] The present invention relates to an information processing system, a resource management device, a resource management method, and a program. [Background technology]

[0002] OAuth is known as a technical specification for delegating partial authority to a third party (Non-Patent Document 1 and Non-Patent Document 2).

[0003] The players involved in OAuth are the resource owner (RO), resource server (RS), relying party (RP), and authorization server (AS). The RO is the owner of resources such as data, and is a user who uses the resources via a certain service provided by a third party. The RS is the entity that manages the RO's resources (generally, the AS and the RS are managed by the same entity). The RP is a third party that provides the certain service. When providing the service, the RP is delegated authority by the RO, and accesses the resources managed by the RS on behalf of the RO. The AS delegates access authority for resources to the RP.

[0004] Specifically, first, the RO uses the service of the RP. At that time, the RO selects to link the AS and the RP (while accessing the RP, the RO selects the link between the RP and the AS). The RO is redirected from the RP to the AS, and authorizes the link with the RP on the AS (agrees to the delegation of authority). As a result, the RP can obtain the access token required to access resources managed by the RS.

[0005] In OAuth, the authority to be delegated to another party is called scope. The AS designs what authority can be delegated and publishes it in the API reference, etc. The RP selects the authority to use to provide the service from the API reference. The RO checks the authority requested by the RP, and if it agrees, delegates its own authority to the RP. [Prior art documents] [Non-patent literature]

[0006] [Non-Patent Document 1] The OAuth 2.0 Authorization Framework (RFC6749), [online], Internet<URL:https: / / tools.ietf.org / html / rfc6749> [Non-Patent Document 2] The OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC6750), [online], Internet<URL:https: / / tools.ietf.org / html / rfc6750> Summary of the Invention [Problem to be solved by the invention]

[0007] However, in the above conventional technology, since the AS specifies only the scope that it originally designed, there is a possibility that the RP may be delegated more authority than necessary for the services it provides.

[0008] The present invention has been made in consideration of the above points, and has an object to improve the flexibility of the scope of authority that can be delegated to others. [Means for solving the problem]

[0009] In order to solve the above problem, in an information processing system including a resource management device that manages a certain resource, an access device that accesses the resource, and an authorization device that issues an access token corresponding to the access authority to the access device when delegation of access authority to the resource is permitted by an owner of the resource, the resource management device includes an acquisition unit that acquires, in response to an access request from the access device accompanied by the access token to the resource, information to which a modifier is added to the access authority previously made public by the authorization device as information indicating the range of the access authority corresponding to the access token; , one or more of the structural relationship of the resource, the period during which the resource was generated, and the location where the resource was generated. and an execution unit that executes a process in response to the access request within the scope of the limited access authority. Effect of the Invention

[0010] It allows for greater flexibility in the scope of authority that can be delegated to others. [Brief description of the drawings]

[0011] [Figure 1] 1 is a diagram illustrating an example of a configuration of an information processing system according to an embodiment of the present invention. [Diagram 2] 2 is a diagram illustrating an example of a hardware configuration of a resource server 10 according to the embodiment of the present invention. [Diagram 3] FIG. 2 is a diagram illustrating an example of a functional configuration of an information processing system according to an embodiment of the present invention. [Figure 4] FIG. 11 is a sequence diagram illustrating an example of a processing procedure when an access token is issued. [Diagram 5] 13 is a diagram showing an example of a screen display for inquiring of the user as to whether or not cooperation with the authorization server 20 is permitted. FIG. [Figure 6] 13 is a diagram showing an example of a menu displayed on a screen for inquiring of the user as to whether or not cooperation with the authorization server 20 is permitted. FIG. [Figure 7] FIG. 13 is a diagram showing an example of a screen display for inquiring whether or not authority can be transferred; [Figure 8] FIG. 13 is a diagram showing an example of an expanded menu on a screen for inquiring whether or not authority can be transferred; [Figure 9] FIG. 1 is a diagram conceptually showing the size (range) of a scope. [Figure 10] 11 is a flowchart illustrating an example of a processing procedure when an access token is used. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, an embodiment of the present invention will be described with reference to the drawings. Fig. 1 is a diagram showing an example of the configuration of an information processing system according to an embodiment of the present invention.

[0013] In FIG. 1, an RO terminal 40, an RP server 30, an authorization server 20, and a resource server 10 are connected via a network such as the Internet.

[0014] The RO terminal 40 is a terminal used by a user who is the owner of a certain software resource such as data (hereinafter referred to as a "target resource") and who is a user of a certain service (hereinafter referred to as a "target service") that accesses the target resource. For example, a PC (Personal Computer), a smartphone, or a tablet terminal may be used as the RO terminal 40. The user corresponds to an RO (resource owner) in OAuth.

[0015] The RP server 30 is one or more computers that provide a target service. In order to provide the target service, the RP server 30 executes a process for receiving delegation of authority to access a target resource from the RO. This process complies with OAuth. The RP server 30 functions as an RP (Relying Party) in OAuth.

[0016] The authorization server 20 is one or more computers that function as an AS in OAuth.

[0017] The resource server 10 is one or more computers that store and manage target resources and function as an RS in OAuth.

[0018] Fig. 2 is a diagram showing an example of a hardware configuration of the resource server 10 in the embodiment of the present invention. The resource server 10 in Fig. 2 includes a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, and an interface device 105, which are all connected to each other via a bus B.

[0019] A program for implementing the processing in the resource server 10 is provided by a recording medium 101 such as a CD-ROM. When the recording medium 101 storing the program is set in the drive device 100, the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100. However, the program does not necessarily have to be installed from the recording medium 101, but may be downloaded from another computer via a network. The auxiliary storage device 102 stores the installed program as well as necessary files, data, and the like.

[0020] When an instruction to start a program is received, the memory device 103 reads out the program from the auxiliary storage device 102 and stores it. The CPU 104 executes functions related to the resource server 10 in accordance with the program stored in the memory device 103. The interface device 105 is used as an interface for connecting to a network.

[0021] The RP server 30, the authorization server 20, and the RO terminal 40 may also have the same hardware configuration as that shown in FIG.

[0022] Fig. 3 is a diagram showing an example of a functional configuration of an information processing system according to an embodiment of the present invention. In Fig. 3, the RP server 30 has an RPOAuth unit 31 and a scope determination unit 32. These units are realized by processing executed by the CPU of the RP server 30 of one or more programs installed in the RP server 30.

[0023] The authorization server 20 includes an ASOAuth unit 21, a scope setting unit 22, and a scope verification unit 23. Each of these units is realized by a process executed by a CPU of the authorization server 20 of one or more programs installed in the authorization server 20.

[0024] The resource server 10 includes an RSOAuth unit 11 and a scope analysis unit 12. These units are realized by processing of one or more programs installed in the resource server 10 that the CPU 104 executes.

[0025] The processing procedure executed by the information processing system will be described below. Fig. 4 is a sequence diagram for explaining an example of the processing procedure when an access token is issued. The processing procedure in Fig. 4 complies with OAuth. In addition, the processing executed by the RO terminal 40 in Fig. 4 is, for example, processing that a web browser installed in the RO terminal 40 causes the RO terminal 40 to execute.

[0026] In step S101, in response to a predetermined operation by the user, the RO terminal 40 transmits a usage request for the target service to the RP server 30. It is assumed that the user has already been authenticated by the RP server 30. Therefore, it is assumed that the RP server 30 can identify the user who has made the usage request.

[0027] When the RPOAuth unit 31 of the RP server 30 receives the usage request, it inquires of the scope determination unit 32 about the value of scope required for the target service (S102). Scope refers to the scope in OAuth. Scope in OAuth refers to the authority that is delegated to another party. Values ​​that can be specified for scope (i.e., the range or type of authority) are published in advance by the authorization server 20 in an API reference or the like. Hereinafter, the list of scope values ​​published in advance by the authorization server 20 is referred to as the "default list."

[0028] The scope determination unit 32 determines the scope required for the target service in response to an inquiry from the RPOAuth unit 31. The determination by the scope determination unit 32 is made based on setting information that is set in advance and stored in the auxiliary storage device 102 or the like. That is, the setting information indicates the scope required for the target service. The setting information indicates the scope applied to the AS when the RP applied for registration of itself to the AS (application for registration of the account of the developer of the RP's service), which is required for OAuth. That is, the application requires information such as the linked information (information about the RP), the display name, contact information, and the authority (scope) that the user wishes to transfer. Note that the RP can use OAuth only if the AS approves the application.

[0029] In this embodiment, the setting information can be set to further limit the range of access authority related to any of the scopes in the default list. When a value in the default list is further limited, an identifier (hereinafter referred to as a "modifier") indicating the limiting content is given to the value. Examples of modifiers include the following:

[0030] (a) Qualifiers related to the structural relationships of resources (such as parent-child relationships) For example, if the resource is a photo, {scope}.{album_name} Here, {scope} is one of the values ​​in the predefined list, and ".{album_name}" indicates the modifier, which means to limit access to only photos in a specific album associated with album_name.

[0031] (b) A qualifier regarding the period during which the resource was generated. For example, scope.{YYYY / MM / DD} This qualifier means that access is restricted to only resources created on a specific date (YYYY / MM / DD). scope.{YYYY / MM / DD-YYYY / MM / DD} The period in which the resource was generated may be limited, as shown below. In this case, "MM / DD" and "DD" may be omitted.

[0032] For example, if "photo" is one scope in the default list that indicates access rights to all photos, a setting such as "photo.span2020-2021" is possible. Here, ".span2020-2021" is a modifier that limits the period during which the photo was taken. Therefore, "scope=photo.span2020-2021" indicates access rights limited to only photos taken between 2020 and 2021.

[0033] (c) The location where the resource was generated For example, {scope}.{building name, prefecture name, etc.} The above qualifier means that the access authority is limited to only resources related to a specific location.

[0034] As described above, when applying for RP registration, it is necessary to apply for a scope, but in this embodiment, it is assumed that a scope with a qualifier (hereinafter, referred to as a "scope with a qualifier") can be applied for, and that the scope with a qualifier has been applied for. Therefore, the scope determination unit 32 responds to the RPOAuth unit 31 with the scope with the qualifier that has been applied for (S103).

[0035] Next, the RPOAuth unit 31 responds to the RO terminal 40 with a redirect request for the authorization request including the modifier-added scope (S104). Specific contents of the redirect request are, for example, as follows. "HTTP / 1.1 302 Moved Temporarily Location: https: / / [AS authorization endpoint (public information)] / authorize?response_type=code&scope=photo&client_id=..." In this manner, in this embodiment, the redirect request may include the scope as a parameter.

[0036] The RO terminal 40 that receives the response displays a screen for inquiring of the user as to whether or not cooperation with the authorization server 20 is permitted for the RP server 30.

[0037] Fig. 5 is a diagram showing a display example of a screen that inquires of the user about whether or not to permit cooperation with the authorization server 20. In the screen 510 shown in Fig. 5, the part enclosed in {} is actually replaced with a specific service name or the like. The screen 510 includes a menu 511. When the menu 511 is clicked by the user, the state of the screen 510 becomes as shown in Fig. 6.

[0038] 6, candidates 513 and 514, which are candidates for modifiers to be further added to the modifier-added scope included in the redirect request, are displayed as options. Such candidates may be modifiers from a list of modifiers that can be added to the original scope of the modifier-added scope, excluding modifiers already added to the scope. If the user wishes to limit the authority to be granted to the RP server 30 by his / her own will, he / she can select one of the candidates to limit the authority according to the candidate.

[0039] When an operation indicating permission for cooperation with the authorization server 20 is performed via the screen 510, the RO terminal 40 redirects the authorization request including the modifier-added scope to the authorization server 20 in response to the redirect request (S105). Note that when the user selects to add a modifier via the screen 510 (when any of the modifier candidates is selected), the modifier-added scope is further given the added modifier.

[0040] When the ASOAuth unit 21 of the authorization server 20 receives the redirected authorization request, if the scope included in the authorization request is a scope with a modifier, it transmits a verification request for the scope with the modifier to the scope verification unit 23 (S106). The scope verification unit 23 verifies the scope with the modifier in response to the verification request. For example, it is verified whether the scope is a scope to which a modifier is permitted to be added, whether the value of the modifier is correct, etc. In other words, whether a modifier can be added and modifiers that can be added are specified in advance for each scope. Next, the scope verification unit 23 transmits a verification result (OK or NG) to the ASOAuth unit 21 (S107). If the verification result is OK, step S108 and subsequent steps are executed, and if NG, step S108 and subsequent steps are not executed.

[0041] In step S108, the ASOAuth unit 21 performs authentication processing of the user of the RO terminal 40 (i.e., the RO of the target resource) according to the conventional OAuth procedure. If the authentication is successful, the ASOAuth unit 21 transmits an inquiry to the RO terminal 40 as to whether or not the authority indicated by the modifier-added scope can be delegated (S109).

[0042] In response to the inquiry, the RO terminal 40 displays a screen inquiring whether or not the authority can be transferred.

[0043] Fig. 7 is a diagram showing an example of a screen display inquiring whether or not to transfer authority. In screen 520 shown in Fig. 7, the part enclosed in {} is actually replaced with a specific service name or the like. Screen 520 includes menu 521. When menu 521 is clicked by the user, the state of screen 520 becomes as shown in Fig. 8.

[0044] 8, candidates 523 and 524, which are candidates for modifiers to be further assigned to the modifier-attached scope indicating the authority, are displayed as options. Such candidates may be modifiers, excluding modifiers already assigned to the scope, from a list of modifiers that can be assigned to the original scope of the modifier-attached scope. If a user wishes to limit his / her authority, he / she can select one of the candidates to assign a limit to the authority according to the candidate.

[0045] When an operation indicating permission for delegation of authority to the RP server 30 is performed via the screen 520, the RO terminal 40 transmits a response indicating permission for delegation of authority to the authorization server 20 (S110). The response also includes a scope with a modifier. If no modifier has been added by the user via the screen 520, the scope with modifier is the same as that transmitted to the RO terminal 40 in step S109, and if a modifier has been added by the user via the screen 520, the scope with modifier further includes the added modifier.

[0046] When the scope setting unit 22 of the authorization server 20 receives the response, it sets the modifier-attached scope included in the response to the ASOAuth unit 21 (S111). If the set modifier-attached scope has been changed from the modifier-attached scope verified in step S106 (if a modifier has been added), the ASOAuth unit 21 transmits a verification request for the set modifier-attached scope to the scope verification unit 23 (S112). In response to the verification request, the scope verification unit 23 verifies the modifier-attached scope. The content of the verification may be the same as the verification request in response to step S106. Next, the scope verification unit 23 transmits the verification result (OK or NG) to the ASOAuth unit 21 (S113). If the verification result is OK, step S114 is executed, and if it is NG, step S114 is not executed.

[0047] In step S114, the ASOAuth unit 21 issues (sends) an access token for the target resource to the RSOAuth unit 11 in accordance with the procedure defined in OAuth. Note that S114 refers to the procedure for issuing an access token to the RP server 30, and the specific processing procedure is interpreted as being replaced with the specific procedure according to the Grant type of OAuth. With the issuance of the access token, the ASOAuth unit 21 stores a modifier-attached scope corresponding to the access token. The method of storing the modifier-attached scope corresponding to the access token may conform to the method of storing the scope corresponding to the access token in OAuth.

[0048] The RP can access the target resource by using the access token (hereinafter referred to as the "target token").

[0049] In FIG. 4, the scope can be limited (a modifier can be added to the scope) at the following three times in the process before the access token is issued:

[0050] (0) Timing of scope presentation when RP registers with AS As a result, a qualified scope is returned in step S103.

[0051] (1) When a user uses a service of the RP server 30, the timing of an authorization request on the RP server 30 side The user limits the scope (adds a modifier to the scope) via screen 510.

[0052] (2) Timing at which the user authorizes the authority presented by the RP via the authorization server 20 The user limits the scope (adds a modifier to the scope) via screen 520.

[0053] However, it is not intended that modifiers must be able to be added at all of the above timings (0) to (2), but rather that modifiers may be added at any one or more of the timings.

[0054] When the scope can be limited at three timings as described above, the size (range) of the scope can be limited in multiple stages as shown in FIG.

[0055] Next, the use of the access token will be described. Fig. 10 is a flowchart for explaining an example of a processing procedure when the access token is used. The processing procedure in Fig. 10 is executed, for example, following step S114 in Fig. 4.

[0056] In step S201, the RPOAuth unit 31 transmits an access request to the target resource together with the target token to the resource server 10 as a procedure conforming to OAuth.

[0057] When the RSOAuth unit 11 of the resource server 10 receives the access request and the target token, the RSOAuth unit 11 transmits a query for the scope corresponding to the target token to the ASOAuth unit 21 as a procedure conforming to OAuth (S202). The query includes the target token.

[0058] In response to the inquiry, the ASOAuth unit 21 transmits a response including the scope stored in association with the target token to the RSOAuth unit 11 (S203). In this embodiment, the response includes a scope with a modifier. Specific contents of the response are, for example, as follows: "HTTP 200 OK Content-type: application / json { "scope":"scope.{album_name} scope.{YYYY-MM-DD}" ,…}" That is, the response lists the scopes corresponding to the target token, and modifiers are added to the scopes.

[0059] By receiving the response, the RSOAuth unit 11 acquires the modifier-attached scope included in the response. Next, the RSOAuth unit 11 transmits an analysis request for the meaning (authority) of the modifier-attached scope to the scope analysis unit 12 together with the modifier-attached scope (S204). In response to the analysis request, the scope analysis unit 12 analyzes the meaning of the modifier-attached scope, and transmits a response including the access authority implied by the modifier-attached scope as the analysis result to the RSOAuth unit 11 (S205). In this embodiment, the access authority limited by the modifier is responded. For example, if the modifier-attached scope is "scope=photo.span2020-2021", a response indicating that the access authority is only for photos taken from 2020 to 2021 is transmitted.

[0060] Next, the RSOAuth unit 11 executes processing (access to the target resource) in response to the access request from the RPOAuth unit 31 within the scope of the access authority (S206). As a result, the authority of the RPOAuth unit 31 is limited based on the modifier.

[0061] Next, the RSOAuth unit 11 transmits the result of the access to the target resource to the RPOAuth unit 31 (S207).

[0062] As described above, according to this embodiment, by adding a modifier to the scope, the scope of the authority of the initial scope can be limited. Therefore, the flexibility of the scope of the authority to be delegated to others can be improved. As a result, the authority to be delegated can be limited to the scope required for the service.

[0063] In addition, since the user can assign a modifier, it is possible to limit the authority to a user's advantage. As a result, it is possible to increase the possibility that the user can avoid unintended delegation of authority.

[0064] In this embodiment, the resource server 10 is an example of a resource management device. The authorization server 20 is an example of an authorization device. The RP server 30 is an example of an access device. The RSOAuth unit 11 is an example of an acquisition unit and an execution unit.

[0065] Although the embodiment of the present invention has been described in detail above, the present invention is not limited to such specific embodiment, and various modifications and variations are possible within the scope of the gist of the present invention described in the claims. [Explanation of symbols]

[0066] 10 Resource Server 11 RSOAuth section 12 Scope Analysis Section 20 Authorization Server 21 ASOAuth section 22 Scope setting section 23 Scope Verification Department 30 RP Servers 31 RPOAuth section 32 Scope judgment unit 40 RO terminal 100 Drive device 101 Recording media 102 Auxiliary storage 103 Memory device 104 CPU 105 Interface device B Bus

Claims

1. An information processing system including a resource management device that manages a certain resource, an access device that accesses the resource, and an authorization device that issues an access token corresponding to the access authority to the access device when delegation of access authority to the resource is permitted by an owner of the resource, The resource management device includes: an acquisition unit that acquires, in response to an access request accompanied by the access token from the access device, information indicating a range of access authority corresponding to the access token, in which a modifier is added to the access authority previously published by the authorization device; an execution unit that executes a process according to the access request within a range of access authority that is limited by the modifier in one or more of a structural relationship of the resource, a period during which the resource was generated, and a place where the resource was generated; An information processing system comprising:

2. the qualifier is added by the access device before the access token is issued to the access device.

2. The information processing system according to claim 1.

3. the qualifier is provided by the owner of the resource before the access token is issued to the access device.

3. The information processing system according to claim 1 or 2.

4. A resource management device that manages a certain resource, an acquisition unit that acquires, in response to an access request for the resource accompanied by an access token corresponding to the access authority issued by an authorization device when delegation of the access authority to the resource is permitted by an owner of the resource, information indicating a range of the access authority corresponding to the access token, the access authority being previously made public by the authorization device and having a modifier added thereto; an execution unit that executes a process according to the access request within a range of access authority that is limited by the modifier in one or more of a structural relationship of the resource, a period during which the resource was generated, and a place where the resource was generated; A resource management device comprising:

5. A resource management device that manages a certain resource, an acquisition step of acquiring information in response to an access request for the resource accompanied by an access token corresponding to the access authority issued by an authorization device when delegation of the access authority to the resource is permitted by an owner of the resource, the information being information indicating a range of the access authority corresponding to the access token and to which a modifier is added, the access authority being previously made public by the authorization device; an execution step of executing a process according to the access request within a range of access authority limited by the modifier to one or more of a structural relationship of the resource, a period during which the resource was generated, and a place where the resource was generated; 2. A resource management method comprising:

6. A resource management device that manages a certain resource includes: an acquisition step of acquiring information in response to an access request for the resource accompanied by an access token corresponding to the access authority issued by an authorization device when delegation of the access authority to the resource is permitted by an owner of the resource, the information being information indicating a range of the access authority corresponding to the access token and to which a modifier is added, the access authority being previously made public by the authorization device; an execution step of executing a process according to the access request within a range of access authority limited by the modifier to one or more of a structural relationship of the resource, a period during which the resource was generated, and a place where the resource was generated; A program characterized by executing the above.

Images