CN111600899A - Micro-service access control method and device, electronic equipment and storage medium - Google Patents

Abstract

Embodiments of the present application provide a microservice access control method, apparatus, electronic device, and storage medium. The specific implementation scheme is: receiving an access request to the target interface of the microservice, and the access request includes the user ID; querying the authorization role corresponding to the user ID, and the authorization role includes at least one interface with access rights; controlling the target interface according to the query result Access. The embodiment of the present application grants a user access rights to at least one microservice interface through an authorization role, so that unified management of access rights to multiple microservice interfaces can be implemented, and security access control to the microservice interfaces can be ensured while ensuring service performance.

Description

Microservice access control method, device, electronic device and storage medium

technical field

The present application is in the field of computer network technologies, and in particular, relates to a microservice access control method, apparatus, electronic device, and storage medium.

Background technique

In a microservice architecture, different microservices can have different network addresses. Each microservice completes user requests by calling each other. A client may complete a user request by calling the interfaces of multiple microservices. An API (Application Programming Interface) gateway can be added between the client and the server. All external requests interact through this API gateway, and the gateway calls each microservice. Therefore, this API gateway is also called a microservice gateway. In practical applications, since the microservice architecture usually includes multiple microservices, and each microservice provides several interfaces, the microservice gateway needs to perform access control on a large number of microservice interfaces. Therefore, when a large number of users access concurrently, the performance bottleneck of the gateway authentication service will be caused. How to ensure secure access control to microservice interfaces while ensuring service performance is an urgent problem to be solved.

SUMMARY OF THE INVENTION

The embodiments of the present application provide a microservice access control method, device, electronic device, and storage medium to solve the problems existing in the related technologies, and the technical solutions are as follows:

In a first aspect, an embodiment of the present application provides a microservice access control method, which includes:

Receive an access request to the target interface of the microservice, and the access request includes the user ID;

Query the authorization role corresponding to the user ID, and the authorization role includes at least one interface with access rights;

Controls access to the target interface based on the results of the query.

In a second aspect, an embodiment of the present application provides a microservice access control device, including:

a receiving unit, configured to receive an access request to the target interface of the microservice, where the access request includes a user identifier;

a query unit, used for querying the authorization role corresponding to the user ID, where the authorization role includes at least one interface with access rights;

The control unit is used to control the access to the target interface according to the query result.

In a third aspect, an embodiment of the present application provides an electronic device, including:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor, so that the at least one processor can execute the method provided by any one of the embodiments of the present application.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium, where the computer-readable storage medium stores computer instructions, and when the computer instructions are executed on a computer, the method in any one of the implementation manners of the above aspects is executed.

The advantages or beneficial effects of the above technical solutions include at least: granting access rights to at least one micro-service interface to a user through an authorization role, which can realize unified management of access rights to multiple micro-service interfaces, and can ensure service performance while ensuring that the Microservice interface for secure access control.

The above summary is for illustrative purposes only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments and features described above, further aspects, embodiments and features of the present application will become apparent by reference to the drawings and the following detailed description.

Description of drawings

In the drawings, unless stated otherwise, the same reference numbers refer to the same or like parts or elements throughout the several figures. The drawings are not necessarily to scale. It should be understood that these drawings depict only some embodiments disclosed in accordance with the present application and should not be considered as limiting the scope of the present application.

FIG. 1 is a flowchart of a microservice access control method according to an embodiment of the present application;

2 is a schematic diagram of a microservice architecture of a method for microservice access control according to another embodiment of the present application;

FIG. 3 is a schematic diagram of rights management of a microservice access control method according to another embodiment of the present application;

4 is a schematic diagram of data setting of a microservice access control method according to another embodiment of the present application;

5 is a schematic diagram of data setting of a microservice access control method according to another embodiment of the present application;

6 is a schematic diagram of data setting of a microservice access control method according to another embodiment of the present application;

7 is a schematic diagram of data setting of a microservice access control method according to another embodiment of the present application;

8 is a schematic diagram of data setting of a microservice access control method according to another embodiment of the present application;

FIG. 9 is a flowchart of a microservice access control method according to another embodiment of the present application;

10 is a schematic diagram of a microservice gateway architecture and an access control flow diagram of a microservice access control method according to another embodiment of the present application;

11 is a schematic diagram of a microservice access control apparatus according to an embodiment of the present application;

12 is a schematic diagram of a microservice access control apparatus according to another embodiment of the present application;

13 is a schematic diagram of a query unit of a microservice access control apparatus according to another embodiment of the present application;

FIG. 14 is a block diagram of an electronic device used to implement the microservice access control method according to the embodiment of the present application.

Detailed ways

In the following, only certain exemplary embodiments are briefly described. As those skilled in the art would realize, the described embodiments may be modified in various different ways, all without departing from the spirit or scope of the present application. Accordingly, the drawings and description are to be regarded as illustrative in nature and not restrictive.

FIG. 1 is a flowchart of a microservice access control method according to an embodiment of the present application. As shown in Figure 1, the microservice access control method may include:

Step S110, receiving an access request to the target interface of the microservice, where the access request includes a user identifier;

Step S120, query the authorization role corresponding to the user ID, and the authorization role includes at least one interface with access rights;

Step S130, controlling access to the target interface according to the query result.

In the microservice architecture, the client may complete a user request by calling the interfaces of multiple microservices. For example, when a user views information about a product, the product information may include product basic information, price information, comment information, discount information, inventory information, and so on. These information acquisitions come from different microservices, such as product systems, price systems, comment systems, promotion systems, inventory systems, and so on. Therefore, to complete the information viewing, multiple microservices need to be called. In this case, an API gateway can be added between the client and the server, all external requests interact through this microservice gateway, and the gateway calls each microservice.

FIG. 2 is a schematic diagram of a microservice architecture of a microservice access control method according to another embodiment of the present application. Referring to the example in Figure 2, "third party" refers to a third-party application that uses the microservice, that is, the user accessing the microservice. In the microservice architecture shown in Figure 2, third parties, charging piles, APPs (Applications) and developers' ecological access terminals all need to access through a unified open platform gateway (microservice gateway) to provide in-vehicle services business center. Among them, the middle platform corresponds to the foreground and the background, which refers to the collection of middleware shared in the system. The business center can include multiple microservices, and each microservice can be a business service that combines the public requirements of the business. For example, public needs can include car manufacturers, users, vehicles, orders, deliveries, etc. These public services are combined into a unified business service, which can be provided to third-party applications. The microservices in the platform of the service providing in-vehicle services in FIG. 2 may include user microservices for providing user information, weather microservices for providing weather information, and the like.

During system operation, the microservice gateway needs to perform access control on a large number of microservice interfaces. Take the cloud platform that adopts the SpringCloud microservice architecture as an example, the cloud platform can provide users with dozens of microservices, each microservice can provide several interfaces, and the total number of interfaces can exceed 800. In the prior art, a third-party application would access a corresponding interface through a microservice gateway to realize account activation, token exchange, and function use. For example, the process of account activation may include steps such as account binding request, binding verification, verification code sending, and feedback of binding verification results. The process of token exchange may include the steps of requesting token exchange, generating a new token, and returning the new token. The process of function use may include steps such as function invocation, token verification, task distribution, instruction issuance, and result feedback. In the above access process, if a large number of users access concurrently, the performance bottleneck of the gateway authentication service will be caused due to the large number of interfaces.

In view of this, the present application provides a microservice access control method, which grants different access rights to different third-party applications, so as to achieve unified management of access rights and access security for multiple microservice interfaces.

As mentioned above, each microservice can provide several interfaces in the microservice architecture. Each interface can be a URL (Uniform Resource Locator, Uniform Resource Locator). The URL is a representation method used to specify the location of information on the World Wide Web service program, and is also called a web address. In step S110, the micro-service gateway receives the user's access request to the target interface. The access request may include information such as the URL address and user ID of the target interface to be accessed. In one example, the user identification may be the Access Key Id (AK, access key). The microservice gateway can verify the user identity of a request by encrypting with the AccessKey Id/Secret Access Key (SK, secret access key). Among them, the Access Key Id (AK) is used to identify the user, and the Secret Access Key (SK) is the key used by the user to encrypt the authentication string and the microservice to verify the authentication string.

FIG. 3 is a schematic diagram of rights management of a microservice access control method according to another embodiment of the present application. As shown in FIG. 3 , in this embodiment of the present application, gateway authority management is implemented through authorization roles. Different from the method of directly granting the URL authority to the user AK in the authority management of the traditional gateway, in the embodiment of the present application, the gateway assigns the authorization role to the user AK, and the authorization role is a collection of microservice URLs. Referring to the example in FIG. 3 , the authorization roles assigned by the gateway to a certain user AK include authorization role 1 , authorization role 2 and authorization role 3 . Wherein, authorization role 1 includes authorization URL1 and authorization URL2, authorization role 2 includes authorization URL3, authorization URL4, and authorization URL5, and authorization role 3 also includes at least one authorization URL (not shown in FIG. 3 ). After the gateway assigns the authorization role to the user AK, the user AK is granted the right to access the URL included in the authorization role. In the example of FIG. 3 , the gateway assigns authorization role 1, authorization role 2 and authorization role 3 to the user AK, and the permissions possessed by the user AK include accessing URL1 and URL2 included in authorization role 1, and authorization role 2 including URL1 and URL2 included in authorization role 2. URL3, URL4, and URL5, and at least one URL included in authorization role 3.

In this embodiment of the present application, a corresponding relationship between the user ID and at least one authorization role may be preset, and the corresponding relationship may be pre-stored in the database in the form of a relationship table. In addition, the corresponding relationship between the authorization role shown in FIG. 3 and the at least one authorization URL may also be pre-stored in the database in the form of a relationship table. In step S120, the authorization role corresponding to the user identifier may be queried according to the corresponding relationship between the user identifier and at least one authorization role. Then, according to the corresponding relationship between the authorization role and at least one authorization URL, the authorization URL corresponding to the authorization role is queried. In step S130, if the authorization role corresponding to the user identifier includes the target interface that the user requests to access, the user is allowed to access the target interface.

The embodiment of the present application grants a user access rights to at least one microservice interface through an authorization role, which can realize unified management of access rights to multiple microservice interfaces, and can ensure safe access control to the microservice interfaces while ensuring service performance.

In one embodiment, the above method further includes:

Pre-set at least one microservice for access control;

The correspondence between each microservice and at least one interface is preset.

In one example, the corresponding relationship between each microservice that needs to perform access control and at least one interface may be preset, and the corresponding relationship may be pre-stored in the database in the form of a relational table. In one example, the microservice name may be maintained before the interface URL contained in the microservice. That is to say, the name of the microservice for access control can be stored in the database first, and then the interface URL contained in each microservice can be stored in the database.

FIG. 4 is a schematic diagram of data setting of a microservice access control method according to another embodiment of the present application. In the example of Figure 4, the microservice interface URL is: admin/url/insertOrUpdate. The name of the owning microservice set for this URL is goods-service.

In the embodiment of the present application, by maintaining the corresponding relationship between the microservice and the interface URL, data support can be provided for the unified management of the access authority of the microservice interface.

In one embodiment, the above method further includes:

Pre-set at least one authorization role;

The corresponding relationship between the authorization role and the at least one interface with access rights is preset.

In order to achieve unified management of access rights to multiple microservice interfaces, in addition to the above-mentioned correspondence between microservices and interface URLs, the data to be maintained in the database also needs to maintain the correspondence between authorization roles and at least one authorization URL. Referring to the example of FIG. 3 , the corresponding relationship between the authorization role and at least one authorization URL may be preset and stored in the database in the form of a relationship table.

In an example, the authorization role can be maintained first, and then the authorization relationship between the authorization role and the URL can be bound through the maintained correspondence between the microservice and the interface URL in the example in FIG. 4 . That is to say, the set at least one authorization role may be stored in the database first, and then the interface URL included in each authorization role may be stored in the database.

FIG. 5 and FIG. 6 are schematic diagrams of data setting of a microservice access control method according to another embodiment of the present application. In the example of FIG. 5, the first column of data in the relational two-dimensional table of the database is the name of the authorization role, the second column of data is the creation time, the third column of data is the description of the authorization role, and the fourth column of data is the authorization role The operation implemented. For example, the name of the authorization role recorded in the third row in Fig. 5 is "message platform", and the box in the figure is marked as the "authorization" operation button corresponding to this role. Click the "authorize" operation button, and the program jumps to the interface shown in Figure 6. In the interface shown in FIG. 6 , the corresponding interface URL access authority can be set for the authorization role named "message platform". Referring to Figure 6 again, the interface URL provided by the microservice named goods-service includes: admin/url/insertOrUpdate. In FIG. 6, the corresponding relationship between the authorization role named "message platform" and the interface URL admin/url/insertOrUpdate can be set. If the authorization role corresponding to a user is "message platform", the user has access to the interface URL admin/url/insertOrUpdate.

In the embodiment of the present application, by maintaining the corresponding relationship between authorization roles and interface URLs, users can be granted access rights to at least one micro-service interface, and unified management of access rights to multiple micro-service interfaces can be achieved, while ensuring service performance. Ensure secure access controls for microservice interfaces.

In one embodiment, the above method further includes:

Pre-set at least one user ID;

A corresponding relationship between the user ID and at least one authorization role is preset.

In order to achieve unified management of access rights to multiple microservice interfaces, in addition to the above-mentioned correspondence between microservices and interface URLs, and the correspondence between authorization roles and at least one authorization URL, the data that needs to be maintained in the database also needs to maintain user IDs and URLs. Correspondence of at least one authorization role. Wherein, the user ID can be AK. In an example, AK and SK may be allocated to the third-party application first, and then at least one authorization role corresponding to the AK may be maintained, so as to grant corresponding permissions to different AKs respectively. That is to say, the set at least one user ID may be stored in the database first, and then the at least one authorization role corresponding to each user ID may be stored in the database.

7 and 8 are schematic diagrams of data setting of a method for microservice access control according to another embodiment of the present application. In the example of FIG. 7 , the data in the first column of the relational two-dimensional table of the database is the user AK, the data in the second column is SK, the data in the third column is the creation time, and the data in the fourth column is the user description information corresponding to the user AK , the fifth column of data is for the operations that can be implemented by the user AK. Among them, users can be third-party applications that use microservices. For example, the user description information corresponding to the user AK recorded in the first row in FIG. 7 is "charging service", and the box in the figure is marked as the "modify" operation button corresponding to the user AK. Click the "authorize" operation button, and the program jumps to the interface shown in Figure 8. In the interface shown in FIG. 8 , a corresponding authorization role can be set for the user AK whose user description information is "charging service". Referring to FIG. 8 again, a correspondence relationship between a user AK whose user description information is "charging service" and an authorized role whose name is also "charging service" can be set. Through the above settings, the user AK has access rights to all interfaces included in the authorized role named "charging service".

In the embodiment of this application, the above three correspondences of microservice-interface, authorization role-interface, and user ID-authorization role are maintained in the database, and through the progressive maintenance mode, users can be granted at least one microservice interface It can realize the unified management of the access rights of multiple microservice interfaces, and ensure the security access control of the microservice interfaces while ensuring the service performance.

FIG. 9 is a flowchart of a method for microservice access control according to another embodiment of the present application. As shown in FIG. 9 , in one embodiment, in step S120 in FIG. 1 , query the authorization role corresponding to the user ID, which may specifically include: step S210 , query the user ID according to the corresponding relationship between the user ID and at least one authorization role The corresponding authorization role;

The above method also includes:

Step S220, according to the corresponding relationship between the authorization role and the at least one interface with the access authority, query the interface with the access authority included in the authorization role corresponding to the user ID.

FIG. 10 is a schematic diagram of a microservice gateway architecture and an access control flow diagram of a microservice access control method according to another embodiment of the present application. The partner application background in Figure 10 can be a third-party application that uses microservices. The partner application backend sends an access request to the target interface of the microservice to the authorization appraisal module (Authorization appraisal) of the microservice gateway. The authority identification module sends a query request to the data storage module to check whether the user who invokes the interface has the corresponding authority.

Wherein, data maintenance can be performed on the data storage module in advance through an authority assignment module. The data maintenance may include: assembling the permission assignment data requested by the front end, sending a request to the data storage module; and the data storage module responding to the request and saving the permission result. To simplify naming, "authorization roles" are simply referred to as "roles" in the data storage module. The data relationships maintained in the data storage module may include:

1) User object (user) data table, the data fields stored in this data table can include user AK and user SK;

2) a user-role relationship object (user-role) data table, the data fields stored in the data table may include user AK and role id (identification);

3) role object (role) data table, the data fields stored in this data table can include role id and role name;

4) a role-URL relationship object (role-URL) data table, the data fields stored in the data table may include a role id and an authority id; wherein, the authority id is the URL id;

5) URL object data table, the data fields stored in the data table can include interface id and interface address; wherein, interface id is also URL id;

6) Microservice-URL relational object (service-URL) data table, the data fields stored in the data table may include service id and interface id;

7) Micro service object (Micro service) data table, the data fields stored in the data table may include service id and service name.

Referring to FIG. 10, the process of querying whether the user who invokes the interface has the corresponding authority may include:

Step 1) according to the access request including the user identification, in the user object (user) data table, look up whether there is a user AK that matches the user identification;

Step 2) If the user AK matching the user ID is found in step 1), according to the matching user AK, in the user-role relationship object (user-role) data table, look up the role id corresponding to the user AK ;

Step 3) according to the role id found in step 2), in the role-URL relationship object (role-URL) data table, look up the URL id corresponding to the role id;

Step 4) According to the URL id found in step 3), in the URL object data table, look up the interface address (URL address) corresponding to the URL id.

In the embodiment of the present application, the interface corresponding to the authorization role corresponding to the user ID is queried through the above process, the unified management of the access rights of multiple microservice interfaces is realized through the authorization role, and the same authorization role can be set for users with the same access requirements. There is no need to set the authorized access URL for each user separately. Since the number of authorized roles is much smaller than the number of URLs, the microservice access control method of the embodiment of the present application improves management efficiency and ensures service performance.

In one embodiment, controlling access to the target interface according to the result of the query includes:

In the case that the authorization role corresponding to the user ID includes the target interface, the target interface is allowed to be accessed.

Referring to Fig. 10 again, after the authority identification module inquires the data storage module whether the user who invokes the interface has the corresponding authority, in the data storage module, through the query process of the above-mentioned steps 1) to step 4), the authority identification module returns the authorization. result. If the target interface requested to be accessed by the user is found in step 4), the target interface is allowed to be accessed. In an embodiment, after the authentication is passed, a tamper-resistant signature may be calculated according to the request parameters in the access request in the signature verification module (Signature verification) to identify whether it has been tampered with. The gateway illustrated in Figure 10 adopts a unified authentication method and requires tamper-proof signatures for all request parameters, which ensures the security of Internet access. If the verification is passed in the signature verification module, the partner application background is allowed to access the target interface, and the request data result is returned. For example, if a partner application requests to access the weather microservice in the background, the request data result about the weather information is returned.

In the embodiment of the present application, the user ID-role-authorization management method is adopted to assign roles to the user AK, and perform authorization management according to the roles, thereby realizing unified and efficient management of access rights of multiple microservice interfaces. Take the cloud platform that adopts the SpringCloud microservice architecture as an example, the cloud platform can provide users with dozens of microservices, each microservice can provide several interfaces, and the total number of interfaces can exceed 800. By using the microservice access control method in the embodiment of the present application, the time for issuing AK and SK to new users can be controlled within 1 minute, which significantly improves system performance.

In one embodiment, controlling access to the target interface according to the result of the query includes:

When the authorization role corresponding to the user ID includes the target interface, tamper-proof verification is performed on the access request;

Access to the target interface is allowed if the tamper proof verification is passed.

In this embodiment, if the authorization role corresponding to the user identification includes the target interface, it can be determined that the authentication is passed. Referring to the example in FIG. 10 , after the authentication is passed, the tamper-resistant signature can also be calculated in the signature verification module according to the request parameters in the access request to identify whether it has been tampered with. In one example, the request parameters may include Access KeyId, timestamp (timestamp), and sign (tamper-resistant signature).

In the embodiment of the present application, on the basis of authentication, the tamper-proof signature can further ensure secure access control to the microservice interface.

In one embodiment, tamper-proof verification is performed on the access request, including:

Generate the first tamper-resistant signature information according to the key corresponding to the user ID and the timestamp included in the access request;

comparing the first tamper-resistant signature information with the second tamper-resistant signature information included in the access request;

If the first tamper-resistant signature information is the same as the second tamper-resistant signature information, it is determined that the tamper-resistant verification is passed.

In an exemplary tamper-proof verification method, the client may be required to access the header tag Header in the request message to include the following request parameters:

1. Access Key Id: Indicates the user ID.

The access Key Id is assigned to the third-party application by the web (World Wide Web) management system of the unified open platform gateway.

2. timestamp: Indicates the request time.

In one example, timestamp can be a 13-bit timestamp. The request time can be expressed in UTC+8. For example 1569291769123. Among them, UTC is Coordinated Universal Time. Due to the different abbreviations in English (CUT) and French (TUC), as a compromise, it is referred to as UTC. UTC+8 means international time plus eight hours, which is the East Eighth District time and Beijing time.

3. sign: Indicates a tamper-proof signature. For example OnV1CRIWXv+k89BTphzb0AZ9m3A=.

The tamper-proof signature is generated according to the secret key, timestamp, and signature algorithm corresponding to the access Key Id. On the client side, according to the secret key SK corresponding to the access Key Id and the timestamp timestamp of the access request, the signature algorithm is used to generate the second tamper-resistant signature information, that is, the request parameter sign included in the access request is generated. After receiving the access request, the server uses the same signature algorithm according to the key corresponding to the user ID and the timestamp included in the access request, that is to say, uses the same calculation method to calculate the first tamper-proof signature information. The server compares whether the sign (second tamper-proof signature information) in the client Header and the first tamper-proof signature information calculated by the server are the same. has not been tampered with. In this case, it is determined that the tamper proof verification passes.

In the embodiment of the present application, the tamper-resistant signature can solve the problems of forgery, denial, impersonation and tampering, ensure the integrity of information transmission, the identity authentication of the sender, and prevent denial behavior in interaction.

FIG. 11 is a schematic diagram of a microservice access control apparatus according to an embodiment of the present application. As shown in Figure 11, the microservice access control device may include:

A receiving unit 100, configured to receive an access request to the target interface of the microservice, where the access request includes a user identifier;

A query unit 200, configured to query an authorization role corresponding to the user ID, where the authorization role includes at least one interface with access rights;

The control unit 300 is configured to control the access to the target interface according to the query result.

FIG. 12 is a schematic diagram of a microservice access control apparatus according to another embodiment of the present application. As shown in FIG. 12 , the above-mentioned device further includes a setting unit 400 for:

Pre-set at least one microservice for access control;

The correspondence between each microservice and at least one interface is preset.

In one embodiment, the above device further includes a setting unit 400 for:

Pre-set at least one authorization role;

The corresponding relationship between the authorization role and the at least one interface with access rights is preset.

In one embodiment, the setting unit 400 is further used for:

Pre-set at least one user ID;

A corresponding relationship between the user ID and at least one authorization role is preset.

FIG. 13 is a schematic diagram of a query unit of a microservice access control apparatus according to another embodiment of the present application. As shown in FIG. 13, in one embodiment, the query unit 200 includes:

The first query subunit 210 is configured to query the authorization role corresponding to the user ID according to the corresponding relationship between the user ID and at least one authorization role;

The second query subunit 220 is configured to query, according to the corresponding relationship between the authorization role and at least one interface with access rights, the interfaces with access rights included in the authorization role corresponding to the user ID.

In one embodiment, the control unit 300 is used to:

In the case that the authorization role corresponding to the user ID includes the target interface, the target interface is allowed to be accessed.

In one embodiment, the control unit 300 includes:

A verification subunit, used to perform tamper-proof verification on the access request when the authorization role corresponding to the user ID includes the target interface;

The control subunit is used to allow access to the target interface when the tamper-proof verification is passed.

In one embodiment, the verification subunit is used to:

Generate the first tamper-resistant signature information according to the key corresponding to the user ID and the timestamp included in the access request;

comparing the first tamper-resistant signature information with the second tamper-resistant signature information included in the access request;

If the first tamper-resistant signature information is the same as the second tamper-resistant signature information, it is determined that the tamper-resistant verification is passed.

For the functions of each unit in the microservice access control apparatus according to the embodiment of the present application, reference may be made to the corresponding description in the foregoing method, and details are not described herein again.

FIG. 14 is a block diagram of an electronic device used to implement the microservice access control method according to the embodiment of the present application. As shown in FIG. 14 , the control device includes: a memory 910 and a processor 920 , and instructions that can be executed on the processor 920 are stored in the memory 910 . When the processor 920 executes the instruction, the microservice access control method in the foregoing embodiment is implemented. The number of the memory 910 and the processor 920 may be one or more. The control device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Control devices may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are by way of example only, and are not intended to limit implementations of the application described and/or claimed herein.

The control device may further include a communication interface 930 for communicating with external devices and performing data interactive transmission. The various devices are interconnected using different buses and can be mounted on a common motherboard or otherwise as desired. Processor 920 may process instructions executed within the control device, including instructions stored in or on memory to display graphical information of the GUI on an external input/output device, such as a display device coupled to the interface. In other embodiments, multiple processors and/or multiple buses may be used with multiple memories and multiple memories, if desired. Likewise, multiple control devices may be connected, with each device providing some of the necessary operations (eg, as a server array, a group of blade servers, or a multi-processor system). The bus can be divided into address bus, data bus, control bus and so on. For ease of presentation, only one thick line is shown in FIG. 14, but it does not mean that there is only one bus or one type of bus.

Optionally, in specific implementation, if the memory 910, the processor 920 and the communication interface 930 are integrated on one chip, the memory 910, the processor 920 and the communication interface 930 can communicate with each other through an internal interface.

It should be understood that, the above-mentioned processor may be a central processing unit (Central Processing Unit, CPU), and may also be other general-purpose processors, digital signal processors (Digital Signal Processing, DSP), application specific integrated circuits (Application Specific Sntegrated Circuit, ASIC), Field Programmable Gate Array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general purpose processor may be a microprocessor or any conventional processor or the like. It should be noted that the processor may be a processor supporting an advanced RISC machines (ARM) architecture.

Embodiments of the present application provide a computer-readable storage medium (such as the above-mentioned memory 910 ), which stores computer instructions, and when the program is executed by a processor, implements the methods provided in the embodiments of the present application.

Optionally, the memory 910 can include a stored program area and a stored data area, wherein the stored program area can store an operating system and an application program required by at least one function; data etc. Additionally, memory 910 may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory 910 may optionally include memory located remotely from processor 920, which may be connected to the microservice access control device via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

In the description of this specification, description with reference to the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples", etc., mean specific features described in connection with the embodiment or example , structure, material or feature is included in at least one embodiment or example of the present application. Furthermore, the particular features, structures, materials or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and combine the different embodiments or examples described in this specification, as well as the features of the different embodiments or examples, without conflicting each other.

In addition, the terms "first" and "second" are only used for descriptive purposes, and should not be construed as indicating or implying relative importance or implying the number of indicated technical features. Thus, a feature delimited with "first", "second" may expressly or implicitly include at least one of that feature. In the description of the present application, "plurality" means two or more, unless otherwise expressly and specifically defined.

Any description of a process or method in a flowchart or otherwise described herein may be understood to represent a representation of executable instructions comprising one or more (two or more) steps for implementing a specified logical function or process. A module, fragment or section of code. Also, the scope of the preferred embodiments of the present application includes alternative implementations in which the functions may be performed out of the order shown or discussed, including performing the functions substantially concurrently or in the reverse order depending upon the functions involved.

The logic and/or steps represented in flowcharts or otherwise described herein, for example, may be considered an ordered listing of executable instructions for implementing the logical functions, may be embodied in any computer-readable medium, For use with, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or other system that can fetch instructions from and execute instructions from an instruction execution system, apparatus, or apparatus) or equipment.

It should be understood that various parts of the present application may be implemented in hardware, software, firmware, or a combination thereof. In the above-described embodiments, various steps or methods may be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the method in the above-mentioned embodiments can be completed by instructing the relevant hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one of the steps of the method embodiment or its combination.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing module, or each unit may exist physically alone, or two or more units may be integrated into one module. The above-mentioned integrated modules can be implemented in the form of hardware, and can also be implemented in the form of software function modules. If the above-mentioned integrated modules are implemented in the form of software functional modules and sold or used as independent products, they may also be stored in a computer-readable storage medium. The storage medium may be a read-only memory, a magnetic disk or an optical disk, and the like.

The above are only specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of various changes or replacements thereof within the technical scope disclosed by the present application, These should all be covered within the protection scope of this application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (18)

1. A method for micro-service access control, comprising:

receiving an access request to a target interface of the micro service, wherein the access request comprises a user identifier;

inquiring an authorized role corresponding to the user identification, wherein the authorized role comprises at least one interface with access right;

and controlling the access to the target interface according to the query result.

2. The method of claim 1, further comprising:

presetting at least one micro service for access control;

and presetting the corresponding relation between each micro service and at least one interface.

3. The method of claim 1, further comprising:

presetting at least one authorized role;

and presetting the corresponding relation between the authorized role and at least one interface with access authority.

4. The method of claim 3, further comprising:

presetting at least one user identifier;

the corresponding relation between the user identification and at least one authorized role is preset.

5. The method of claim 4,

inquiring an authorized role corresponding to the user identification, wherein the method comprises the following steps: inquiring an authorized role corresponding to the user identifier according to the corresponding relation between the user identifier and at least one authorized role;

the method further comprises the following steps:

and inquiring the interface with the access right included in the authorization role corresponding to the user identification according to the corresponding relation between the authorization role and at least one interface with the access right.

6. The method of any of claims 1 to 5, wherein controlling access to the target interface based on the result of the query comprises:

and allowing access to the target interface under the condition that the authorized role corresponding to the user identification comprises the target interface.

7. The method of any of claims 1 to 5, wherein controlling access to the target interface based on the result of the query comprises:

performing tamper-proof verification on the access request under the condition that the authorized role corresponding to the user identifier comprises the target interface;

and in the case that the tamper-proof verification is passed, allowing access to the target interface.

8. The method of claim 7, wherein performing tamper-proof verification on the access request comprises:

generating first anti-tampering signature information according to a secret key corresponding to the user identification and a timestamp included in the access request;

comparing the first tamper-resistant signature information with second tamper-resistant signature information included in the access request;

determining that the tamper-proof verification passes if the first tamper-proof signature information is the same as the second tamper-proof signature information.

9. A microservice access control device, comprising:

the system comprises a receiving unit, a processing unit and a processing unit, wherein the receiving unit is used for receiving an access request of a target interface of the micro service, and the access request comprises a user identifier;

the query unit is used for querying an authorization role corresponding to the user identifier, and the authorization role comprises at least one interface with access right;

and the control unit is used for controlling the access to the target interface according to the query result.

10. The apparatus according to claim 9, further comprising a setting unit for:

presetting at least one micro service for access control;

and presetting the corresponding relation between each micro service and at least one interface.

11. The apparatus according to claim 9, further comprising a setting unit for:

presetting at least one authorized role;

and presetting the corresponding relation between the authorized role and at least one interface with access authority.

12. The apparatus of claim 11, wherein the setting unit is further configured to:

presetting at least one user identifier;

the corresponding relation between the user identification and at least one authorized role is preset.

13. The apparatus of claim 12, wherein the query unit comprises:

the first inquiry subunit is used for inquiring the authorization role corresponding to the user identifier according to the corresponding relation between the user identifier and at least one authorization role;

and the second query subunit is used for querying the interface with the access right included in the authorization role corresponding to the user identifier according to the corresponding relation between the authorization role and at least one interface with the access right.

14. The apparatus according to any one of claims 9 to 13, wherein the control unit is configured to:

and allowing access to the target interface under the condition that the authorized role corresponding to the user identification comprises the target interface.

15. The apparatus according to any one of claims 9 to 13, wherein the control unit comprises:

the verification subunit is used for performing tamper-proof verification on the access request under the condition that the authorized role corresponding to the user identifier comprises the target interface;

and the control subunit is used for allowing the target interface to be accessed under the condition that the tamper-proof verification is passed.

16. The apparatus of claim 15, wherein the authentication subunit is configured to:

generating first anti-tampering signature information according to a secret key corresponding to the user identification and a timestamp included in the access request;

comparing the first tamper-resistant signature information with second tamper-resistant signature information included in the access request;

determining that the tamper-proof verification passes if the first tamper-proof signature information is the same as the second tamper-proof signature information.

17. An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 8.

18. A computer readable storage medium having stored therein computer instructions which, when executed by a processor, implement the method of any one of claims 1 to 8.

Images