Authorization server system, control procedures for it and program

Abstract

An authorization server system configured to restrict the use of a network-provided service of a resource server system, wherein the authorization server system comprises: an authorization processing facility configured to provide authorization information in response to an authorization operation performed to allow a user to transfer authorization to use the service to a client; and a verification processing facility that is configured to verify the authorization information to be transmitted when the client, which has collected the authorization information provided by the authorization processing facility, uses the service, and is configured to allow the client to use the service with the user authorization based on a result of the verification. characterized by the fact that the authorization server system additionally features: a determining device configured to determine whether the number of uses of a mathematical function called by the client to use the service exceeds a limit, wherein a use of the mathematical function includes a use of an application programming interface of the resource server system to use the service; and a restriction device configured to limit the use of the mathematical function when the determining device determines that the number of uses is greater than the upper limit, wherein the determining unit is configured to determine whether the number of uses of the mathematical function called by the client to use the service is greater than the upper limit when the authorization information is submitted by the authorization processing unit, and when the authorization information is verified by the verification processing unit.

Description

BACKGROUND OF THE INVENTIONField of the invention

[0001] The present invention relates to an authorization server system that can transmit a user authorization to a client, a control method for controlling an authorization server system, and a program. Description of related technology

[0002] The use of web services, commonly referred to as cloud services, accessible over the Internet has increased in recent times. For example, cloud services include managing a customer relationship using a CRM (Customer Relationship Management) service and performing real-time information sharing / collection using a social networking service (SNS). Cloud services are available not only for personal use but also for business use. Furthermore, there are numerous cloud services, each of which includes a web service's application programming interface (API) that is open to the public. Another application (or another cloud service) can use the service via the API.There has been an increase in the use of a "mashup" feature that presents multiple cloud services as if they could be viewed as a single web service, allowing each of the corresponding cloud services to use an API of another cloud service that is open to the public.

[0003] On the other hand, certain problems may arise when the "mashup" function for cooperatively using a variety of cloud services is frequently used. For example, user data or personal information may be undesirably leaked if an excessive amount of information is exchanged between a variety of cloud services. Generally, it is undesirable for each cloud service to unnecessarily collect user data and personal information. Furthermore, it should be strictly prevented that user data and personal information is provided to a cloud service with which the user does not want to cooperate. However, it is generally desirable for any service provider to have a system (or configuration) that can be used cooperatively between cloud services that is easy to install.

[0004] OAuth 2.0 is a standard protocol capable of implementing authorization cooperation, designed to solve the problem that may arise in the aforementioned situation. For example, OAuth 2.0 is the protocol that allows a user-identified service B to access the API that can capture user data managed by service A. Service A clearly specifies the scope of a resource accessed by service B and obtains explicit authorization from the user regarding service B's access to the API. The explicit authorization performed by the user is called an authorization process.

[0005] When the user performs an authorization operation, Service B captures an authorization token or symbol from Service A, proving that access was authorized by Service A. Using the authorization token allows Service B to access Service A's API. The user authorization operation (i.e., a user behavior to permit access to a resource), specifically the behavior to transfer or delegate authorization or permission to use Service A to Service B, is referred to as an "authorization transfer."

[0006] Furthermore, according to OAuth 2.0, it is necessary to authenticate service B to prevent tampering with or masquerading as service B. The preparation necessary to authenticate service B is for service A to issue authentication information (specifically, a client ID and a secret) through service B and to set the authentication information in advance on service B. Hereinafter, service B is referred to as a client of service A. Furthermore, according to OAuth 2.0, it is feasible to separately form an authorization server that performs the user authorization process, authorization token issuance, and client authentication described above, and a resource server that manages user data as a resource and an API as a web service open to the public.In this case, Service B captures an authorization transmission from the user, acquires an authorization token from the authorization server, and uses the resource server's API based on the authorization token. The resource server is configured to request the authorization server to verify the acquired authorization token, allow access to the resource only if access permission is received, and transmit a response including the required data to Service B.

[0007] The use and usability of OAuth 2.0 is evident, for example, from the internet article titled "Using OAuth 2.0 to Access Google APIs" by Google, which was available on June 20, 2012 (see URL: http: / / web.archive.org / web / 20120620042440 / https: / / developers.google.co m / accounts / docs / OAuth2), which represents the generic prior art. In this respect, this internet article discloses an authorization server system and a control method for controlling an authorization server system with the features according to the preamble of the independent patent claims.

[0008] Another technique that is conventionally known is to monitor the API used by a client per unit time. This technique aims to prevent the quality of the entire service from deteriorating when the API is excessively used by a specific client. In particular, a payment service is generally configured to be charged according to a usage volume of the service and to deny a user access if the usage frequency per unit time exceeds a predetermined upper limit. This is because the payment service is basically provided based on a contract concluded between a service provider and each user, and the payment service is responsible for stable provision of the service in accordance with the contract. For example, a service level agreement (SLA) isA service level agreement (SLA) is a well-known system capable of ensuring the quality of a service. For example, the SLA can define the minimum speed of a service to be provided and the maximum unavailability period. Each user pays a usage fee for the quality of service defined by the SLA. Furthermore, the content defined by the SLA includes penalties to be imposed on the service provider in the event of failure to achieve the defined quality and guarantees to be provided to users (such as a reduction in the usage fee). Accordingly, it is strictly required for the paid service to guarantee the quality defined by the SLA. Setting a limit on the API usage scope and denying access when the limit is exceeded is important to prevent the quality of the service from deteriorating.

[0009] Further prior art is known from the document US 2003 / 0 005 135 A1, which relates to a license management system. SUMMARY OF THE INVENTION

[0010] However, in a system where a client receives an authorization transfer from a user and accesses a collaboration target server, as in the OAuth 2.0 configuration, there is no effective system or configuration that enables the client to use the API appropriately, taking into account the upper limit related to the API usage frequency.

[0011] The present invention is directed to a technique capable of ensuring proper API usage for a client in a system in which the client receives an authorization transmission from a user and accesses a collaboration target server.

[0012] According to the invention, an authorization server system and a control method for controlling an authorization server system are provided, as defined in the independent patent claims. Advantageous further developments and refinements are defined in the dependent patent claims.

[0013] According to one aspect of the present disclosure, an authorization server system configured to restrict the use of a service provided over a network includes an authorization processing unit, a verification processing unit, a determination unit, and a restriction unit. The authorization processing unit outputs authorization information in response to an authorization process performed to allow a user to transmit authorization to use the service to the client. The verification processing unit verifies the authorization information to be transmitted when the client, which has acquired the authorization information issued by the authorization processing unit, uses the service, and, based on a result of the verification, allows the client to use the service with the user authorization.The determination unit determines whether the usage frequency of a mathematical function called by the client to use the service is greater than an upper limit. The restriction unit restricts the usage of the mathematical function if the determination unit determines that the usage frequency is greater than the upper limit. The determination unit is configured to determine whether the usage frequency of the mathematical function called by the client to use the service is greater than the upper limit when the authorization information is submitted by the authorization processing unit and when the authorization information is verified by the verification processing unit.

[0014] The authorization server system according to the present disclosure ensures proper API usage to a client in a case where the client receives an authorization transmission from a user and accesses a collaboration target server.

[0015] Further features of the present invention will become apparent from the following description of exemplary embodiments with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 illustrates a system configuration. Fig. 2 illustrates a hardware configuration of each device. Fig. 3A, Fig. 3B and Fig. 3C illustrate software module configurations of respective devices. Fig. 4A, Fig. 4B and Fig. 4C illustrate table structures managed by an authorization server. Fig. 5A, Fig. 5B, Fig. 5C and Fig. 5D illustrate table structures managed by the authorization server. Fig. 6A, Fig. 6B and Fig. 6C illustrate examples of an API limit management screen. Fig. 7 (consisting of Fig. 7A and Fig. 7B) illustrates an API usage sequence. Fig. 8A, Fig. 8B and Fig. 8C illustrate screen examples. Fig. Figure 9 illustrates an API upper limit verification processing flow. Fig. 10 illustrates a general API upper limit verification processing flow. Fig. Figure 11 illustrates a single API upper limit verification processing flow. Fig. 12 illustrates a table structure managed by the authorization server according to a second exemplary embodiment. Fig. 13 illustrates an example of the API upper limit management screen according to the second exemplary embodiment. Fig. 14 illustrates an API upper limit verification processing flow according to the second exemplary embodiment. DESCRIPTION OF THE EMBODIMENTS

[0016] A cloud service according to an exemplary embodiment of the present invention has a multi-tenant architecture. The multi-tenant architecture is characterized by the provision of the same web application, deployed by a common server, to a plurality of companies or organizations. In this respect, the multi-tenant architecture is advantageous in terms of cost-benefit ratio, since it is not necessary to create and deploy a dedicated server for each service delivery target (e.g., a company or organization).

[0017] Now assume that the aforementioned service A has a multi-tenant architecture and is available to users belonging to multiple tenants (e.g., tenant 1 and tenant 2). Furthermore, assume that the aforementioned service B is a client of service A, and therefore service B can use an API of service A that is open to the public. As described above, the client's use of the API is restricted by an upper limit determined in advance with respect to the frequency of use per unit time. In this case, the following problem may arise.

[0018] When Service B uses the API based on an authorization token submitted with authorization transmitted by a user belonging to Tenant 1, and the number of API uses has reached the upper limit, the API use based on an authorization token submitted with authorization transmitted by a user belonging to Tenant 2 is rejected. Specifically, due to an inadequacy of the SLA, the content included in the SLA cannot be guaranteed for the user belonging to Tenant 2. The above problem occurs when the upper limit is not set for each tenant with respect to the use of the API. The authorization server system according to the present exemplary embodiment has a novel configuration effective for the above-mentioned cloud service.

[0019] The following is the definition of any terminology used in the exemplary embodiments of the present invention. First, a service is a function to be provided to each client when a software program running on a server is executed according to a request from the client. In this regard, a web application (software) can be referred to as an independent service. In the present exemplary embodiment, two types of services are usable. One of them is a cloud service, which can be provided by a collaboration server. The other service can be provided by a resource server. In the following description, it is assumed that a user accesses the service provided by the collaboration server via a terminal device. Furthermore, the resource server exposes an API of the service to the public.The collaboration server can use the API to provide a "mashup" functionality to any user. Specifically, from the perspective of the resource server, the collaboration server is a client.

[0020] To use the resource server's API, the collaboration server requires an authorization transfer based on a user authorization process according to the OAuth 2.0 Authorization Code Grant, which is described below. In other words, the collaboration server can use the resource server's API only when the collaboration server receives an authorization transfer from a user. Furthermore, the number of API uses per unit time is managed by the collaboration server (i.e., a client) to ensure the quality of a service provided by the resource server. If the resource server is simply configured to count the number of API uses and verify whether the counted number has reached an upper limit, the resource server cannot reduce its load when the collaboration server accesses the API excessively.To solve the above problem, the authorization server system according to the present exemplary embodiment can reduce the load of the resource server by cooperating with an authorization server to restrict the authorization transmission according to OAuth 2.0, as described in detail hereinafter.

[0021] An API is a mathematical function to be called when using a service. Any client (i.e., a calling source) can receive the service by calling the API. It can be viewed by the user as if the client has performed the processing. Hereinafter, the present exemplary embodiment will be described in detail with reference to the drawings.

[0022] An authorization or authorization transmission system according to the present exemplary embodiment can be implemented as a network system having a Fig. 1. The authorization or credential transfer system comprises a wide area network (i.e., WAN) 100 and a local area network (i.e., LAN) 101. In the present exemplary embodiment, the WAN 100 represents a WWW (World Wide Web) system. Components of the system are connected via the LAN 101.

[0023] An authorization server 200 can implement OAuth 2.0 and includes an authorization server module installed therein. A resource server 300 includes a resource server module installed therein. The resource server module includes an API that is open to the public as a web service. A collaboration server 400 includes a collaboration server module installed therein. The collaboration server module can use the API exposed by the resource server module included in the resource server 300 to enable a user to use a "mashup" function in addition to its own services. A database server 500 is connected to the authorization server 200 via the LAN 101. The database server 500 stores data that can be used by the authorization server module. A terminal 810 includes a web browser 820 installed therein. For example, the terminal 810 is a personal computer (PC) or a portable terminal (e.g.a smartphone).

[0024] A user can use the web browser 820 to communicate with the collaboration server 400 and the authorization server 200. Furthermore, the authorization server 200 and the resource server 300 are connected to each other via the LAN 101. Furthermore, the authorization server 200, the resource server 300, the collaboration server 400, and the terminal device 810 can communicate with each other via the WAN 100. Furthermore, the authorization server 200 and the database server 500 can be configured as a single server. Although each server according to the present exemplary embodiment is formed as a single device, a server group consisting of a plurality of devices can form each server. In view of the foregoing, each server according to the present exemplary embodiment is referred to as a server system.For example, an authorization server system may be formed by a single authorization server or by an authorization server group comprising a plurality of authorization servers.

[0025] The authorization or authorization transmission system according to the present exemplary embodiment can be realized as a system composed of servers and a terminal, each of which has a Fig. 2 illustrated configuration. Fig. 2 illustrates a hardware configuration applicable to all of the authorization server 200, the resource server 300, the collaboration server 400, the terminal 810, and the database server 500. The Fig. The hardware block diagram illustrated in Figure 2 corresponds to a hardware block diagram of a general information processing device. A hardware configuration of a general information processing device is applicable to each server (or the terminal) according to the present exemplary embodiment.

[0026] According to Fig. 2, a central processing unit (CPU) 201 can execute a program (e.g., an operating system (OS) or an application) stored in a program ROM of the ROM 203 or loaded from an external memory 211, such as a hard disk (HD), into a random access memory (RAM) 202 to control each block connected to a system bus 204. Executing the program can realize processing of each sequence, which is described in detail below. The RAM 202 is functionally operable as a main memory or a work area for the CPU 201. A keyboard control unit (KBC) 205 can control each key input from a keyboard 209 or a pointing device (not shown). A CRT control unit (CRTC) 206 can control a display operation to be performed by a CRT display device 210.A disk control unit (DKC) 207 can control data access to the external storage 211, such as the hard disk (HD), which can store various data. A network control unit (NC) 208 can perform communication control processing for other devices accessible via the WAN 100 or the LAN 101. In the following description, unless otherwise stated, the CPU 201 serves as a main hardware component of each server or the terminal device. On the other hand, an application program installed on the external storage 211 serves as a main software component of each server or the terminal device.

[0027] Fig. 3A illustrates a module configuration of the authorization server 200. Fig. 3B illustrates a module configuration of the resource server 300. Fig. Figure 3C illustrates a module configuration of the cooperation server 400. The authorization server 200, the resource server 300 and the cooperation server 400 are identical to those shown in Fig. 2. According to Fig. 3A, the authorization server 200 includes an authorization server module 600 and an HTTP server module 610. The HTTP server module 610 is a module capable of performing HTTP communications with the web browser 820 installed on the terminal device 810 accessible via the WAN 100. Furthermore, the HTTP server module 610 can perform SSL / TLS-based communications and includes a certificate store (not shown). In the present exemplary embodiment, the HTTP server module 610 further requests a request source to perform user authentication based on user ID and password when accepting an authorization request, as described below.

[0028] Next, the authorization server module 600 accepts a request from the web browser 820 via the HTTP server module 610, processes the request, and transmits a response to the web browser 820. In this case, in the present exemplary embodiment, the HTTP server module 610 accepts user authentication. If the request source is successfully authenticated, the HTTP server module 610 generates an authentication token associated with authenticated user information and notifies the authorization server module 600 of the generated authentication token. In the present exemplary embodiment, the authentication token is a token indicating that an authenticated user is currently in a login state, or a token verifying whether user authentication has been completed.It is possible to identify each user by using the authentication token.

[0029] On the other hand, an authorization token, described below, is a token or symbol / character that indicates that a target client is permitted access with user authorization or permission, instead of the user, if an authenticated user has performed an authorization process. In this respect, the authorization token differs from the authentication token. Furthermore, the authorization token is a token or symbol / character that indicates that the client has authorization or permission to use the API, which can be obtained using an authorization code. The authorization token, i.e., information indicating that the authorization or permission to use a user service has been transferred or delegated to the client, is referred to as authorization information.

[0030] The following describes in detail processing that can be performed by the HTTP server module 610 and the authorization server module 600. The authorization server module 600 is configured to accept authorization token verification processing from a resource server module 700 via the LAN 101, perform the authorization token verification processing, and return a response to the resource server module 700. The authorization token verification processing can be configured as a remote procedure call (RPC) or as an API of a web service that can perform communications via the HTTP server module 610 in the LAN 101.

[0031] The Fig. Resource server 300 illustrated in Figure 3B includes resource server module 700. Resource server module 700 may be configured to operate on an HTTP server module (not illustrated). Resource server module 700 includes an API exposed to the public as a web service. Resource server module 700 may accept a resource request from collaboration server 400, as described below, process the resource request, and return a response to collaboration server 400. Further, resource server module 700 may request authorization server module 600, via LAN 101, to perform authorization token verification processing, as described below.

[0032] The Fig. The collaboration server 400 illustrated in Figure 3C includes a collaboration server module 800. The collaboration server module 800 may be configured to operate on an HTTP server module (not illustrated). The collaboration server module 800 is a web application that may accept a request from the web browser 820, process the request, and return a response to the web browser 820. Furthermore, the collaboration server module 800 may be configured as an HTTP client that may invoke an API of a web service exposed to the public by the resource server module 700.

[0033] Fig. 4A, Fig. 4B and Fig. 4C illustrate data tables stored in an external memory (not shown) of the database server 500, with which the authorization server 200 can communicate via the LAN 101. Alternatively, the Fig. 4A, Fig. 4B and Fig. 4C are stored in the external memory of the authorization server 200. Fig. 4A illustrates a user management table 1200. The user management table 1200 consists of data columns for user ID 1201, password 1202, tenant ID 1203, and type 1204. The authorization server 200 has a function of authenticating each user by verifying information about a set of the user ID 1201 and the password 1202 and then generating authentication information when the verification result is true or valid.

[0034] The tenant ID 1203 is ID information about a tenant to which a user identified by each user ID belongs. The tenant is a unit that can be referred to to identify a company to which each user belongs. The company to which the user belongs can be identified based on the tenant ID. The example used in the present exemplary embodiment is not limited to the aforementioned tenant. The tenant may be replaced by another specific group for managing each user. In this case, it is practical to identify a group to which the user belongs based on a group ID. The type 1204 denotes a user authorization identified by each user ID.When the type 1204 is "client administrator," it is feasible to confirm and set a client API limit number on an API limit management screen described below. The user ID 1201 and password 1202 corresponding to "client administrator" of the type 1204 are notified in advance to a user who manages the collaboration server 400 or to a user to whom management is delegated. When the type 1204 is "user," it is further feasible to delegate authorization to the client according to a sequence described below. The user ID 1201 and password 1202 corresponding to "user" of the type 1204 are notified in advance to a user of the terminal 810. Each processing is described in detail below.

[0035] Fig. 4B illustrates a client management table 1300. The client management table 1300 consists of data columns for client ID 1301, secret 1302, tenant ID 1303, redirect URL 1304, and client name 1305. The authorization server 200 has a function of authenticating each client by verifying information about a set of the client ID 1301 and the secret 1302, and then generating authentication information when the verification result is true. Furthermore, the set of the client ID 1301 and the secret 1302 is set in advance in the collaboration server module 800. In the present exemplary embodiment, the redirect URL is URL information about a client accessed in the authorization code grant process of OAuth 2.0, which is described below, when the client receives the authorization code indicating that the authorization server 200 has allowed the user to delegate authorization to the client. In the present exemplary embodiment, the redirect URL is a URL of the collaboration server module 800, which is to be referred to when the collaboration server module 800 accepts the authorization code issued by the authorization server module 600. The redirect URL 1304 and the client name 1305 can be acquired and registered when the client ID 1301 and the secret 1302 are generated.In the present exemplary embodiment, the client ID 1301, the secret 1302, the redirect URL 1304, and the client name 1305 may be transmitted and received between a provider deploying a cloud service using the collaboration server 400 and a provider deploying a cloud service using the authorization server 200 according to a predetermined agreement.

[0036] For example, the authorization server module 600 may be configured to include a client display screen to allow an administrator of the collaboration server 400 to access the aforementioned screen to transmit and receive information. The client ID 1303 is related to the client ID 1203 of the user management table 1200. If the client ID 1303 is identical to the client ID 1203, it can be recognized that the client identified by the client ID is a "client administrator" user. Specifically, the "client administrator" user of the same tenant ID can perform confirmation and setting with respect to the client API limit number identified by the client ID. Processing regarding the redirect URL 1304 and the client name 1305 will be described in detail below.

[0037] Fig. 4C illustrates an authorization token management table 1400. The authorization token management table 1400 consists of data columns for authorization token ID 1401, token type 1402, validity period 1403, client ID 1404, and user ID 1405. The authorization token management table 1400 is described in detail below.

[0038] The Fig. 5A, Fig. 5B, Fig. 5C and Fig. The data tables illustrated in Figure 5D may be stored in the external memory of the database server 500, with which the authorization server 200 can communicate via the LAN 101. Alternatively, the aforementioned data tables may be stored in the external memory of the authorization server 200.

[0039] Fig. 5A illustrates an API usage frequency limit management table 1500. The API usage frequency limit management table 1500 consists of data columns for client ID 1501, limit value 1502, reset time 1503, period 1504, limit mode 1505, and number of calls per unit period 1506. In the present exemplary embodiment, setting values ​​of the limit value 1502, the reset time 1503, and the period 1504 are set in advance between the provider deploying the cloud service using the collaboration server 400 and a provider deploying a cloud service using the resource server 300 according to a predetermined agreement.In the present exemplary embodiment, the authorization server module 600 may include a management screen (not shown) dedicated to managing the contract between providers, and may be configured to allow an administrator of the collaboration server 400 to access the aforementioned screen and make settings via the web browser 820. The API usage frequency limit management table 1500 will be described in detail below. Furthermore, the number of calls per unit period 1506 may be reset to 0 at reset time 1503 for each interval defined by the period 1504.

[0040] Fig. 5B illustrates a tenant single setting management table 1600. The tenant single setting management table 1600 consists of data columns for client ID 1601, tenant single rejection setting 1602, tenant single approval setting 1603, and tenant single limit value sum 1604. The tenant single setting management table 1600 is described in detail below.

[0041] Fig. 5C illustrates a tenant single rejection setting management table 1700. The tenant single rejection setting management table 1700 consists of data columns for client ID 1701 and rejected tenant ID 1702. The tenant single rejection setting management table 1700 is described in detail below.

[0042] Fig. 5D illustrates a tenant single-admission setting management table 1800. The tenant single-admission setting management table 1800 consists of data columns for client ID 1801, approved tenant ID 1802, upper limit value 1803, and number of calls per unit period 1804. The approved tenant ID 1802 and the upper limit value 1803 are registered in association with each other. When an approved tenant ID is recognized, an upper limit value assigned to the tenant can be identified. The upper limit value can be set for each group ID, that is, for each tenant ID. The tenant single-admission setting management table 1800 is described in detail below. Furthermore, the number of calls per unit period 1804 may be reset to 0 at reset time 1503 for each interval defined by period 1504 of the API usage frequency upper limit management table 1500.

[0043] Fig. 6A, Fig. 6B and Fig. 6C illustrate examples of limit management screens that can be generated by the authorization server module 600 to manage and set the client API limit number. Fig. 6A, Fig. 6B and Fig. The screens illustrated in Figure 6C may be displayed on the web browser 820 available to an administrator of the collaboration server 400 or a user to whom administration is delegated.

[0044] Fig. 6A illustrates an API usage frequency limit management screen 2000 used to confirm and set the client API limit number. The API usage frequency limit management screen 2000 includes setting fields for limit value 2001, limit value setting 2002, tenant individual rejection setting button 2003, tenant individual approval setting button 2004, setting button 2005, and close button 2006. Hereinafter, processing related to the API usage frequency limit management screen 2000 will be described below with reference to Fig. 6A and Fig. 8A. When the close button 2006 is pressed, the web browser 820 closes the aforementioned screen and terminates the processing.

[0045] An administrator or delegated user of the collaboration server 400 launches the web browser 820 to access the HTTP server module 610. In response to the access from the web browser 820, the HTTP server module 610 verifies whether the notification from the web browser 820 includes a valid authentication token as an HTTP cookie. If a valid authentication token is included, the HTTP server module 610 notifies the authorization server module 600 of the authentication token. If no valid authentication token is included in the notification, the HTTP server module 610 performs the following processing. The HTTP server module 610 transmits a response including a login screen usable for user authentication to the web browser 820. Fig. 8A is an example of the login screen included in the response from the HTTP server module 610. In the present exemplary embodiment, the user inputs a user ID and password. If the input set of user ID and password matches a set of information registered in the user management table 1200, user authentication is successfully completed. As another user authentication method, an X.509 certificate or multi-factor authentication that requires multiple password input operations may be used. In this regard, the user authentication method is not limited to the above example.

[0046] The Fig. The login screen illustrated in Figure 8A consists of a user ID input field 3001 for entering a user ID, a password input field 3002 for entering a password, and a login button 3003 operable to perform a login operation. The user enters login information via the Fig. 8A, which can be displayed on the web browser 820, and presses the login button 3003. The web browser 820 transmits the entered information to the HTTP server module 610. The HTTP server module 610 acquires the user ID and password. The HTTP server module 610 then authenticates the user by verifying whether the acquired information matches a set of information from the user ID 1201 and password 1202 in the user management table 1200. Furthermore, the HTTP server module 610 confirms whether the type 1204 of the authenticated user ID 1202 is "client administrator" by referring to the user management table 1200.If user authentication failed (specifically, if the acquired information is not registered in the user management table 1200), or if the type 1204 is not "client administrator," the HTTP server module 610 transmits a response including an authentication error screen (not illustrated) to the web browser 820. If user authentication was successfully completed, the HTTP server module 610 generates an authentication token.

[0047] The authentication token may be stored in the non-volatile memory of the HTTP server module 610 in association with the user ID 1201 and the client ID 1203. The HTTP server module 610 then notifies the authorization server module 600 of the authentication token. In this case, the authentication token is set as an HTTP cookie, and it may be set in the response, and the HTTP server module 610 notifies the web browser 820. In other words, when the web browser 820 transmits the authentication token to the HTTP server module 610, the user can access the authorization server module 610 via the web browser 820 without entering the user ID and password.As mentioned above, when the web browser 820 accesses the authorization server module 600, the HTTP server module 610 performs authentication token verification and authentication processing hereinafter, and notifies the authentication token to the authorization server module 600, although redundant description thereof is avoided. Note that the authentication token in this case is different from an authorization code and an authorization token, which will be described in detail below.

[0048] When the authorization server module 600 accepts the authentication token, the authorization server module 610 acquires a value of the tenant ID 1203 associated with the authentication token and identifies the client ID 1301 if the same tenant ID is set in the tenant ID 1303 of the client management table 1300. Then, the authorization server module 600 generates the API usage frequency limit management screen 2000 (ie, the screen usable for confirming and setting the API limit number corresponding to the identified client ID), and transmits a response including the generated API usage frequency limit management screen 2000 to the web browser 820. The authorization server module 600 performs client ID identification processing hereinafter using the notified authentication token, although redundant description thereof is avoided.

[0049] The authorization server module 600 performs processing to generate the API usage frequency upper limit management screen 2000, as described in detail below. The authorization server module 600 acquires information about each item from the API usage frequency upper limit management table 1500 when the identified client ID is set in the client ID 1501. The authorization server module 600 generates the upper limit value 2001 based on the acquired upper limit value 1502, the reset time 1503, and the period 1504. Furthermore, the authorization server module 600 acquires information about each item from the tenant individual setting management table 1600 when the identified client ID is set in the client ID 1601.The authorization server module 600 generates the upper limit value 2001 and the upper limit value setting 2002 by referring to the acquired tenant individual rejection setting 1602, the tenant individual approval setting 1603, and the tenant individual upper limit value sum 1604. The API usage frequency upper limit management screen 2000 shown in . Fig. 6A is a screen example in a case where the identified client ID is “client_001”.

[0050] Next, operations to be performed when various buttons on the API usage frequency limit management screen 2000 are pressed will be described in detail below. The tenant single rejection setting button 2003 is a button that is only operable when the option selected in the tenant single rejection setting is "make effective." When the tenant single rejection setting button 2003 is pressed, the authorization server module 600 generates a Fig. 6B, and transmits a response that includes the generated tenant rejection setting screen 2100. The tenant rejection setting screen 2100 is described in detail below. The tenant approval setting button 2004 is a button that is only operable when the option selected in the tenant approval setting is "make effective." When the tenant approval setting button 2004 is pressed, the authorization server module 600 generates a Fig. 6C, and transmits a response including the generated tenant single-admission setting screen 2200. The tenant single-admission setting screen 2200 will be described in detail below. The setting button 2005 is a button operable to set and reflect the selection state of each item on the tenant single-admission setting screen 2200. When the setting button 2005 is pressed, selection states of respective setting items, namely, an operation to be performed upon reaching the upper limit, a tenant single-rejection setting, and a tenant single-admission setting, are notified from the web browser 820 to the authorization server module 600.

[0051] In response to the notification, the authorization server module 600 reflects the notified selection state of the operation to be performed upon reaching the upper limit in the upper limit mode 1505 of the client upper limit management table 1500, referring to the identified client ID. Furthermore, the authorization server module 600 reflects the selection state of the tenant single rejection setting in the tenant single rejection setting 1602 of the tenant single setting management table 1600, referring to the identified client ID. Then, the authorization server module 600 reflects the setting state of the tenant single approval setting in the tenant single approval setting 1603. The authorization server module 600 transmits a response including the API usage frequency upper limit management screen 2000 to the web browser 820 based on all the reflected data.

[0052] Fig. 6B illustrates the individual tenant rejection setting screen 2100. The individual tenant rejection setting screen 2100 includes setting fields for rejected tenant registration 2101, registration button 2102, rejected tenant list 2103, release button 2104, and close button 2105. Hereinafter, processing related to the individual tenant rejection setting screen 2100 will be described in detail below with reference to Fig. 6B. When the close button 2105 is pressed, the web browser 820 closes the aforementioned screen and terminates processing.

[0053] When the tenant single rejection setting button 2003 is pressed on the API usage frequency limit management screen 2000, the authorization server module 600 acquires no information or at least information based on the identified client ID from the tenant single rejection setting table 1700 with reference to the rejected tenant ID 1702. Then, the authorization server module 600 generates the tenant single rejection setting screen 2100. The registration button 2102 is a button operable to additionally register a rejected tenant. When the registration button 2102 is pressed, the web browser 820 notifies the authorization server module 600 of the tenant ID input in the rejected tenant registration 2101.In response to the notification, the authorization server module 600 sets the identified client ID and the notified tenant ID in the single-tenant rejection setting table 1700. The release button 2104 is a button operable to release a rejected tenant. When the release button 2104 is pressed, the web browser 820 notifies the authorization server module 600 of the tenant ID displayed in the rejected tenant list 2103 corresponding to the release button 2104. In response to the notification, the authorization server module 600 deletes the set of the identified client ID and the notified tenant ID from the single-tenant rejection setting table 1700. The button shown in FIG. Fig. The tenant single rejection setting screen 2100 illustrated in Figure 6B is a screen example in a case where the identified client ID is “client_001”.

[0054] Fig. 6C illustrates an example of the tenant single-admission setting screen 2200. The tenant single-admission setting screen 2200 consists of setting fields for single-admission tenant registration and modification 2201, registration and modification button 2202, single-admission tenant list 2203, release button 2204, and close button 2205. Hereinafter, processing related to the tenant single-admission setting screen 2200 will be described in detail below with reference to Fig. 6C. When the close button 2205 is pressed, the web browser 820 closes the aforementioned screen and terminates processing.

[0055] When the tenant single-admission setting button 2004 is pressed on the API usage frequency limit management screen 2000, the authorization server module 600 acquires at least one of the approved tenant ID 1802 and the limit value 1803 based on the identified client ID from the tenant single-admission setting table 1800, as well as the period 1504 from the client limit management table 1500. Furthermore, the authorization server module 600 generates the tenant single-admission setting screen 2100 based on the acquired information. The registration and modification button 2202 is a button operable to add and register a single-admission tenant or to modify the limit value.When the registration and modification button 2202 is pressed, the web browser 820 notifies the authorization server module 600 of the entry of the tenant ID and the upper limit value in the individual setting tenant registration and modification 2201. In response to the notification, the authorization server module 600 sets the identified client ID, the notified tenant ID, and the upper limit value in the tenant individual authorization settings table 1800. In this case, if the notified set of client ID and tenant ID is already set, the authorization server module 600 updates the upper limit value 1803 according to the notified set. Furthermore, the authorization server module 600 recalculates and updates the tenant individual upper limit value sum 1604 in the tenant individual setting management table 1600.The release button 2204 is a button operable to release a single-setting tenant. When the release button 2204 is pressed, the web browser 820 notifies the authorization server module 600 of the tenant ID displayed in the single-setting tenant list 2203 corresponding to the release button 2204. In response to the notification, the authorization server module 600 deletes the identified set of client ID and tenant ID and the upper limit value from the tenant single-admission settings table 1800. The limit value specified in . Fig. The tenant single approval setting screen 2200 illustrated in Figure 6C is a screen example in a case where the identified client ID is “client_001”.

[0056] Although the Fig. 6A, Fig. 6B and Fig. 6C are provided as independent screens, all of the illustrated screens can be combined into a single screen. Although both the individual tenant approval setting and the individual tenant rejection setting are provided in the screen of Fig. 6A, the screen may further be configured to enable at least one of the aforementioned settings. In the present exemplary embodiment, the screen that enables designation of a client ID and setting of an upper limit value when a mathematical function is called for the designated client ID is referred to as the "management screen." The management screen allows a user to Fig. 6A, Fig. 6B and Fig. 6C illustrated settings.

[0057] Next, with reference to Fig. 7 and Fig. 8A, Fig. 8B and Fig. 8C, an exemplary processing sequence according to the present exemplary embodiment is described in detail in which the collaboration server module 800 uses the API that is publicly available through the resource server module 700. According to Fig. In Figure 7, "Ref" stands for "reference," which is described with reference to another drawing. "Alt" also stands for "branch," which is branch processing to be performed based on the result of the previously executed sequence. Furthermore, "Opt" indicates that processing is to be performed only if the upper limit is met.

[0058] In step S1.1, a user performs a collaboration start operation, which is displayed on the web browser 820, although not illustrated. In step S1.2, the web browser 820 transmits a collaboration start notification to the collaboration server module 800. In step S1.3, the collaboration server module 800 transmits an authorization request to the web browser 820 in response to the collaboration start notification. In step S1.4, the web browser 820 transmits an authorization request to the authorization server module 600 via the HTTP server module 610. In the present exemplary embodiment, authorization token submission processing, including an authorization request in step S1.3 and an authorization token response in step S3.2, may be performed according to the Authorization Code Grant flow defined by OAuth 2.0.

[0059] In the present exemplary embodiment, the authorization request includes at least the client ID and the redirection URL held by the collaboration server module 800. Furthermore, the authorization request includes a request for issuing an authorization code necessary for the collaboration server module 800 to access the resource server module 700 when authorization is delegated by the user. As described above, the redirection URL is URL information about a client to be referenced to accept the authorization code issued by the authorization server 200.

[0060] In step S1.4, the HTTP server module 610 accepts the authorization request from the web browser 820 and verifies whether the notification from the web browser 820 includes a valid authentication token as an HTTP cookie. If the valid authentication token is included, the HTTP server module 610 notifies the authorization server module 600 of the authentication token. The process proceeds to step S1.9. If the valid authentication token is not included, the HTTP server module 610 performs predetermined processing in step S1.5.

[0061] In step S1.5, the HTTP server module 610 transmits a response including a user authentication login screen to the web browser 820. Fig. 8A illustrates an example of the login screen transmitted from the HTTP server module 610. In the present exemplary embodiment, to perform authentication, the user is required to input a user ID and password to check whether the input user ID and password match a set of information previously registered in the user management table 1200. As another user authentication method, an X.509 certificate or multi-factor authentication that requires multiple password input operations may be used. In this regard, the user authentication method is not limited to the above example.

[0062] The Fig. The login screen illustrated in Figure 8A consists of the user ID input field 3001 for entering a user ID, the password input field 3002 for entering a password, and the login button 3003 operable to perform a login operation. The user enters necessary login information on the screen displayed on the web browser 820 and then presses the login button 3003. The web browser 820 transmits the entered information to the HTTP server module 610. The HTTP server module 610 acquires the user ID and password. The HTTP server module 610 then authenticates the user by verifying whether the acquired information matches a set of the user ID 1201 and the password 1202 in the user management table 1200. Furthermore, the HTTP server module 610 confirms whether the type 1204 of the authenticated user ID 1202 is “user” by referring to the user management table 1200.If user authentication has failed (specifically, if the acquired information is not registered in the user management table 1200), or if the type 1204 is not "user," the HTTP server module 610 transmits a response including the authentication failure screen (not illustrated) to the web browser 820.

[0063] If user authentication is successfully completed, the HTTP server module 610 generates an authentication token. The authentication token can be stored in the non-volatile memory of the HTTP server module 610 in association with the user ID 1201 and the client ID 1203. The HTTP server module 610 then notifies the authorization server module 600 of the authentication token. In this case, the authentication token is set as an HTTP cookie, is included in the response, and is notified by the HTTP server module 610 to the web browser 820. Hereinafter, as mentioned above, when the web browser 820 accesses the authorization server module 600, the HTTP server module 610 performs authentication token verification and authentication processing, and notifies the authentication token to the authorization server module 600, although redundant description thereof is avoided.

[0064] In step S1.9, the authorization server module 600 verifies whether the acquired authorization request includes a correct set of client ID and redirection URL if the authorization request is accepted with the authentication token. Specifically, the authorization server module 600 verifies whether the set of client ID and redirection URL included in the acquired authorization request matches the set of client ID 1301 and redirection URL 1304 registered in the client management table 1300. If it is determined that the captured set of client ID and redirect URL does not match the registered set of client ID 1301 and redirect URL 1304, the authorization server module 600 transmits a response including an error screen (not illustrated) to the web browser 820 via the HTTP server module 610.If it is determined that the acquired set of client ID and redirect URL matches the registered set of client ID 1301 and redirect URL 1304, the authorization server module 600 then performs API upper limit verification processing in step S1.11. In this case, the authorization server module 600 performs processing using the user ID acquired from the authentication token notified by the HTTP server module 610 and the client ID acquired as the authorization request. The API upper limit verification processing will be described in detail below.

[0065] If the result of the API upper limit verification processing is "Rejection Response", the authorization server module 600 then transmits an authorization error response to the cooperation server module 800 via the web browser 820 in step S2.11 and step S2.12. Specifically, the authorization server module 600 transmits a redirection response to the web browser 820 such that the web browser 820 is redirected to the redirection URL acquired in response to the authorization request. In step S2.13, the cooperation server module 800 transmits a response containing a Fig. 8C, to the web browser 820, and completes the Fig. 7 illustrated processing. The Fig. The screen illustrated in Figure 8C is merely an example. For example, if the collaboration server module 800 can detect the content of an error response, a screen displaying only the authorization-related error content and a screen notifying that the number of API uses has reached the upper limit may be selectively displayed. If the number of API uses has already reached the upper limit through the sequential processing described above, the system may terminate the processing without requiring the collaboration server module 800 to access the resource server module 700. As a result, the load on the resource server module 700 can be reduced.

[0066] Next, if the result of the API upper limit verification processing is “Accept Response,” the authorization server module 600 then transmits a response including an authorization confirmation screen to the web browser 820 in step S2.1. Fig. 8B illustrates an example of the authorization confirmation screen included in the response. An authorization confirmation screen 3100 includes an access source display area 3101, which is an area where the client name 1305 acquired from the client management table 1300 with reference to the client ID included in the authorization request can be displayed. Furthermore, the authorization confirmation screen 3100 includes an approval button 3102 and a rejection button 3103 that can be operated by a user to perform an authorization operation and a rejection operation with reference to the contents of the aforementioned information. When the user presses the rejection button 3103, the authorization server module 600 then transmits to step S2.11 and step S2.12, an authorization error response to the collaboration server module 800, similar to the process performed when the result of the API upper limit verification processing is a "rejection response." The authorization error response may be configured to allow a user to modify the contents of the error response in any way such that the configuration or wording of the screen to be displayed by the collaboration server module 800 accepting the response is changed.

[0067] In step S2.2, the user presses the authorization button 3102 on the authorization confirmation screen 3100. Specifically, when an authorization operation is performed to allow delegation of a user authorization to use a service provided by the resource server 300 to the collaboration server 400, then in step S2.3, the authorization is notified from the web browser 820 to the authorization server module 600.

[0068] In step S2.4, the authorization server module 600 issues an authorization code. Specifically, the authorization server module 600 issues an authorization token ID and registers the client ID included in the authorization request and the user ID of the user from whom the permission was obtained in the authorization token management table 1400. In this case, the authorization server module 600 registers the authorization code as the token type 1402 and the authorization code validity date and time as the validity period 1403. Then, in steps S2.5 and S2.6, the authorization server module 600 adds the authorization token ID of the issued authorization code and transmits an authorization response to the cooperation server module 800 via the web browser 820.Specifically, the authorization server module 600 transmits a redirect response to the web browser 820 to redirect the web browser 820 to the redirect URL detected in response to the authorization request.

[0069] In step S2.7, the cooperation server module 800 transmits an authorization token request to the authorization server module 600. The authorization token request includes at least the acquired authorization code, the client ID, the secret, and the redirection URL transmitted in response to the authorization request.

[0070] In step S2.8, the authorization server module 600 authenticates the client by referring to the acquired set of the client ID and secret. Specifically, the authorization server module 600 authenticates the client by verifying whether the acquired set of the client ID and secret matches the set of the client ID 1301 and the secret 1302 in the client management table 1300. In the present exemplary embodiment, if the client authentication fails, the authorization server module 600 transmits an authentication failure response to the cooperation server module 800. If the client authentication is successfully completed, the authorization server module 600 then verifies the acquired authorization code in step S2.9.In the authorization code verification, the authorization server module 600 verifies whether the authorization token ID of the acquired authorization code is registered in the authorization token management table 1400. If the authorization token ID is registered, the authorization server module 600 verifies whether the authorization token ID is within the validity period 1403. Furthermore, the authorization server module 600 verifies whether the redirect URL acquired based on the authorization token request matches the redirect URL 1304 registered in the client management table 1300, referring to the client ID 1404 associated with the authorization token ID. If the result of the authorization code verification is invalid, the authorization server module 600 transmits a token invalidity error response to the cooperation server module 800.If the result of the authorization code verification is valid, the authorization server module 600 then performs API upper limit verification processing in step S2.10. In this case, the authorization server module 600 performs the processing using the user ID associated with the authorization code and the authenticated client ID. The API upper limit verification processing is described in detail below. If the result of the API upper limit verification processing is "Rejection Response," the authorization server module 600 then transmits an authorization error response to the cooperation server module 800 in step S3.9. In step S3.10, the cooperation server module 800 transmits a response that satisfies the requirements specified in . Fig. 8C, to the web browser 820, and completes the Fig. 7 illustrated processing.

[0071] When the number of API uses has already reached the upper limit through the sequential processing described above, the system can terminate the processing without requiring the collaboration server module 800 to access the resource server module 700. As a result, the load on the resource server module 700 can be reduced.

[0072] Next, if it is determined that the result of the API upper limit verification processing is "Accept Response," the authorization server module 600 then issues an authorization token in step S.3.1. Specifically, the authorization server module 600 issues an authorization token ID and registers the user ID and the authenticated client ID associated with the authorization code in the authorization token management table 1400. In this case, the authorization server module 600 registers the authorization token as the token type 1402 and the authorization token validity date and time as the validity period 1403.

[0073] Then, in step S3.2, the authorization server module 600 transmits a response including the authorization token ID of the issued authorization token to the collaboration server module 800. In this case, the authorization server module 600 may be configured to transmit a response including the validity period of the issued authorization token. In the present exemplary embodiment, the system does not issue any refresh tokens, as governed by OAuth 2.0, to update the authorization token. However, the authorization server module 600 may be configured to manage a refresh token ID and the validity period in the authorization token management table 1400.In this case, it is useful to submit both the authorization token and the refresh token at the same time so that the authorization server module 600 can transmit a response that includes the submitted refresh token ID in the authorization token response.

[0074] If the collaboration server module 800 acquires the authorization token, the collaboration server module 800 then transmits a resource request for the public API to the resource server module 700 in step S3.3. If the resource server module 700 accepts the resource request, the resource server module 700 then transmits an authorization token verification request to the authorization server module 600 in step S3.4. The authorization token verification request includes an authorization token ID of the verification target authorization token.

[0075] In step S3.5, the authorization server module 600 verifies the authorization token acquired by the resource server module 700. The authorization server module 600 acquires information about the authorization token based on the acquired authorization token ID. Specifically, the authorization server module 600 identifies data matching the authorization token ID and the token type "authorization token" from the authorization token management table 1400 and acquires the validity period 1403. Then, the authorization server module 600 verifies whether the authorization token exists (specifically, in the authorization token management table 1400) and verifies whether the authorization token is within the validity period.

[0076] If the result of the authorization token verification shows that the authorization token is not present or is not within the validity period even though the authorization token is present, the authorization server module 600 determines that the authorization token is "invalid." Then, in step S3.8, the authorization server module 600 transmits a "rejection response" notification to the resource server module 700. If it is determined that the result of the authorization token verification request is "rejection response," the resource server module 700 then transmits an error response to the cooperation server module 800 in step S4.4. In step S4.5, the cooperation server module 800 transmits a response that meets the requirements specified in Fig. 8C, to the web browser 820, and terminates the processing of the Fig. 7 illustrated process.

[0077] If the authorization token verification result shows that the authorization token exists and is within the validity period, the authorization server module 600 determines that the authorization token is "valid." Then, in step S3.6, the authorization server module 600 performs API upper limit verification processing. In this case, the authorization server module 600 performs the processing using the user ID and the client ID associated with the authorization token. The API upper limit verification processing is described in detail below.

[0078] If it is determined that the result of the API upper limit verification processing is “Rejection Response”, the authorization server module 600 then transmits a “Rejection Response” notification to the resource server module 700 in step S3.8. If it is determined that the result of the authorization token verification request is “Rejection Response”, the resource server module 700 then transmits an error response to the cooperation server module 800 in step S4.4. In step S4.5, the cooperation server module 800 transmits a response that meets the requirements specified in Fig. 8C, to the web browser 820, and completes the Fig. 7 illustrated processing.

[0079] If it is determined that the result of the API upper limit verification processing is "Accept Response," the authorization server module 600 then performs API call count addition processing in step S3.7. Specifically, if the API upper limit verification processing described below is general upper limit verification processing, the authorization server module 600 acquires the client ID 1404 from the authorization token management table 1400 based on the acquired authorization token ID. Then, if the acquired client ID matches the client ID 1501 in the API usage frequency upper limit management table 1500, the authorization server module 600 adds 1 to the number of calls per unit period 1506 for the corresponding data.

[0080] Further, when the API upper limit verification processing described below is a single upper limit verification processing, the authorization server module 600 acquires the client ID 1404 and the user ID 1405 from the authorization token management table 1400 based on the acquired authorization token ID. Furthermore, the authorization server module 600 acquires the tenant ID 1203 from the user management table 1200 based on the acquired user ID. Then, if the acquired client ID and the acquired tenant ID match the set of the client ID 1801 and the approved tenant ID 1802 in the tenant individual approval setting management table 1800, the authorization server module 600 adds 1 to the number of calls per unit period 1804 for the corresponding data. Then, in step S3.8, the authorization server module 600 transmits an “authorization response” notification to the resource server module 700.If it is determined that the result of the authorization token verification request is "permission response," the resource server module 700 then performs resource acquisition processing according to the API function open to the public in step S4.1. In step S4.2, the resource server module 700 transmits a response including the acquired resource to the collaboration server module 800. In step S4.3, the collaboration server module 800 transmits a response including a collaboration screen (not illustrated) to the web browser 820, and terminates the processing of the input data shown in step S4.3. Fig. 7. Through the processing described above, the collaboration server module 800 can use the publicly available API through the resource server module 700.

[0081] Performing the API usage frequency upper limit verification processing in steps S1.11 and S2.10 brings about various effects, as described in detail below. For example, the timing for verifying whether the number of API usages has reached the upper limit can be any of steps S1.11, S2.10, S3.3, and S3.6. First, when performing the aforementioned verification in step S3.3, specifically, in a case where the resource server module 700 independently verifies the upper limit of the number of API usages, it is practical to perform the upper limit management using detailed API processing information acquired by the resource server module 700. Specifically, it is advantageous that the upper limit management can be performed finely compared to the transmission / reception granularity within the category of OAuth 2.0.On the other hand, considering the purpose of the present invention (i.e., reducing a load in the resource server 300), it is necessary for the resource server module 700 to have a module configuration capable of independently managing the upper limit of the number of API uses and performing verification. In other words, the load may undesirably increase. According to a system configuration in which there are a plurality of resource servers 300, each of which can deploy unique / special services and expose APIs to the public, each resource server 300 is further required to have a module configuration capable of managing the upper limit of the number of API uses. In this respect, the aforementioned configuration is inefficient.Furthermore, each client may have a unique / special method for managing the upper limit of the number of API uses for each API of the resource server 300 used. Therefore, each client is required to perform complicated processing control.

[0082] Next, the aforementioned verification may be performed only in step S3.6, specifically in a case where the resource server module 700 requests the authorization server module 600 to verify whether the number of API uses has reached the upper limit. In this case, for example, even in a case where there are a plurality of resource servers 300 each deploying unique / special services and capable of exposing APIs to the public, it is practical to implement a unified method capable of managing the upper limit of the number of API uses. As a result, it becomes easy for the client to perform its own processing control. On the other hand, considering the purpose of the present invention (ie,In the above-mentioned method (i.e., reducing a load in the resource server 300), the load reduction is not perfect because the resource server module 700 must perform the sequential processing in steps S3.3 to S3.8 even when the number of API uses has reached the upper limit. Specifically, the load on the network resource cannot be reduced because it is necessary for the resource server module 700 to establish the communication path across the WAN 100 and the LAN 101 to accept the resource request from the client in step S3.3.

[0083] As an example, the issuance of the authorization token may be restricted in steps S1.11 and S2.10. In this case, the effect of reducing the load on the resource server 300 (i.e., the purpose of the present invention) is considered to be higher. However, according to OAuth 2.0, it is generally the case that the authorization token can be frequently reused within the validity period. Reusing the authorization token is useful when it is necessary to continuously execute a plurality of APIs to establish a single service. However, frequent reuse of the authorization token is disadvantageous in that it is impractical to strictly count the number of uses for the purpose of managing the upper limit of the number of API uses.As a result, it may be impractical to control the load of the resource server 300 if the authorization token is frequently reused within the validity period even after the number of API uses has reached the upper limit.

[0084] In view of the above, the system according to the present invention can provide a special effect for the purpose of controlling the load of the resource server 300 by simultaneously restricting the issuance of the authorization token at the time of the authorization token issuance processing in step S1.11 and step S2.10 in accordance with the method for managing the upper limit of the number of API uses at the time of the verification processing performed in step S3.6.

[0085] Next, with reference to Fig. 9, Fig. 10 and Fig. 11 describes in detail the upper limit verification processing that can be performed by the authorization server module 600. Fig. 9 is a flowchart illustrating the API upper limit verification processing that may be performed by the authorization server module 600. The Fig. 9 can be carried out in each of steps S1.11, S2.10 and S3.6 in the embodiment described with reference to Fig. 7 can be called and performed. In step S5.1, the authorization server module 600 receives an API upper limit verification processing request. In step S5.2, the authorization server module 600 acquires the client ID and user ID notified along with the request. Next, in step S5.3, the authorization server module 600 acquires the upper limit mode 1505 of the acquired client ID from the API usage frequency upper limit management table 1500.

[0086] If the detected upper limit mode 1505 is “deferred payment for excess” (NO in step S5.4), the authorization server module 600 then transmits an “approval response” notification in step S5.5, and ends the processing of the Fig. 9. In this case, the type of upper limit verification processing included in the notification is general upper limit verification processing. If the acquired upper limit mode 1505 is "rejection" (YES in step S5.4), the authorization server module 600 then acquires the individual tenant rejection setting 1602 and the individual tenant approval setting 1603 of the acquired client ID from the individual tenant setting management table 1600 in step S5.6.

[0087] If both the acquired tenant rejection setting 1602 and the acquired tenant approval setting 1603 are "invalid" (NO in step S5.7), the authorization server module 600 then performs the general upper limit verification processing in step S5.8. The general upper limit verification processing will be described in detail below. If at least one of the acquired tenant rejection setting 1602 and the acquired tenant approval setting 1603 is "valid" (YES in step S5.7), the authorization server module 600 then acquires a tenant ID based on the acquired user ID in step S5.9. Specifically, the authorization server module 600 acquires the tenant ID 1203 from the user management table 1200 by referring to the user ID.In this case, the captured tenant ID is information required to identify a tenant to which the user who transferred or delegated an authorization or permission to the client belongs (in particular, the authorization transfer source according to OAuth 2.0).

[0088] Next, if the authorization server module 600 determines that the acquired single-tenant rejection setting 1602 is "invalid" (NO in step S5.10), the process proceeds to step S5.13. If the acquired single-tenant rejection setting 1602 is "valid" (YES in step S5.10), the authorization server module 600 then confirms in step S5.11 whether the tenant of the acquired client ID is a rejection target. Specifically, the authorization server module 600 confirms whether the acquired set of client ID and tenant ID is registered in the single-tenant rejection setting management table 1700. If it is determined that the acquired set of client ID and tenant ID is registered (YES in step S5.11), the authorization server module 600 then identifies the tenant as a rejected tenant in step S5.12 and transmits a "rejection response" notification. Then, the authorization server module 600 terminates the processing of the Fig. 9. If it is determined that the acquired set of client ID and tenant ID is not registered (NO in step S5.11), the process proceeds to step S5.13.

[0089] In step S5.13, the authorization server module 600 checks the acquired tenant individual permission setting 1603. If it is determined that the acquired tenant individual permission setting 1603 is "invalid" (NO in step S5.13), the authorization server module 600 then performs the general upper limit verification processing in step S5.8. The general upper limit verification processing is described in detail below. If the acquired tenant individual permission setting 1603 is "effective" (YES in step S5.13), the authorization server module 600 then confirms whether the tenant of the acquired tenant ID is an individual setting target in step S5.14. Specifically, the authorization server module 600 confirms whether the acquired set of client ID and tenant ID is registered in the tenant individual permission setting table 1800.If it is determined that the acquired set of client ID and tenant ID is not registered (NO in step S5.14), the authorization server module 600 then performs general upper limit verification processing in step S5.8. The general upper limit verification processing will be described in detail below. If it is determined that the acquired set of client ID and tenant ID is registered (YES in step S5.14), the authorization server module 600 then performs individual upper limit verification processing in step S5.15. The individual upper limit verification processing will be described in detail below.

[0090] Fig. 10 is a flowchart illustrating the general upper limit verification processing (“General Upper Limit Verification Processing”) that may be performed by the authorization server module 600. The Fig. 10 can be carried out in step S5.8 in the embodiment described with reference to Fig. 9 described processing can be accessed and carried out.

[0091] In step S6.1, the authorization server module 600 acquires the upper limit value 1502 and the number of calls per unit period 1506 from the API usage frequency upper limit management table 1500 based on the acquired client ID. Then, in step S6.2, the authorization server module 600 confirms whether the number of calls per unit period 1506 is equal to or less than the upper limit value 1502. If it is determined that the number of calls per unit period 1506 is greater than the upper limit value 1502 (NO in step S6.2), the authorization server module 600 then transmits a "rejection response" notification in step S6.3 and terminates the processing of the Fig. 10. If it is determined that the number of calls per unit period 1506 is equal to or less than the upper limit value 1502 (YES in step S6.2), the authorization server module 600 then transmits an "authorization response" notification in step S6.4 and ends the processing of the Fig. 10. In this case, the type of upper limit verification processing included in the notification is general or ordinary upper limit verification processing.

[0092] Fig. 11 is a flowchart illustrating the individual upper limit verification processing (“single upper limit verification processing”) that may be performed by the authorization server module 600. The Fig. 11 can be carried out in step S5.15 in the embodiment described with reference to Fig. 9 described processing can be accessed and carried out.

[0093] In step S7.1, the authorization server module 600 acquires the upper limit value 1803 and the number of calls per unit period 1804 from the tenant single authorization setting management table 1800 based on the acquired client ID and the acquired tenant ID. Then, in step S7.2, the authorization server module 600 confirms whether the number of calls per unit period 1804 is equal to or less than the upper limit value 1803. If it is determined that the number of calls per unit period 1804 is greater than the upper limit value 1803 (NO in step S7.2), the authorization server module 600 then transmits a "rejection response" notification in step S7.3 and ends the processing of the Fig. 11. If the number of calls per unit period 1804 is equal to or less than the upper limit value 1803 (YES in step S7.2), the authorization server module 600 then transmits an "Accept Response" notification in step S7.4 and ends the processing of the Fig. 11. In this case, the type of upper limit verification processing included in the notification is a single or individual upper limit verification processing.

[0094] As described above, the authorization server module 600 performs the upper limit verification processing. Specifically, performing the individual tenant authorization setting and the individual upper limit verification processing allows the user who has delegated authorization according to OAuth 2.0 to manage the upper limit on the number of API uses for each associated tenant. Specifically, when the API is used by a client, it is possible to eliminate the discrepancy in the number of API uses between the tenants that constitute an authorization transmission source.

[0095] According to the upper limit verification processing flow described with reference to the Fig. 9, the authorization server module 600 performs the general upper limit verification processing when it is determined that the client of the acquired client ID is not a single setting target (NO in step SS.14). According to the flowchart shown in Fig. However, in the processing flow illustrated in Figure 9, if there are a large number of clients that make the individual client approval setting ineffective, an undesirable deviation may occur with regard to the number of API uses between the non-approval and non-setting clients.

[0096] On the other hand, assume that the provider deploying the cloud service using the collaboration server 400 is different from the providers deploying the cloud services using the authorization server 200 and the resource server 300. In this case, security and the contract may restrict an administrator of the collaboration server 400 from obtaining information about all tenants registered in the user management table 1200 and managed by the authorization server 200. Furthermore, the users registered in the user management table 1200 are not limited to the users of the collaboration server 400. Therefore, it is difficult for the administrator of the collaboration server 400 to perform the per-tenant permission setting for each tenant in advance, which includes all users who use the API of the resource server 300 via the collaboration server 400.

[0097] As a result, an undesirable discrepancy in the number of API usages between two or more tenants may occur, rendering the per-tenant permission setting ineffective.

[0098] In view of the above, the following, with reference to Fig. 12, Fig. 13 and Fig. 14, a system capable of solving the aforementioned problem according to a second exemplary embodiment is described in detail. A configuration according to the second exemplary embodiment is similar to the aforementioned configuration according to the first exemplary embodiment, with the exception of Fig. 6C and Fig. 9. Therefore, a redundant description of it is avoided. Furthermore, configurations and processing similar to those described in Fig. 6C and Fig. 9 are designated using the same numerals, and redundant description thereof is avoided.

[0099] Fig. 12 is a data table stored in the external memory of the database server 500 with which the authorization server 200 can communicate via the LAN 101 according to the second exemplary embodiment. Alternatively, the Fig. 12 may be stored in the external memory of the authorization server 200.

[0100] Fig. 12 illustrates a tenant individual detail setting management table 1900. The tenant individual detail setting management table 1900 consists of data columns for client ID 1901, unregistered tenant mode 1902, automatic registration 1903, automatic setting value 1904, setting upper limit value 1905, and setting upper limit mode 1906. Processing regarding the tenant individual detail setting management table 1900 will be described in detail below.

[0101] Fig. 13 illustrates a tenant single authorization settings screen 4000. The Fig. The screen illustrated in Figure 13 is a screen that can be displayed on the web browser 820, which is available to an administrator of the collaboration server 400 or a user thereof to whom administration is delegated. Fig. The screen illustrated in Fig. 13 is a screen that can be generated when the tenant single permission setting button 2004 is pressed on the API usage frequency limit management screen 2000 described with reference to Fig. 6A. The tenant individual authorization settings screen 4000 includes, in addition to the contents of the Fig. 6C illustrates characteristic features according to the second exemplary embodiment. The same numerals are assigned to components similar to those of the tenant single-admission setting screen 2200, and redundant description thereof is avoided.

[0102] The tenant single authorization setting screen 4000 includes fields for detailed setting 4001 and setting button 4002 in addition to the configuration of the tenant single authorization setting screen 2200. The setting button 4002 is a button operable to set and reflect a selection state of each item in the detailed setting 4001. When the setting button 4002 is pressed, information regarding an operation for "use by unregistered tenant," "automatic registration of unregistered tenant," and setting values ​​of "automatic registration" can be notified from the web browser 820 to the authorization server module 600.In response to the notification, the authorization server module 600 reflects the acquired information in each item of the tenant individual detailed setting management table 1900 with reference to the identified client ID. Specifically, the authorization server module 600 updates the values ​​of the client ID 1901, the unregistered tenant mode 1902, the automatic setting value 1903, the setting upper limit value 1905, and the setting upper limit mode 1906 in the tenant individual detailed setting management table 1900 based on the identified client ID.

[0103] Fig. 14 is a flowchart illustrating API upper limit verification processing that may be performed by the authorization server module 600. The authorization server module 600 performs the Fig. 14, if in each processing of step S1.11, step 2.10 and step S3.6 according to Fig. 7 is called. The Fig. 14, in addition to the contents of the processing flow illustrated with reference to Fig. 9, characteristic features of the second exemplary embodiment are shown. Steps that are similar to those already described in the Fig. 9 are designated by the same step numbers, and redundant description thereof is avoided.

[0104] In step S5.14, the authorization server module 600 confirms whether the tenant of the acquired tenant ID is a single setting target. Specifically, the authorization server module 600 confirms whether the acquired set of client ID and tenant ID is registered in the tenant single authorization setting table 1800. If it is determined that the acquired set of client ID and tenant ID is registered (YES in step S5.14), the authorization server module 600 then performs single upper limit verification processing in step S5.15. If it is determined that the acquired set of client ID and tenant ID is not registered (NO in step S5.14), the authorization server module 600 then confirms the unregistered tenant mode 1902 in the tenant single detail setting table 1900 based on the acquired client ID in step S8.1. If the non-registered tenant mode is “Reject” (YES in step S8.1), the authorization server module 600 then transmits a "rejection response" notification in step S8.2 and terminates the processing of the request in . Fig. 14. If the unregistered tenant mode is "allowed" (NO in step S8.1), the authorization server module 600 then confirms the automatic registration 1903 in the tenant individual details setting table 1900 based on the acquired client ID in step S8.3. If the automatic registration 1903 is "not required" (NO in step S8.3), the authorization server module 600 then performs the general upper limit verification processing in step S5.8. If the automatic registration 1903 is "required" (YES in step S8.3), the authorization server module 600 then acquires the tenant individual upper limit value sum 1904 from the tenant individual setting management table 1600, as well as the automatic setting value 1904 and the setting upper limit value 1905 from the tenant individual detailed setting management table 1900 based on the acquired client ID in step S8.4.

[0105] In step S8.5, the authorization server module 600 confirms whether the sum of the automatic setting value 1904 and the tenant individual upper limit value sum 1604 is equal to or less than the setting upper limit value 1905. If it is determined that the above sum is equal to or less than the setting upper limit value 1905 (YES in step S8.5), the authorization server module 600 then automatically registers the tenant in step S8.6. Specifically, the authorization server module 600 sets the acquired client ID, the acquired tenant ID, and the automatic setting value 1904 as upper limit values ​​in the tenant individual authorization setting management table 1800. Then, in step S5.15, the authorization server module 600 performs the individual upper limit verification processing. If it is determined that the above sum is greater than the setting upper limit value 1905 (NO in step S8.5), the authorization server module 600 then detects in step S8.7 the setting limit mode 1906 in the tenant individual detail setting table 1900 based on the acquired client ID, and confirms it.

[0106] If the setting upper limit mode 1906 is “Reject” (YES in step S8.7), the authorization server module 600 then transmits a “Rejection Response” notification in step S8.8, and ends the processing of the Fig. 14. If the setting upper limit mode 1906 is "Allow" (NO in step S8.7), the authorization server module 600 then performs the general upper limit verification processing in step S5.8.

[0107] Through the above processing, the administrator of the collaboration server 400 can set a control to be performed in response to an API usage request from a tenant that invalidates / has invalidated the tenant-per ...

[0108] Furthermore, in the present invention, the client is not limited to a service accessible via the Internet. For example, an application installed on a terminal device can be a client. Further examples

[0109] Embodiments of the present invention may also be implemented by a computer of a system or device that retrieves and executes computer-executable instructions recorded on a storage medium (e.g., a non-transitory computer-readable storage medium) to perform the functions of one or more of the above-described embodiments of the present invention, as well as by a method performed by the computer of the system or device, for example, by retrieving and executing the computer-executable instructions from the storage medium to perform the functions of one or more of the above-described embodiments.The computer may include one or more of a central processing unit (CPU), a microprocessing unit (MPU), or other circuitry, and may include a network of separate computers or separate computer processors. The computer-executable instructions may be provided to the computer, for example, from a network or the storage medium. The storage medium may include, for example, one or more of a hard disk, random access memory (RAM), read-only memory (ROM), distributed computing system memory, an optical disc (such as a compact disc (CD), a digital versatile disc (DVD), or a Blu-ray Disc (BD)™), a flash memory device, a memory card, and the like.

[0110] While the present invention has been described with reference to exemplary embodiments, it is to be understood that the invention is not limited to the disclosed exemplary embodiments. The scope of the following claims is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures and functions.

[0111] An authorization server system configured to restrict the use of a service provided over a network includes an authorization processing unit, a verification processing unit, a determination unit, and a restriction unit. The determination unit is configured to determine whether the number of uses of the mathematical function called by the client to use the service is greater than the upper limit when the authorization information is submitted by the authorization processing unit and when the authorization information is verified by the verification processing unit.

Claims

[1] An authorization server system configured to restrict the use of a service of a resource server system provided over a network, the authorization server system comprising: an authorization processing device configured to output authorization information in response to an authorization process performed to allow a user to transfer authorization to use the service to a client; and a verification processing device configured to verify the authorization information to be transmitted when the client, which has acquired the authorization information issued by the authorization processing device, uses the service, and configured to allow the client to use the service with the user authorization based on a result of the verification, characterized bythat the authorization server system additionally has: a determining device configured to determine whether the number of uses of a mathematical function called by the client to use the service is greater than an upper limit, wherein use of the mathematical function comprises use of an application programming interface of the resource server system to use the service; and a restriction device configured to restrict the use of the mathematical function when the determination device determines that the number of uses is greater than the upper limit, wherein the determining means is configured to determine whether the number of uses of the mathematical function called by the client to use the service is greater than the upper limit when the authorization information is submitted by the authorization processing means and when the authorization information is verified by the verification processing means. [2] Authorization server system according to claim 1, additionally comprising: a holding device configured to hold a table for registering information in which a group ID for identifying a group to which the user belongs is associated with the upper limit of the number of uses of the mathematical function for each group ID, wherein the determining means is configured to identify the group ID corresponding to the user when the client uses the service with the user authorization, and to determine whether the number of uses of the mathematical function called by the client is greater than the upper limit by referring to the upper limit of the number of uses of the mathematical function corresponding to the identified group ID. [3] An authorization server system according to claim 2, further comprising a providing device configured to provide a management screen usable for setting rejection and / or approval with respect to the use of the mathematical function for each group ID, wherein an error response is performed in response to a client access with a user authorization corresponding to a denied group ID designated on the screen. [4] The authorization server system according to claim 3, wherein the providing means is configured to provide the management screen for setting the upper limit of the number of uses of the mathematical function for an authorized group ID designated via the management screen, and the table held by the holding means includes registered information about the authorized group ID designated via the management screen in association with the upper limit of the number of uses of the mathematical function set on the management screen. [5] The authorization server system according to claim 3 or 4, wherein the providing means is configured to provide the management screen for setting rejection or approval with respect to the use of the mathematical function in response to an access of the client with a user authorization corresponding to an unregistered group ID for which neither rejection nor approval is designated via the management screen, and the providing means is further configured to provide the management screen for setting the upper limit of the number of uses of the mathematical function to be set upon automatic registration in the table, and for setting whether to automatically register the unregistered client group ID in the table in response to the access of the client with a user authorization corresponding to the unregistered group ID. [6] A control method for controlling an authorization server system configured to restrict the use of a service of a resource server system provided over a network, the method being carried out by the authorization server system and comprising the steps of: causing an authorization processing device to output authorization information in response to an authorization process performed to allow a user to transfer authorization to use the service to a client; and Causing a verification processing device to verify the authorization information to be transmitted when the client that has acquired the authorization information issued by the authorization processing device uses the service, and causing the verification processing device to allow the client to use the service with the user authorization based on a result of the verification, characterized by that the procedure additionally comprises the steps: Causing a determining device to determine whether the number of uses of a mathematical function called by the client to use the service is greater than an upper limit, wherein a use of the mathematical function comprises a use of an application programming interface of the resource server system to use the service; and Causing a restriction device to restrict the use of the mathematical function if the determination device determines that the number of uses is greater than the upper limit, wherein the determining means determines whether the number of uses of the mathematical function called by the client to use the service is greater than the upper limit when the authorization information is submitted by the authorization processing means and when the authorization information is verified by the verification processing means. [7] A control method according to claim 6, additionally comprising the steps of: Causing a holding device to hold a table for registering information in which a group ID for identifying a group to which the user belongs is associated with the upper limit of the number of uses of the mathematical function for each group ID, wherein the determining means identifies the group ID corresponding to the user when the client uses the user's service, and determines whether the number of uses of the mathematical function called by the client is greater than the upper limit by referring to the upper limit of the number of uses of the mathematical function corresponding to the identified group ID. [8] A control method according to claim 7, additionally comprising the steps of: Causing a provisioning device to provide an administration screen usable for setting rejection and / or approval with respect to the use of the mathematical function for each group ID, wherein an error response is performed in response to a client access with a user authorization corresponding to a denied group ID designated on the screen. [9] The control method according to claim 8, wherein the providing means provides the management screen for setting the upper limit of the number of uses of the mathematical function for a permitted group ID designated via the management screen, and the table held by the holding means includes registered information about the permitted group ID designated via the management screen in association with the upper limit of the number of uses of the mathematical function set on the management screen. [10] The control method according to claim 8 or 9, wherein the providing means provides the management screen for setting rejection or approval with respect to the use of the mathematical function in response to an access of the client with a user authorization corresponding to an unregistered group ID for which neither rejection nor approval is designated via the management screen, and the providing means further provides the management screen for setting the upper limit of the number of uses of the mathematical function to be set upon automatic registration in the table, and sets whether to automatically register the unregistered client group ID in the table in response to the access of the client with a user authorization corresponding to the unregistered group ID. [11] A program for causing a computer to carry out the control method according to any one of claims 6 to 10.

Images