Resource server, method for controlling the same, and system

Abstract

To guarantee the security level of tenants.SOLUTION: A resource server system includes: an acquisition unit that acquires a resource request indicating that a user, who belongs to a second tenant at a higher rank than a first tenant, requests the use of resources of the first tenant; and a use control unit that, when it is set that multi-element authentication is required for using the resources of the first tenant, permits the user's use of the resources on the basis of the resource request indicating that the user has performed the multi-element authentication.SELECTED DRAWING: Figure 10

Description

[Technical Field]

[0001] The present invention relates to a resource server, a control method thereof, and a system thereof. [Background technology]

[0002] In recent years, the number of web services built and operated on cloud services deployed on the Internet has been increasing. Systems running on cloud services typically use a multi-tenant approach, in which each customer's resources are managed in a logically separated data space. A system in which tenants at higher levels in a tree structure are permitted to access the resources of tenants at lower levels is also known (Patent Document 1). OAuth 2.0 has been published as one of the framework specifications for delegating user privileges in web services (Non-Patent Document 1). In OAuth 2.0, authentication and authorization servers and resource servers cooperate by exchanging authentication and authorization information with each other. Access tokens are generally used to exchange authentication and authorization information, and JWT (JSON Web Token) has been published as one of the access token specifications (Non-Patent Document 2). JWT is a token specification that represents attribute information using a data structure based on JSON (JavaScript Object Notation). Furthermore, JWS (JSON Web Signature) has been published as a specification related to JWT (Non-Patent Document 3). On the other hand, multi-factor authentication is also being adopted for user authentication, which uses two or more different authentication factors from the three authentication factors of knowledge information, possession information, and biometric information. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6957223 [Non-patent literature]

[0004] [Non-Patent Document 1] D. Hardt, “The OAuth 2.0 Authorization Framework”, [online], August 2012, [Retrieved April 22, 2020], Internet<URL: https: / / tools.ietf.org / html / rfc6749> [Non-patent document 2] M. Jones, J. Bradley, N. Sakimura, “JSON Web Token(JWT)”, [online], May 2015, [searched on April 22, 2020], Internet<URL: https: / / tools.ietf.org / html / rfc7519> [Non-patent document 3] M. Jones, J. Bradley, N. Sakimura, “JSON Web Signature (JWS)”, [online], May 2015, [Retrieved April 22, 2020], Internet<URL: https: / / tools.ietf.org / html / rfc7515> Summary of the Invention [Problem to be solved by the invention]

[0005] Whether or not to require multi-factor authentication for users can be configured for each tenant. A tenant administrator ensures a specific security level for the tenant's resources by requiring multi-factor authentication to use the resources of his or her tenant. However, if a user of a higher-level tenant can use the resources of a lower-level tenant without restriction, this security level may not be ensured. Some aspects of the present invention aim to ensure the security level of a tenant. [Means for solving the problem]

[0006] According to some embodiments, a resource server system is provided, the resource server system including: an acquisition means for acquiring a resource request indicating that a user belonging to a second tenant above a first tenant is requesting use of a resource of the first tenant; and a usage control means for permitting the user to use the resource, when multi-factor authentication is set to be required to use the resource of the first tenant, based on the resource request indicating that the user has performed the multi-factor authentication. [Effects of the Invention]

[0007] According to the above embodiment, the security level of the tenant can be guaranteed. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a block diagram illustrating an example of the configuration of an access control system according to a first embodiment. [Figure 2] FIG. 2 is a block diagram illustrating an example of the hardware configuration of an information processing apparatus according to the first embodiment. [Figure 3] FIG. 2 is a block diagram illustrating an example of the functional configuration of each server according to the first embodiment. [Figure 4] FIG. 3 is a diagram illustrating an example of information managed by the authentication and authorization server according to the first embodiment. [Figure 5] FIG. 2 is a diagram illustrating an example of information managed by a resource server according to the first embodiment. [Figure 6] FIG. 3 is a sequence diagram illustrating an example of the operation of the access control system according to the first embodiment. [Figure 7] FIG. 4 is a flowchart illustrating an example of the operation of authentication processing according to the first embodiment. [Figure 8] FIG. 4 is a flowchart illustrating an example of the operation of a token issuing process according to the first embodiment. [Figure 9] FIG. 4 is a flowchart illustrating an example of operation of a usage control process according to the first embodiment. [Figure 10] FIG. 4 is a flowchart illustrating an example of operation of a usage control process according to the first embodiment. [Figure 11] FIG. 10 is a diagram illustrating an example of information managed by a resource server according to the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the scope of the invention claimed. Although multiple features are described in the embodiments, not all of these multiple features are necessarily essential to the invention, and multiple features may be combined arbitrarily. Furthermore, in the accompanying drawings, the same reference numerals are used to designate the same or similar components, and redundant explanations will be omitted.

[0010] First Embodiment [Access control system configuration example] Referring to FIG. 1, an example configuration of an access control system 100 according to the first embodiment will be described. The access control system 100 includes an authentication and authorization server 101, a resource server 102, and a client 103. The authentication and authorization server 101 is connected to the Internet 120 via a local area network (LAN) 111. The resource server 102 is connected to the Internet 120 via a LAN 112. The client 103 is connected to the Internet 120 via a LAN 113. The client 103 can communicate with each of the authentication and authorization server 101 and the resource server 102 via these networks. The client 103 obtains an access token from the authentication and authorization server 101. The client 103 uses the access token obtained from the authentication and authorization server 101 to receive a Web service (hereinafter simply referred to as a "service") from the resource server 102. Specifically, the client 103 uses a resource managed by the resource server 102. The resource may be data, and the use of the resource may be access to the data. The client 103 may be, for example, an image forming device.

[0011] In the example of FIG. 1, the access control system 100 includes one authentication and authorization server 101, one resource server 102, and one client 103. Alternatively, the access control system 100 may include multiple authentication and authorization servers 101, multiple resource servers 102, or multiple clients 103. A system consisting of one or more servers is called a server system. Specifically, the authentication and authorization server system includes one authentication and authorization server 101 or multiple authentication and authorization servers 101. The resource server system includes one resource server 102 or multiple resource servers 102. In the example of FIG. 1, the authentication and authorization server 101 is represented as a single server. Alternatively, the authentication and authorization server 101 may be divided into an authentication server and an authorization server. The authentication and authorization server 101 and the resource server 102 may be connected to the same LAN. The client 103 may be connected to the same LAN as the authentication and authorization server 101 or the resource server 102.

[0012] [Example of hardware configuration of information processing device] An example of the hardware configuration of the information processing device 200 will be described with reference to Fig. 2. The information processing device 200 may also be called a computer. The information processing device 200 may be used to configure any of the authentication and authorization server 101, the resource server 102, and the client 103. Each of the authentication and authorization server 101, the resource server 102, and the client 103 may be configured by one information processing device 200 or by multiple information processing devices 200.

[0013] The information processing device 200 includes a CPU (Central Processing Unit) 201, a memory 202, a storage device 203, an input / output (I / O) interface 204, a video interface 205, and a communication interface 206. These components are connected to one another via a system bus 207. The CPU 201 is a processor that controls the components via the system bus 207 and calculates and processes data. The memory 202 is a device that stores data and programs, and is configured, for example, by a random access memory (RAM) or a read-only memory (ROM). The storage device 203 is a device that semi-permanently stores data and programs. The storage device 203 is configured, for example, by a hard disk drive (HDD) or a solid-state drive (SSD) 113. The operation of the information processing device 200 is realized by the CPU 201 reading a program stored in the storage device 203 into the memory 202 and executing the program. The CPU 201 may read a program from an external device into the memory 202 via the communication interface 206.

[0014] The video interface 205 controls display output to the display device 213. The display device 213 may be a cathode ray tube display, a liquid crystal display, or another type of display device. Input devices such as a keyboard 211 and a pointing device 212 are connected to the I / O interface 204. A user of the information processing device 200 issues operation commands to the information processing device 200 by operating the keyboard 211. The pointing device 212 is used to move a cursor on the display device 213 to select or operate a menu or object. Furthermore, when the display device 213 can acquire operation input via a touch panel or the like, the display device 213 serves as both an output device and an input device. The communication interface 206 is an interface for connecting to a network 214 (for example, LANs 111 to 113).

[0015] The information processing device 200 may not include some of the components shown in Fig. 2, or may include other components. The information processing device 200 may not include the I / O interface 204 and the video interface 205, and may perform input and output through a communication interface. In the example of Fig. 2, the input device and the display device are configured as external devices of the information processing device 200. Alternatively, the input device and the display device may be integrated into the information processing device 200.

[0016] [Access token configuration example] An example of an access token used in this embodiment will be described. In this embodiment, JWS (JSON Web Signature) is used to store access token information and user information in the access token. JWS (JSON Web Signature) is a method of protecting and representing content expressed in JWT (JSON Web Token) using a digital signature or MAC (Message Authentication Code). JWT is a method of expressing URL (Uniform Resource Locator)-safe claims using a JSON (JavaScript Object Notation)-based data structure. A claim in JSON refers to a data item in the payload. Specifications for JWS and JWT are published in RFC7515 and RFC7519, respectively. An access token in which information is stored using JWS is referred to as a JWS access token. The user information included in the JWS access token is information about the user (resource owner) associated with the JWS access token.

[0017] The claims included in the JWS access token used in this embodiment are shown in Table 1. The JWS access token may also include claims defined in JWT. In Table 1, the JWS access token is represented as JWT.

[0018] [Table 1]

[0019] The claims included in the claim name class "Registered Claim" in Table 1 are predefined in RFC7519. The dates and times specified in "exp", "nbf", and "iat" are expressed in IntDate format, and are JSON numeric values ​​representing the number of seconds since 1970-01-01T00:00:00Z UTC. Use of the claims included in the claim name class "Registered Claim" is optional.

[0020] Each claim in the claim name class "Private Claim" in Table 1 is a claim used under the agreement between the JWS Access Token Issuer and the Consumer. Each claim in "Private Claim" is prohibited from clashing with other claim names.

[0021] In this embodiment, the authentication and authorization server 101 includes each claim of the claim name class "Private Claim" in Table 1 in the JWS access token. "authz:scopes" and "authz:client_id" represent information authorized in the JWS access token. Such information is referred to as authorization information. "ext:fname", "ext:lname", "ext:tenantid@recm", "ext:email@req", "ext:appid", and "ext:ismfa" represent attribute information of the user (subject) associated with the JWS access token.

[0022] The authentication and authorization server 101 encodes the claims in Table 1 as JSON in accordance with RFC7519. Then, the authentication and authorization server 101 expresses the digitally signed content (the JSON representation of the claims in Table 1, i.e., the JWT payload) as a compact, URL-safe string in accordance with the compact serialization specification of RFC7515. In this way, the JWS access token of this embodiment is expressed in accordance with the JWS compact serialization specification. Specifically, the JWS access token is a string in which the encoded JWS header, the encoded JWT payload, and the encoded JWS signature are concatenated in this order, with periods (.) as delimiters.

[0023] In this embodiment, the JWS header includes an “alg” (algorithm) that identifies the cryptographic algorithm used to sign the JWS. In this embodiment, “RS256” (RSASSA-PKCS1_v1_5 using SHA-256) is used as “alg.” The string “RS256” is registered as the “alg” value in the IANA JSON Web Signature and Encryption Algorithms registry and is defined in section 3.1 of the JSON Web Algorithms (JWA) specification (RFC7518). The authentication and authorization server 101 generates a private key and public key pair to be used with the cryptographic algorithm “RS256” in advance and manages it in an encryption key management table (described later). In addition, the resource server 102 obtains a public key for verifying the JWS signature from the authentication and authorization server 101 before verifying the JWS access token (for example, when the resource server 102 is started for the first time).

[0024] [Server functional configuration example] An example of the functional configuration of the authentication and authorization server 101 will be described with reference to FIG. 3(a). The authentication and authorization server 101 includes the functional blocks shown in FIG. 3(a). The authentication and authorization server 101 may not include some of the functional blocks shown in FIG. 3(a), or may include other functional blocks. Each functional block shown in FIG. 3(a) may be divided into multiple functional blocks. Two or more functional blocks shown in FIG. 3(a) may be integrated into one functional block. Each functional block in FIG. 3(a) may be implemented by the CPU 201 of an information processing device 200 used as the authentication and authorization server 101 executing a program loaded into a memory 202 of the information processing device 200. Alternatively, some or all of the functional blocks shown in FIG. 3(a) may be implemented by a dedicated circuit such as an ASIC (Application Specific Integrated Circuit). The same description applies to the functional blocks of the resource server 102, which will be described later.

[0025] The tenant management unit 301 manages tenant information. A tenant is a data space created for each customer. The user management unit 302 manages user information. The client management unit 303 manages client information. The authentication unit 304 performs authentication processing for users and clients. For example, the authentication unit 304 performs authentication using not only knowledge information (e.g., ID and password) but also information other than knowledge information, such as possession information or biometric information, as necessary, based on the multi-factor authentication policy (hereinafter referred to as MFA policy) of the tenant to which the user belongs. The token issuance unit 305 issues JWS access tokens. The token management unit 306 manages information on JWS access tokens issued by the token issuance unit 305. The resource server information management unit 307 manages information on the resource server 102 that cooperates with the authentication and authorization server 101.

[0026] An example of information managed by the authentication and authorization server 101 will be described with reference to FIG. 4. This information is stored, for example, in the storage device 203 of the information processing device 200 used as the authentication and authorization server 101. In the following description, the information is managed in a table format. Alternatively, the information may be managed in other formats. The information described below is used to issue and verify JWS access tokens, as will be described later.

[0027] The tenant management table 401 includes information on one or more tenants. The tenant management table 401 is managed by the tenant management unit 301. Each entry in the tenant management table 401 represents information on an individual tenant. The entries in the tenant management table 401 are created and edited, for example, by the operator of the authentication and authorization server 101 or the tenant administrator. "Tenant ID" represents the ID (i.e., identifier) ​​of an individual tenant. "Parent Tenant ID" represents the identifier of the parent tenant of an individual tenant. By including "Parent Tenant ID" in the tenant management table 401, the tenant management table 401 defines a tree structure of multiple tenants. "MFA Policy" represents the MFA policy of an individual tenant.

[0028] The user management table 402 includes information on one or more users. The user management table 402 is managed by the user management unit 302. Each entry in the user management table 402 represents information on an individual user. The entries in the user management table 402 are created and edited, for example, by a tenant administrator. "User ID" represents the identifier of an individual user. "UUID" represents the internal representation of the user's identifier. "Password" represents the password of an individual user. "MFA Key" represents the MFA key for generating a one-time password (OTP) used for multi-factor authentication of an individual user.

[0029] The user attribute management table 403 includes attribute information of one or more users. The user attribute management table 403 is managed by the user management unit 302. Each entry in the user attribute management table 403 represents attribute information of an individual user. The entries in the user attribute management table 403 are generated and edited, for example, by a tenant administrator. "UUID" represents the internal representation of a user's identifier. The "UUID" in the user attribute management table 403 has the same numbering system as the "UUID" in the user management table 402. "First Name" represents the last name of an individual user. "Last Name" represents the first name of an individual user. "Locale" represents the locale of an individual user. "Tenant ID" represents the identifier of the tenant to which an individual user belongs. The "Tenant ID" in the user attribute management table 403 has the same numbering system as the "Tenant ID" in the tenant management table 401. "Email" represents the email address of an individual user. "Service ID" represents the identifier of a service available to an individual user.

[0030] The service management table 404 includes information on one or more services that use resources (e.g., data) provided by one or more resource servers (e.g., resource server 102). The service management table 404 is managed by the resource server information management unit 307. Each entry in the service management table 404 represents information on an individual service. The entries in the service management table 404 are created and edited, for example, by the operator of the authentication / authorization server 101 or the operator of the resource server 102. "Service ID" represents the identifier of an individual service. The "Service ID" in the service management table 404 has the same numbering system as the "Service ID" in the user attribute management table 403. "Scope" represents the content specified by the scope of an authorization request based on the OAuth 2.0 protocol or the like when an individual service is represented as a resource. "URL" represents the URL of the resource server (e.g., resource server 102) that provides the individual service.

[0031] The token management table 405 includes information on one or more tokens. The token management table 405 is managed by the token management unit 306. Each entry in the token management table 405 represents information on an individual token. The entries in the token management table 405 are generated and edited, for example, by the token management unit 306. "Token ID" represents the identifier of an individual token. "Token Type" represents the type of an individual token and has a value representing an access token, authorization code, etc. "Expiration Time" represents the expiration time of an individual token in seconds. "Scope" represents the scope of an individual token. The scope represents the content specified in an authorization request using the OAuth2.0 protocol, etc. "Scope" in the token management table 405 has the same numbering system as "Scope" in the service management table 404. "Grant Type" represents the grand type of an individual token. The grand type is used in the OAuth2.0 protocol, etc. "User UUID" represents the UUID (Universally Unique Identifier) ​​of the user who requested the issuance of an individual token. The “User UUID” in the token management table 405 has the same number system as the “User UUID” in the user management table 402 .

[0032] The token attribute management table 406 includes attribute information of one or more tokens. The token attribute management table 406 is managed by the token management unit 306. Each entry in the token attribute management table 406 represents attribute information of an individual token. The entries in the token attribute management table 406 are generated and edited, for example, by the token management unit 306. "Token ID" represents the identifier of an individual token. "Token ID" in the token attribute management table 406 has the same numbering system as "Token ID" in the token management table 405. "UUID" represents the UUID linked to the token ID of an individual token. "Application ID" represents the identifier of the application that uses an individual token.

[0033] The encryption key management table 407 contains information about encryption keys used for digital signatures of access tokens for one or more services. The encryption key management table 407 is managed by the authentication unit 304. Each entry in the encryption key management table 407 represents information about an encryption key for an individual service. The entries in the encryption key management table 407 are generated and edited, for example, by the authentication unit 304. "Service ID" represents the identifier of an individual service. The "Service ID" in the encryption key management table 407 has the same numbering system as the "Service ID" in the service management table 404. "Key ID" represents the identifier of an encryption key used for an individual service. "Algorithm" represents the encryption algorithm used for an individual service. "Private Key" represents the secret key used to generate a signature for an individual service. "Public Key" represents the public key used to verify the signature for an individual service. In the encryption key management table 407, some of the values ​​of "Private Key" and "Public Key" are omitted.

[0034] An example of the functional configuration of the resource server 102 will be described with reference to FIG. 3(b). The resource server 102 includes the functional blocks shown in FIG. 3(b). The resource management unit 311 manages information about resources in the resource server 102. The management of resource information may include defining the correspondence between scopes and resources and controlling access to resources. The token management unit 312 manages information about JWS access tokens. The token validation unit 313 verifies JWS access tokens. The authorization server information management unit 314 manages information about the authentication and authorization server 101 that cooperates with the resource server 102.

[0035] 5, an example of information managed by the resource server 102 will be described. This information is stored in the storage device 203 of the information processing device 200 used as the resource server 102, for example.

[0036] The tenant management table 501 includes information on one or more tenants. The tenant management table 501 is managed by, for example, the resource management unit 311. The information included in the tenant management table 501 may be the same as that in the tenant management table 401. The tenant management table 501 may be managed independently of the tenant management table 401, or may be synchronized with the tenant management table 401. The resource server 102 may use the tenant management table 401 managed by the authentication and authorization server 101, instead of managing the tenant management table 501 in its own storage device 203.

[0037] The print information table 502 includes information on one or more print jobs. A print job is an example of a resource (e.g., data) managed by the resource server 102. The print information table 502 is managed by the resource management unit 311. Each entry in the print information table 502 represents information on an individual print job. An entry in the print information table 502 may be generated, for example, when the resource server 102 receives information on a print job. The resource server 102 may operate as a print server or may operate in cooperation with a print server. "Print job ID" represents the ID of an individual print job. "Print data" represents data printed by an individual print job. "Number of prints" represents the number of sheets printed by an individual print job. "Tenant ID" represents the ID of the tenant to which the user who submitted the individual print job belongs.

[0038] [Example of access control system operation] An example of the overall operation of the access control system 100 will be described with reference to Fig. 6. The operation of the access control system 100 is performed by cooperation between the authentication and authorization server 101, the resource server 102, and the client 103. In the following operation, a request may be sent from the client 103 to the server (the authentication and authorization server 101 or the resource server 102) using one message or multiple messages.

[0039] In S601, the client 103 sends an authentication request to the authentication and authorization server 101, indicating that the user of the client 103 is requesting self-authentication. The client 103 includes the ID and password of the user of the client 103 in the authentication request. If the MFA policy of the tenant to which the user belongs is "required," the client 103 also includes an MFA code in the authentication request. A one-time password (OTP) may be used as the MFA code. In this case, the user shares key information with the authentication and authorization server 101 in advance on their mobile terminal (not shown), and generates an OTP on the mobile terminal based on the key information. The authentication and authorization server 101 verifies whether the OTP included in the authentication request sent from the client 103 is correct. Possession information other than the OTP may be used as the MFA code, or biometric information may be used instead of or in addition to possession information.

[0040] In S602, the authentication and authorization server 101 performs user authentication processing in response to the authentication request, and responds with an authentication token if authentication is successful. In S603, the client 103 sends an access token request to the authentication and authorization server 101, requesting the issuance of an access token, in accordance with the OAuth 2.0 protocol specifications. The client 103 includes the authentication token acquired in S602 in the access token request. In S604, the authentication and authorization server 101 issues a JWS access token in response to the access token request, and sends this JWS access token to the client 103. For example, the authentication and authorization server 101 sends the JWS access token in the following HTTP response. HTTP / 1.0 200 OK Content-Type: application / json Date: Thu, 15 Sep 2016 07:30:40 GMT { "jws_token": "eyJr(abbreviated)YhA" } In this HTTP response, some strings in the JWS access token are omitted.

[0041] In S605, the client 103 sends a resource request to the resource server 102, indicating that the user is requesting use of a resource. The resource request specifies the resource to be used. The client 103 includes the JWS access token acquired in S604 in the resource request. For example, when making a REST API call to request use of a resource, the client 103 sets the JWS access token in the HTTP Authentication header as follows: Authorization: Bearer eyJr(abbreviated)YhA Here too, some strings in the JWS Access Token are omitted.

[0042] In S606, the resource server 102 verifies the signature attached to the JWS access token included in the resource request in response to the resource request. If the signature verification is successful, in S607 the resource server 102 verifies access to the resource. If the access verification is successful, in S608 the resource server 102 executes processing in response to the resource request. In S609, the resource server 102 transmits the processing result of the resource request (e.g., success or error) to the client 103.

[0043] [Example of authentication processing by the authentication / authorization server 101] The authentication processing executed by the authentication / authorization server 101 in S601 and S602 in Fig. 6 will be described in detail with reference to Fig. 7. The authentication / authorization server 101 waits for an authentication request sent from one or more clients included in the access control system 100, and starts the operation in Fig. 7 in response to receiving an authentication request. In the following description, it is assumed that the authentication / authorization server 101 receives an authentication request from the client 103. Each step of the method in Fig. 7 is executed by, for example, the authentication unit 304 of the authentication / authorization server 101.

[0044] In S701, the authentication and authorization server 101 receives an authentication request from the client 103. The authentication request may be an HTTP request as shown below. POST / auth / token HTTP / 1.1 Host: auth.server.example.com Content-Type: application / x-www-form-urlencoded user_id=jane.doe@101aa &password=********** &mfa_code=123456 This HTTP request includes the user ID of the user of client 103 ("jane.doe@101aa"), this user's password ("**********"), and the MFA code ("123456").

[0045] In S702, the authentication and authorization server 101 determines whether an MFA code is missing from the authentication request. If the authentication and authorization server 101 determines that an MFA code is missing from the authentication request (YES in S702), the process proceeds to S706. Otherwise (NO in S702), the process proceeds to S703. Specifically, if the tenant to which the user who made the authentication request belongs does not require multi-factor authentication, the authentication and authorization server 101 determines that an MFA code is missing from the authentication request regardless of whether the authentication request includes an MFA code. If the tenant requires multi-factor authentication and the authentication request includes an MFA code, the authentication and authorization server 101 determines that an MFA code is missing from the authentication request. If the tenant requires multi-factor authentication and the authentication request does not include an MFA code, the authentication and authorization server 101 determines that an MFA code is missing from the authentication request.

[0046] A specific method for determining whether the tenant to which the user who has made the authentication request belongs requires multi-factor authentication will be described below. The authentication and authorization server 101 refers to the user management table 402 and obtains the UUID ("UUID") associated with (i.e., included in the same entry as) the user ID ("User ID") obtained in S702. The authentication and authorization server 101 then refers to the user attribute management table 403 and obtains the tenant ID ("Tenant ID") associated with this UUID ("UUID"). The authentication and authorization server 101 then refers to the tenant management table 401 and obtains the MFA policy ("MFA Policy") associated with this tenant ID ("Tenant ID"). If the value of the MFA policy is "Required," the authentication and authorization server 101 determines that this tenant requires multi-factor authentication. If the value of the MFA policy is "None," the authentication and authorization server 101 determines that this tenant does not require multi-factor authentication.

[0047] If it is determined that the authentication request does not lack an MFA code, then in S703 the authentication / authorization server 101 determines whether the information included in the authentication request matches the information managed by the authentication / authorization server 101. If the authentication / authorization server 101 determines that this information matches (YES in S703), it transitions the process to S704, and otherwise (NO in S703), it transitions the process to S705.

[0048] First, the authentication and authorization server 101 determines whether the combination of the user ID and password included in the authentication request matches the combination of the user ID ("User ID") and password ("Password") managed in the user management table 402. Furthermore, if it is determined in S702 that the tenant requires multi-factor authentication, the authentication and authorization server 101 determines whether the MFA code included in the authentication request matches an OTP generated from an MFA key ("MFA Key") managed in the user management table 402. The OTP may be generated using TOTP (RFC6238), which uses a key shared between the client 103 and the authentication and authorization server 101 and the current date and time. If all of this information matches, the authentication and authorization server 101 transitions the process to S704, and if any of it does not match, the process transitions to S705.

[0049] If it is determined that the information included in the authentication request matches the information managed by the authentication and authorization server 101, the authentication and authorization server 101 performs processing for successful authentication in S704. Specifically, the authentication and authorization server 101 generates an authentication token, which is a random character string. Thereafter, the authentication and authorization server 101 transmits a response to the client 103, which includes the following message, which includes this authentication token ("authn_token") and a flag ("is_mfa") indicating whether the user has performed multi-factor authentication: { "authn_token": "5f330ee6-664d-4255-ae4c-9c0503ee8b3b-01-933b519f", "is_mfa": "true" } Furthermore, the authentication and authorization server 101 adds information about the issued authentication token to the token management table 405 and the token attribute management table 406. Specifically, the authentication and authorization server 101 adds a new entry to the token management table 405, sets the ID of the generated authentication token in the token ID ("Token ID") of this entry, sets a value representing the authentication token in the token type ("Token Type"), and sets the UUID of the user to whom the authentication token is to be issued in the user UUID ("User UUID"). The authentication and authorization server 101 also adds a new entry to the token attribute management table 406, sets the ID of the generated authentication token in the token ID ("Token ID") of this entry, and sets a UUID linked to the token ID in the UUID ("UUID").

[0050] If the authentication and authorization server 101 determines that the information included in the authentication request does not match the information managed by the authentication and authorization server 101, then in S705 the authentication and authorization server 101 notifies the user of the client 103 that the authentication has failed. If the authentication request is determined to lack an MFA code, then in S706 the authentication and authorization server 101 notifies the user of the client 103 that an MFA code needs to be entered.

[0051] [Example of access token issuance process by the authentication / authorization server 101] The access token issuing process executed by the authentication and authorization server 101 in S603 and S604 of Fig. 6 will be described in detail with reference to Fig. 8. The authentication and authorization server 101 waits for an access token request sent from one or more clients included in the access control system 100, and starts the operation of Fig. 8 in response to receiving an access token request. In the following description, it is assumed that the authentication and authorization server 101 receives an access token request from the client 103. The steps of the method of Fig. 8 are executed by, for example, the token issuing unit 305 of the authentication and authorization server 101.

[0052] 8, a JWS access token is issued and verified using a flow compliant with the Resource Owner Password Credentials Grant in OAuth 2.0. Alternatively, a Client Credentials Grant, Implicit Grant, Authorization Code Grant, etc. in OAuth 2.0 may be used.

[0053] In S801, the authentication and authorization server 101 receives an access token request from the client 103. The access token request may be an HTTP request as shown below. GET / authz / token HTTP / 1.1 Host: auth.server.example.com Content-Type: application / x-www-form-urlencoded grant_type=password &authn_token=5f330ee6-664d-4255-ae4c-9c0503ee8b3b-01-933b519f &is_mfa=true &scope=client.StoreService This HTTP request includes an authentication token ("5f330ee6-664d-4255-ae4c-9c0503ee8b3b-01-933b519f"). Alternatively, the access token request may include a user ID and password as request parameters, as specified in the Resource Owner Password Credentials Grant in OAuth 2.0.

[0054] In S802, the authentication and authorization server 101 verifies the authentication token included in the access token request received in S801. Specifically, the authentication and authorization server 101 determines whether the authentication token included in the access token request matches an authentication token managed by the authentication and authorization server 101. If the authentication and authorization server 101 determines that these authentication tokens match, it determines that the authentication token verification has been successful (YES in S802) and transitions the process to S803. Otherwise, the authentication and authorization server 101 determines that the authentication token verification has failed (NO in S802) and transitions the process to S805. As described above, the authentication token issued by the authentication and authorization server 101 is stored in the token ID ("Token ID") of the token management table 405.

[0055] In S804, the authentication and authorization server 101 verifies the resource usage authority of the user who requested the access token received in S801. If the authentication and authorization server 101 determines that the user has resource usage authority (YES in S803), it transitions the process to S804, and otherwise (NO in S803), it transitions the process to S805.

[0056] A specific method for verifying resource usage authority will be described below. The authentication and authorization server 101 refers to the token attribute management table 406 and obtains the user's UUID ("UUID") associated with the token ID ("Token ID") of the authentication token included in the access token request received in S801. Then, the authentication and authorization server 101 refers to the user attribute management table 403 and obtains the service ID ("Service ID") associated with the UUID. Then, the authentication and authorization server 101 refers to the service management table 404 and obtains the scope ("Scope") associated with this service ID. If a scope corresponding to the user's UUID exists in this scope, the authentication and authorization server 101 determines that the user has resource usage authority. If a scope corresponding to the user's UUID does not exist in this scope, the authentication and authorization server 101 determines that the user does not have resource usage authority.

[0057] If it is determined in S803 that the user has permission to use the resource, in S804 the authentication and authorization server 101 generates a JWS access token and responds to the client 103 with this token. The authentication and authorization server 101 also adds information about the issued JWS access token to the token management table 405 and the token attribute management table 406. Specifically, the authentication and authorization server 101 adds a new entry to the token management table 405, sets the ID of the generated JWS access token in the token ID ("Token ID") of this entry, sets a value representing the access token in the token type ("Token Type"), and sets the UUID of the user to whom the JWS access token is to be issued in the user UUID ("User UUID"). The authentication and authorization server 101 also adds a new entry to the token attribute management table 406, sets the ID of the generated JWS access token in the token ID ("Token ID") of this entry, and sets the UUID associated with the token ID in the UUID ("UUID").

[0058] A specific example of a generated JWS access token will be described. The authentication and authorization server 101 generates a JWT that will be the payload of the JWS access token. This JWT may include the claims included in the JWS token in Table 1.

[0059] For example, the authentication and authorization server 101 refers to the encryption key management table 407, acquires the "Key ID" and "Algorithm" associated with the service ID identified in S803, and sets these in the JWS header. Furthermore, the authentication and authorization server 101 sets "type" in the JWS header to "JWT."

[0060] Next, the authentication and authorization server 101 sets a value associated with the user who requested the issuance of the JWS access token as the JWT payload. For example, the JWT payload has the values ​​shown in Table 2 below.

[0061] [Table 2]

[0062] "iss" is the URI (Uniform Resource Identifier) ​​of the authentication and authorization server 101. "sub" is the UUID of the user who requested the issuance of the JWS access token. "aud" is the URI of the resource server corresponding to the scope verified in S803, and is the value of "URL" in the service management table 404. "exp" is the value 3600 seconds after the issuance of the JWS access token. "nbf" and "iat" are the date and time when the JWS access token was issued. "jti" is the ID of the JWS access token.

[0063] "authz:scopes" is the value of "Scopes" in the token management table 405. "authz:client_id" is the UUID of the resource owner who issued the authentication token included in the access token request. "ext:fname" is the value of "First Name" in the user attribute management table 403. "ext:lname" is the value of "Last Name" in the user attribute management table 403. "ext:locale" is the value of "Locale" in the user attribute management table 403. "ext:tenantid@recm" is the value of "Tenant ID" in the user attribute management table 403. "ext:email@req" is the value of "Email" in the user attribute management table 403. "ext:appid" is the value of "Application ID" in the token attribute management table 406. "ext:ismfa" is the same value as "ext:ismfa" included in the access token request. If the user has performed multi-factor authentication, "ext:ismfa" becomes "true". If the user did not perform multi-factor authentication, "ext:ismfa" will be "false."

[0064] The authentication and authorization server 101 then references the encryption key management table 407 to obtain the "Algorithm" and "Private Key" associated with the service ID identified in S803. The authentication and authorization server 101 digitally signs the JWT payload using this algorithm and private key in accordance with the compact serialization specification of RFC7515. The authentication and authorization server 101 then encodes the digitally signed JWT payload into a compact, URL-safe string. Finally, the authentication and authorization server 101 generates a JWS access token by concatenating the encoded JWS header, the encoded JWT payload, and the encoded JWS signature, in that order, with periods (.) as delimiters.

[0065] If verification of the authentication token fails in S802, or if it is determined in S803 that the client does not have the authorization to use the service, the authentication and authorization server 101 notifies the client 103 of an error in S805. Specifically, if it is determined in S803 that the client does not have the authorization to use the service, the authentication and authorization server 101 may send an error message indicating that the client does not have the authorization to use the service.

[0066] [Example of usage control processing by resource server 102] 6 will be described in detail with reference to Fig. 9. The resource server 102 waits for a resource request transmitted from one or more clients included in the access control system 100, and starts the operation of Fig. 9 in response to receiving the resource request. In the following description, it is assumed that the resource server 102 receives a resource request from the client 103. Each step of the method of Fig. 7 is executed by, for example, the token verification unit 313 of the resource server 102. Before executing the method of Fig. 9 (for example, when the resource server 102 is started), the resource server 102 has acquired public key information (for example, "Key ID" and "Public Key") managed in the encryption key management table 407 from the authentication and authorization server 101.

[0067] In S901, the resource server 102 receives a resource request from the client 103. As described above, a resource request is a request indicating that a user is requesting the use of resources of a specific tenant. The resource server 102 obtains necessary information from the resource request for subsequent processing. Specifically, the resource server 102 obtains a JWS access token from the HTTP Authorization header included in the REST API call made by the client 103 for the resource request. The resource server 102 splits the JWS access token into an encoded JWS header, an encoded JWT payload, and an encoded JWS signature, using periods (.) as delimiters. The resource server 102 then decrypts these pieces of data.

[0068] In S902, the resource server 102 verifies the JWS signature included in the resource request received in S901. If the verification is successful (YES in S902), the resource server 102 transitions the process to S903; otherwise (NO in S902), the resource server 102 transitions the process to S906. For example, the resource server 102 verifies the JWS signature based on public key information acquired in advance, using the algorithm indicated in the JWS header. In S906, the resource server 102 notifies the user of the client 103 of an error indicating that the JWS access token was generated fraudulently.

[0069] In S903, the resource server 102 determines whether the JWS access token received in S901 is valid. If the resource server 102 determines that the JWS access token is valid (YES in S903), it transitions the process to S904; otherwise (NO in S903), it transitions the process to S904. In S904, the resource server 102 executes a usage control process, which will be described later. In S905, the resource server 102 notifies the user of the client 103 of an error indicating that the JWS access token is invalid.

[0070] An example of a method for determining whether a JWS access token is valid will be described below. The resource server 102 determines whether "aud" included in the JWS access token contains its own URL. The resource server 102 references "exp" and "nbf" included in the JWS access token to determine whether the JWS access token is within its expiration date. If "aud" contains its own URL and the JWS access token is within its expiration date, the resource server 102 determines that the JWS access token is valid; otherwise, the resource server 102 determines that the JWS access token is invalid.

[0071] Details of S904 in Fig. 9 will be described with reference to Fig. 10. In S1001, the resource server 102 determines whether the user who has made the resource request belongs to a tenant that has permission to use the resource. In the description of Fig. 10, the user who has made the resource request will be simply referred to as the user. If the resource server 102 determines that the user belongs to a tenant that has permission to use the resource (YES in S1001), it transitions the process to S1002, and otherwise (NO in S1001), it transitions the process to S1005.

[0072] The multiple tenants used in the access control system 100 have a tree structure. A user belonging to a specific tenant can use resources owned by this specific tenant. A user belonging to another tenant that is higher than the specific tenant in the tree structure (i.e., closer to the root) can use resources owned by this specific tenant, unless otherwise restricted. On the other hand, a user belonging to another tenant that is not higher than the specific tenant cannot use resources owned by this specific tenant, unless otherwise permitted.

[0073] To make the determination in S1001, the resource server 102 identifies the tenant that owns the resource to be used (hereinafter referred to as the "owning tenant") and the tenant to which the user belongs (hereinafter referred to as the "belonging tenant"). First, the resource server 102 references the print information table 502 and acquires the tenant ID associated with the resource ("print job ID") specified in the resource request. This tenant ID represents the owning tenant. The resource server 102 also acquires the value of "ext:tenantid@recm" included in the JWS access token. This value represents the belonging tenant.

[0074] Thereafter, the resource server 102 refers to the tenant management table 501 to identify the relationship between the belonging tenant and the owning tenant in the tree structure. If the belonging tenant is the same as the owning tenant or is higher than the owning tenant, the resource server 102 determines that the user belongs to a tenant that has permission to use the resource. If there is no such relationship between the belonging tenant and the owning tenant, the resource server 102 determines that the user does not belong to a tenant that has permission to use the resource. In this case, in S1005, the resource server 102 may notify the user of the client 103 of an error indicating that the user does not have permission to use the resource.

[0075] As described above, the resource request includes information for identifying the resource to be used and information for identifying the tenant to which the user belongs. Therefore, the resource server 102 can identify the relationship between the belonging tenant and the owning tenant.

[0076] In S1002, the resource server 102 determines whether multi-factor authentication is set to be required to use the resources of the owning tenant. If it is determined that multi-factor authentication is set to be required (YES in S1002), the resource server 102 transitions the process to S1003, and otherwise (NO in S1002), the resource server 102 transitions the process to S1004. If multi-factor authentication is not set to be required, the resource server 102 permits the user to use the resources in S1004.

[0077] The resource server 102 refers to the tenant management table 501 and determines that multi-factor authentication is required if "MFA Policy" is set to "Required." The resource server 102 determines that multi-factor authentication is not required if "MFA Policy" is set to "None."

[0078] In S1003, the resource server 102 determines whether the resource request indicates that the user has performed multi-factor authentication. If it is determined that the resource request indicates that the user has performed multi-factor authentication (YES in S1003), the resource server 102 transitions the process to S1004, and otherwise (NO in S1003), the resource server 102 transitions the process to S1005. If the resource request indicates that the user has performed multi-factor authentication, the resource server 102 permits the user to use the resource in S1004. If the resource request does not indicate that the user has performed multi-factor authentication, the resource server 102 may notify the user of the client 103 of an error indicating that the user does not have permission to use the resource in S1005.

[0079] In this embodiment, the fact that a user has performed multi-factor authentication is indicated by "ext:ismfa" included in the Private Claim class of the JWS access token. The resource server 102 refers to the tenant management table 501 and determines that the user has performed multi-factor authentication if "ext:ismfa" is set to "true." The resource server 102 determines that the user has not performed multi-factor authentication if "ext:ismfa" is set to "false."

[0080] In the example included in tenant management table 501 in FIG. 5, it is set that multi-factor authentication is required for the use of resources in a tenant with a tenant ID of "101AA" (hereinafter referred to as "tenant A"), and multi-factor authentication is not required for the use of resources in a tenant with a tenant ID of "100AA" (hereinafter referred to as "tenant B"). Tenant B is the parent tenant of tenant A, i.e., the upper-level tenant. In accordance with the settings in tenant management table 501, users belonging to tenant B can use resources owned by tenant B without performing multi-factor authentication. On the other hand, users belonging to tenant B cannot use resources owned by tenant A unless they perform multi-factor authentication. In this way, whether multi-factor authentication is required for the use of resources owned by each tenant is set, and by controlling the use of resources in accordance with this setting, it is possible to ensure a security level for each tenant.

[0081] [Example of an error notified by S1005] In the above-described S1005, the resource server 102 may notify the user of the client 103 of the same error regardless of which tenant is the owning tenant. Alternatively, in S1005, the resource server 102 may perform processing that is individually set for the owning tenant. In this modification, the resource server 102 may use the tenant management table 1101 shown in FIG. 11 instead of the tenant management table 501.

[0082] The tenant management table 1101 differs from the tenant management table 501 in that it includes an "Access Error Response," but may be the same in other respects. The "Access Error Response" indicates the process performed by the resource server 102 when a user requesting use of a resource owned by a tenant identified by a tenant ID has not performed multi-factor authentication. If "display_mfa_error" is set in the "Access Error Response," the resource server 102 notifies the user of the client 103 that multi-factor authentication is required to use the tenant's resource. This notification may indicate that the MFA policy needs to be changed because there is a difference in the MFA policy between the tenant to which the user belongs and the tenant that owns the resource. If "redirect_mfa_settings" is set in the "Access Error Response," the resource server 102 may send the client 103 a response to redirect the user to a screen for changing the owning tenant's settings related to multi-factor authentication. If nothing is set in the "Access Error Response," the resource server 102 may notify the user of the client 103 of an error indicating that the user does not have permission to use the resource. The resource server 102 can set an "Access Error Response" individually for each of the multiple tenants managed by the resource server 102.

[0083] In the above example, "Access Error Response" represents the process performed by the resource server 102 when a user requesting to use a resource owned by a tenant indicated by a tenant ID has not performed multi-factor authentication. Alternatively, "Access Error Response" may represent the process performed by the resource server 102 when a user belonging to a tenant indicated by a tenant ID has not performed multi-factor authentication.

[0084] When a user who belongs to a resource that does not require multi-factor authentication to use the resource is unable to use the resources of a lower tenant, they may be confused as to why. In particular, if the MFA policy of a lower tenant is changed from "None" to "Required," this user will no longer be able to use the resources that they previously had access to. Even in such cases, the user experience can be improved by taking appropriate action according to the tenant.

[0085] <Summary of the embodiment> (Item 1) A resource server, an acquisition means for acquiring a resource request indicating that a user belonging to a second tenant above a first tenant is requesting use of a resource of the first tenant; a usage control means for permitting the user to use the resource when the resource request indicates that the user has performed the multi-factor authentication, when the resource request indicates that multi-factor authentication is required to use the resource of the first tenant; and A resource server comprising: (Item 2) The resource server described in item 1, wherein the usage control means performs processing individually set for the first tenant based on the resource request not indicating that the user has performed the multi-factor authentication when multi-factor authentication is required to use the resource of the first tenant. (Item 3) 3. The resource server of claim 2, wherein the individually configured processing includes notifying the user that the multi-factor authentication is required to use the resource of the first tenant. (Item 4) 4. The resource server according to item 2 or 3, wherein the individually set processing includes redirecting to a screen for changing the settings of the first tenant regarding the multi-factor authentication. (Item 5) 5. The resource server according to any one of items 1 to 4, wherein the usage control means is capable of individually setting a processing method for when the resource request does not indicate that the user has performed the multi-factor authentication, for each of a plurality of tenants managed by the resource server. (Item 6) The resource request includes an access token issued by an authentication and authorization server, 6. The resource server according to any one of items 1 to 5, wherein the access token includes an identifier of a tenant to which the user belongs. (Item 7) 7. The resource server of claim 6, wherein the access token includes information indicating that the user has performed multi-factor authentication. (Item 8) The access token is expressed as a JWT (JSON Web Token), 8. The resource server according to item 7, wherein the information indicating that the user has performed multi-factor authentication is included in a Private Claim class of a JWT. (Item 9) A program for causing a computer to function as the resource server according to any one of items 1 to 8. (Item 10) A method for controlling a resource server, comprising: an acquisition means acquires a resource request indicating that a user belonging to a second tenant above a first tenant is requesting use of a resource of the first tenant; When a usage control means is configured to require multi-factor authentication to use the resource of the first tenant, allowing the user to use the resource based on the resource request indicating that the user has performed the multi-factor authentication; A control method comprising: (Item 11) A system comprising an authentication and authorization server, a resource server, and a client, The authentication and authorization server transmits to the client an access token indicating that the user of the client has performed multi-factor authentication, based on the user's having performed multi-factor authentication; the client transmits to the resource server a resource request indicating that a user belonging to a second tenant above a first tenant is requesting use of a resource of the first tenant; The resource server permits the user to use the resource based on the resource request including the access token when multi-factor authentication is configured to be required to use the resource of the first tenant.

[0086] The invention is not limited to the above-described embodiments, and various changes and modifications can be made without departing from the spirit and scope of the invention. Accordingly, the following claims are appended to apprise the public of the scope of the invention. [Explanation of symbols]

[0087] 100 Access control system, 101 Authentication and authorization server, 102 Resource server, 103 Client

Claims

1. A resource server system, an acquisition means for acquiring a resource request indicating that a user belonging to a second tenant above a first tenant is requesting use of a resource of the first tenant; a usage control means for permitting the user to use the resource when the resource request indicates that the user has performed the multi-factor authentication, when multi-factor authentication is required to use the resource of the first tenant; and A resource server system comprising:

2. 2. The resource server system according to claim 1, wherein the usage control means performs processing individually set for the first tenant based on the fact that the resource request does not indicate that the user has performed multi-factor authentication when multi-factor authentication is required to use the resources of the first tenant.

3. The resource server system according to claim 2 , wherein the individually set processing includes notifying the user that the multi-factor authentication is required to use the resource of the first tenant.

4. The resource server system according to claim 2 , wherein the individually set process includes redirecting to a screen for changing the first tenant's settings regarding the multi-factor authentication.

5. 2. The resource server system according to claim 1, wherein the usage control means is capable of individually setting a processing to be performed when the resource request does not indicate that the user has performed the multi-factor authentication, for each of a plurality of tenants managed by the resource server system.

6. the resource request includes an access token issued by an authentication and authorization server; The resource server system according to claim 1 , wherein the access token includes an identifier of a tenant to which the user belongs.

7. The resource server system according to claim 6 , wherein the access token includes information indicating that the user has performed multi-factor authentication.

8. The access token is expressed as a JWT (JSON Web Token), The resource server system according to claim 7 , wherein the information indicating that the user has performed multi-factor authentication is included in a Private Claim class of a JWT.

9. A program for causing a computer to function as the resource server system according to any one of claims 1 to 8.

10. A control method for a resource server system, comprising: an acquisition means acquiring a resource request indicating that a user belonging to a second tenant that is higher than a first tenant is requesting use of a resource of the first tenant; When a usage control means is configured to require multi-factor authentication to use the resource of the first tenant, allowing the user to use the resource based on the resource request indicating that the user has performed the multi-factor authentication; A control method comprising:

11. A system including an authentication and authorization server system, a resource server system, and a client, the authentication and authorization server system transmits to the client an access token indicating that the user of the client has performed multi-factor authentication, based on the user's having performed multi-factor authentication; the client transmits to the resource server system a resource request indicating that a user belonging to a second tenant above a first tenant is requesting use of a resource of the first tenant; The resource server system permits the user to use the resource based on the resource request including the access token when multi-factor authentication is set to be required to use the resource of the first tenant.

Images