JP7271147B2 - SERVICE AUTHORIZATION PROCESSING APPARATUS, SYSTEM, METHOD AND PROGRAM - Google Patents

Description

TECHNICAL FIELD Embodiments of the present invention relate to a service authorization processing device, system, method and program.

In recent years, for example, in the development of systems and software for providing Web services, attention has been paid to methods of configuring all functions of services using microservices instead of so-called monolith configurations. A microservices architecture is a mechanism that realizes all predetermined functions by combining and linking multiple services. If you use a method that uses microservices, you can use external services, so you can reduce development costs. In addition, since each service to be combined is independent, it becomes easy to change or add each service (function).

By the way, when using microservices, when a linking service calls and uses a linking service, authorization using a protocol called OAuth2, for example, may be required. In this case, an authorization process is required to acquire authorization information required for authorization, such as an access token.

JP 2015-228067 A WO2013145517 JP 2009-99131 A JP 2013-145506 A

In the method that uses microservices, when a linking service that does not require authorization calls and uses a linking service that requires authorization, the linking service must implement a function to perform authorization processing. will be required. This makes it impossible to ensure the independence of each service included in the benefits of microservices.

Accordingly, it is an object of the present invention to provide a service authorization processing device which can be applied to a method of realizing a predetermined function by coordinating a plurality of services, including services requiring authorization, and which can ensure the independence of each service. be.

The service authorization processing device of this embodiment is a service authorization processing device that is applied to a system that implements a predetermined function by coordinating a plurality of services, and comprises authorization determination means, authorization information management means, and authorization processing information . It has a creating means and a second storage device. The authorization determination means determines whether or not authorization is required when executing each linked service. The authorization information management means acquires and manages the authorization information in order to provide the authorization information used for authorization to a service that requires authorization. The authorization processing information creating means generates, for each of the cooperating services, first information indicating a calling relationship and authorization information for each of the cooperating services based on information obtained from a server included in the system when each of the cooperating services is activated. and second information specifying whether or not there is a need. The second storage device stores the authorization processing information created by the authorization processing information creating means . The authorization determining means further determines that the service specified as not requiring authorization in the second information in the authorization processing information does not require authorization.

1 is a block diagram for explaining the configuration of a system according to an embodiment; FIG. The figure which shows an example of the service related table regarding embodiment. The figure which shows an example of the authorization information table regarding embodiment. The figure which shows an example of the user information table regarding embodiment. The figure which shows an example of the calling relationship of each service regarding embodiment. FIG. 4 is a diagram for explaining an overview of authorization processing related to the embodiment; 4 is a flowchart for explaining authorization processing according to the embodiment; 4 is a flowchart for explaining processing of an authorization determination unit according to the embodiment; 4 is a flowchart for explaining processing of an access token management unit according to the embodiment; 4 is a flowchart for explaining processing of a service-related creation unit according to the embodiment;

Embodiments will be described below with reference to the drawings.
[System configuration]
FIG. 1 is a diagram showing the configuration of a system 1 related to this embodiment. As shown in FIG. 1, the system 1 of this embodiment has an authorization processing device 10, an authorization server 13, a resource server 14, and a service providing server 15 that implements various services (functions) A to E. The service providing server 15 is a group of servers that implement each of the services A to E independently, and implements microservices that link the services A to E, as will be described later. A microservice is a method of realizing a predetermined service (function) by linking a plurality of services.

The authorization processing device 10 includes an API gateway (Application Programming Interface Gateway) 11 and a service registry 12, which are mainly implemented by computers and storage devices. The API gateway 11 of this embodiment implements a relay function for exchanging various information between the client 2 and the services (A to E), and also has an authorization determination function, which will be described later. The API gateway 11 includes a communication unit 101 and an authorization determination unit 102 that control communication. The authorization judgment unit 102 executes authorization judgment processing for judging whether or not authorization is required for using the service, based on data acquired by the authorization information acquisition unit 103, which will be described later.

The service registry 12 corresponds to an information management server, and includes an authorization information acquisition unit 103 , an access token management unit 104 , an authorization information storage unit 105 and a service relation creation unit 106 . The authorization information acquisition unit 103 acquires a service related table 20, an authorization information table 21, and a user information table 22, which will be described later, from the authorization information storage unit 105. FIG. Each of these tables 20 , 21 , 22 is authorization processing information used in the authorization processing device 10 .

The access token management unit 104 executes processing for registering an access token issued by the authorization server 13 in the authorization information storage unit 105 and processing for acquiring the access token from the authorization information storage unit 105 . The authorization information storage unit 105 stores a service related table 20, an authorization information table 21, and a user information table 22, as well as access tokens to be registered. The service relation creation unit 106 creates a service relation table 20 and an authorization information table 21 and stores them in the authorization information storage unit 105, as will be described later.

The authorization server 13 is connected to the communication unit 101 of the API gateway 11, and based on a request from the client 2 operated by the user, determines whether or not to access the resource server 14, and issues an access token. Execute. In this embodiment, the resource server 14 provides an external service (F) that cooperates with the service E, for example. Here, in order for service E to access the service (F), authorization using, for example, the OAuth2 protocol is required. In this embodiment, authorization using the OAuth2 protocol is simply referred to as authorization.

FIG. 2 is a diagram showing an example of the service related table 20. As shown in FIG. The service relation table 20 is information representing the calling relation of each linked service in order to realize the microservice. FIG. 5 is a diagram showing an example of the calling relationship of each service. As shown in FIG. 5, when service A (path: /service a-1) is called by a request from client 2, service A is service B (path: /service b-1) and service D (path: /service d-1). Further, service B has a relationship of calling service C (path: /service c-1) and service E (path: /service e-1).

As shown in FIG. 2, the service relation table 20 is information that can uniquely identify the calling relationship of each service as shown in FIG. 5 by the service name and path. That is, the service relation table 20 defines which service calls which service by row-by-row data. For example, the data in the first row defines that service A (path: /service a-1) calls service B (path: /service b-1). Here, the path indicates a route for accessing the service of the service name, and is information corresponding to the path name of URL (Uniform Resource Locator), for example.

FIG. 3 is a diagram showing an example of the authorization information table 21. As shown in FIG. As shown in FIG. 3, the authorization information table 21 is information indicating whether or not authorization is required to access (call) each service A to E. FIG. The authorization information table 21 indicates that, for example, service A to service D do not require authorization, and service E requires authorization.

FIG. 4 is a diagram showing an example of the user information table 22. As shown in FIG. As shown in FIG. 4, the user information table 22 is information that sets an access token required for authorization when accessing a service for each user. That is, the access token is authorization information used for authorization. The user information table 22 includes, for example, an access token "accVkjcJyb4BWCx" for a user whose user ID is set to "User C" to access service E from the client 2, and an expiration date of "2020/11/30." 00:00:00”.
[System operation]
FIG. 6 is a diagram for explaining an outline of authorization processing by the authorization processing device 10 and the authorization server 13 of this embodiment. Here, an example will be described in which a user whose user ID is set to "User A" accesses service A (path: /service a-1) from the client 2. FIG.

When the API gateway 11 accesses the service A from the client 2 (60), the authorization determination unit 102 determines whether or not the accessed service requires authorization. The authorization determination unit 102 accesses the service registry 12 (61), refers to the service-related table 20 and the authorization information table 21 stored in the authorization information storage unit 105, and judges the presence or absence of authorization. The client 2 is composed of, for example, a personal computer display 200 and a PC body 201 .

Here, for example, when the service (E) to be accessed in cooperation with the service A requires authorization, the API gateway 11 redirects the PC body 201 of the client 2 for authorization ( 62). The client 2 receives login screen information from the authorization server 13 by redirecting to the authorization server 13 (63) (64). The client 2 inputs the user ID and password on the login screen displayed on the display 200 and transmits them to the authorization server 13 (65). If the user ID and password are correct, the authorization server 13 returns an authorization code to the client 2 and API gateway 11 (66).

The API gateway 11 uses the authorization code obtained from the authorization server 13 to obtain an access token, which is authorization information issued by the authorization server 13 (67). In this embodiment, the API gateway 11 stores the access token acquired from the authorization server 13 in the authorization information storage unit 105 of the service registry 12 (61).

After executing such authorization processing, the API gateway 11 accesses service A (68). Due to the calling relationship shown in FIG. 5, each service A to E cooperates to implement all the functions of a given service. That is, service A calls service B and service D, which are cooperation destinations. Further, service B calls service C and service E, which are cooperation destinations.

Here, in order to access the resource server 14, the service E acquires the access token stored in the authorization information storage unit 105 of the service registry 12 (69). Service E sends the access token to resource server 14 (70). That is, service E can use the access token to call service F to obtain the required resource (71).

7 to 10 are flow charts for explaining in more detail the authorization processing by the authorization processing device 10 and the authorization server 13 of this embodiment.

As shown in FIG. 7, when the communication unit 101 receives a request for accessing service A from the client 2 (S1), the API gateway 11 determines whether authorization is required by the authorization determination unit 102. is determined (S2).

FIG. 8 is a flowchart for explaining the determination processing of the authorization determination unit 102. As shown in FIG. The authorization determination unit 102 accesses the authorization information acquisition unit 103 of the service registry 12 . As shown in FIG. 8, the authorization information acquisition unit 103 acquires the service related table 20 and the authorization information table 21 from the authorization information storage unit 105 (S20). The authorization determination unit 102 refers to the service-related table 20 and acquires the data of the item whose path matches the service name (S21). Here, since service A (path: /service a-1) is being accessed, each data in the first and second rows of the service related table 20 is acquired.

Next, the authorization determination unit 102 refers to the authorization information table 21 and acquires the data of the item whose path matches the service name (S22). The authorization judgment unit 102 judges the presence or absence of authorization based on the data in the authorization information table 21 (S23). Specifically, since the data in the first row of the authorization information table 21 has no authorization value, the authorization determination unit 102 determines that service A does not perform authorization (does not require authorization). .

Next, the authorization determination unit 102 refers to the service relation table 20 and acquires the used service name (B, D) including the used service path corresponding to the service name (A) including the path (S24). If there is no used service path and no used service name, it indicates that there is no service called from the corresponding service.

Specifically, from the data in the first row of the service relation table 20, the service used by service A is the service used name B (used service path: /service b-1). The data on the 3rd and 4th rows of the relation table 20 (both are service name B) are acquired. Similarly, the data (service name D) in the sixth line of the service relation table 20 is obtained from the data in the second line (service name D) of the service relation table 20 .

The authorization determination unit 102 repeats the processing from S21 until data cannot be acquired from the service-related table 20 (YES in S25). The authorization determination unit 102 terminates the process if the data could not be obtained (NO in S25). Through such processing of the authorization determination unit 102, in order to access service A (path: /service a-1), authorization is required for partner service E (path: /service e-1). can be determined.

Returning to FIG. 7, when the authorization determination unit 102 determines that authorization is not required to access service A (NO in S3), API gateway 11 executes service A via communication unit 101. and terminate the process (S17). That is, the client 2 is provided with all the functions of a predetermined service realized through the cooperation of the services A to E via the API gateway 11 .

On the other hand, when the authorization determination unit 102 determines that authorization is required, it accesses the access token management unit 104 (YES in S3). The access token management unit 104 checks whether an access token is registered (stored) in the authorization information storage unit 105 (S4).

FIG. 9 is a flowchart for explaining the processing of the access token management unit 104. As shown in FIG. As shown in FIG. 9, the access token management unit 104 acquires the user information table from the authorization information storage unit 105 (S30). The access token management unit 104 acquires data matching the user ID, pass, and service name (E) from the user information table (see FIG. 4) (S31). Specifically, for example, the data of "User C" as the user ID, "/service e-1" as the path, and service name E are obtained from the user information table 22 . That is, in order to access service A (path: /service a-1), authorization is required for affiliated service E (path: /service e-1). Based on

The access token management unit 104 checks whether or not the access token has been registered from the user information table 22 (S32). Here, the access token management unit 104 determines that the access token is not registered in this case because the data in the first row of the user information table 22 does not have an access token value (NO in S32). A reply to that effect is sent to the authorization determination unit 102 (S34).

The access token management unit 104 determines that the access token has been registered because the data in the third row of the user information table 22 has the value of the access token (YES in S32), and notifies the authorization determination unit 104 to that effect. (S33). However, the access token management unit 104 determines that the access token has not been registered if the expiration date is before the current value, and that the access token has been registered if the expiration date is after the current value. I judge.

Returning to FIG. 7, when the authorization determination unit 102 receives a reply from the access token management unit 104 that the access token has been registered (YES in S5), the API gateway 11 accesses the service A via the communication unit 101. (S14). That is, the services A to E cooperate with each other according to the calling relationship as shown in FIG. 5 to realize all the functions of the predetermined service.

In this case, service E acquires an access token registered (stored) in authorization information storage unit 105 from access token management unit 104 in response to a call from service B (S15). The service E acquires a predetermined access token from the access token management unit 104 using information including the user ID, path, and service name of the user information table 22 transmitted from the API gateway 11 . The service E uses the access token to access the resource server 14, calls the service F, and acquires the necessary resource (S16). As a result, the client 2 is provided with all the functions of a predetermined service realized through the cooperation of the services A to E via the API gateway 11 .

On the other hand, when the authorization determination unit 102 receives a reply from the access token management unit 104 that the access token has not been registered (NO in S5), the API gateway 11 redirects to the authorization server 13 via the communication unit 101 ( S6). As described above with reference to FIG. 6, the access token management unit 104 executes processing for registering (storing) the access token issued by the authorization server 13 in the authorization information storage unit 105 .

That is, the authorization server 13 displays a login screen on the client 2 (S7). The client 2 transmits the user ID and password that the user has entered on the login screen to the authorization server 13 (S8). If the transmitted user ID and password are not correct, the authorization server 13 displays the login screen again on the client 2 (NO in S9).

On the other hand, when the transmitted user ID and password are correct (YES in S9), the authorization server 13 returns an authorization code to the communication unit 101 (S10). The API gateway 11 uses the authorization code to acquire an access token from the authorization server 13 via the communication unit 101 (S11). The communication unit 101 passes the acquired access token to the access token management unit 104 (S12). The access token management unit 104 registers the access token in the authorization information storage unit 105 (S13). Specifically, the access token management unit 104 stores the user ID, the pass, the service name (E), the access token, and the expiration date of the access token in the user information table 22 stored in the authorization information storage unit 105. Register (see Figure 4).

Here, the service relation creation unit 106 creates the service relation table 20 and the authorization information table 21 and stores them in the authorization information storage unit 105 when the service is activated in response to the notification from the API gateway 11 . FIG. 10 is a flow chart showing the processing of the service relation creation unit 106. As shown in FIG.

As shown in FIG. 10 , the service-related creation unit 106 is called by the service providing server 15 via the API gateway 11 when the service is activated. The service relation creation unit 106 creates the service relation table 20 based on the information provided from the service providing server 15 via the API gateway 11, and stores (registers) it in the authorization information storage unit 105 (S40). In this case, the service relation creation unit 106 acquires the call relation of each service based on the service source code, setting file, etc., and creates the service relation table 20 .

Next, the service relation creation unit 106 creates the authorization information table 21 based on the information provided from the service providing server 15 via the API gateway 11 and stores (registers) it in the authorization information storage unit 105 ( S41). In this case, the service-related creating unit 106 acquires information as to whether or not the corresponding service requires authorization based on the service source code, setting file, etc., and creates the authorization information table 21 .

As described above, according to this embodiment, it is possible to provide microservices in which a plurality of services cooperate to realize all the functions of a predetermined service in response to a request from a client. In such a relationship of calling each service in a microservice, if the called service requires authorization, the service can use the access token required for authorization. As a result, the caller service that does not require authorization among the multiple linked services does not need to implement the authorization processing function required for authorization of the callee. Therefore, the independence of each service can be ensured when each service cooperates and realizes a microservice.

In this embodiment, authorization using a protocol called OAuth2 has been described, but the present invention is not limited to this, and can be applied to authorization using another method. Also, the calling relationship of each service in this embodiment is an example, and can be applied to other calling relationships.

While several embodiments of the invention have been described, these embodiments have been presented by way of example and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, replacements, and modifications can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are included in the scope of the invention described in the claims and equivalents thereof.

1... system, 2... client, 10... authorization processing device, 11... API gateway,
12... service registry, 13... authorization server, 14... resource server,
15... Service providing server, 101... Communication unit, 102... Authorization determination unit,
103... authorization information acquisition unit, 104... access token management unit,
105... Authorization information storage unit, 106... Service related creation unit.

Claims (7)

A service authorization processing device applied to a system that realizes a predetermined function by linking a plurality of services,
authorization determination means for determining whether or not authorization is required when executing each linked service;
authorization information management means for acquiring and managing the authorization information in order to provide authorization information used for authorization to a service that requires authorization;
When each of the services to be linked is activated, based on information acquired from a server included in the system, first information indicating a calling relationship and whether or not authorization is required for each of the services to be linked authorization processing information creating means for creating authorization processing information including second information specifying whether
a second storage device for storing the authorization processing information created by the authorization processing information creating means ;
The authorization determination means determines that a service specified as not requiring authorization in the second information in the authorization processing information does not require authorization.
Service Authorization Processor. The authorization information management means
Acquiring authorization information corresponding to a service judged to require authorization by the authorization judgment means from a server included in the system;
storing the authorization information in a first storage device;
2. The service authorization processing device according to claim 1, which retrieves said authorization information from said first storage device and provides said authorization information to said service based on a request from said service using said authorization information. a service authorization processing device according to claim 1 or 2 ;
a first server that communicates with the service authorization processing device and executes a plurality of services in cooperation;
and a second server in communication with the service authorization processing device to generate and provide the authorization information to the service authorization processing device. The service authorization processing device,
4. The system according to claim 3 , comprising relay means for communicating with said first server and said second server and exchanging various information. A service authorization processing method applied to a system realizing a predetermined function by linking a plurality of services,
a process of determining whether or not authorization is required when executing each linked service;
a process of acquiring and managing the authorization information in order to provide the authorization information used for authorization to a service that requires authorization;
When each of the services to be linked is activated, based on information acquired from a server included in the system, first information indicating a calling relationship and whether or not authorization is required for each of the services to be linked a process of creating authorization process information including second information specifying whether the
and determining, in the authorization processing information, that the service identified as not requiring authorization in the second information does not require authorization. a process of acquiring the authorization information corresponding to a service determined to require authorization from a server included in the system;
a process of storing the authorization information in a first storage device;
6. The method according to claim 5 , further comprising retrieving said authorization information from said first storage device and providing said authorization information to said service based on a request from said service using said authorization information. A program that causes a computer to execute each process according to the method according to claim 5 or 6 .

Images