CN112788031B - Micro-service interface authentication system, method and device based on Envoy architecture - Google Patents
Micro-service interface authentication system, method and device based on Envoy architecture Download PDFInfo
- Publication number
- CN112788031B CN112788031B CN202110033305.2A CN202110033305A CN112788031B CN 112788031 B CN112788031 B CN 112788031B CN 202110033305 A CN202110033305 A CN 202110033305A CN 112788031 B CN112788031 B CN 112788031B
- Authority
- CN
- China
- Prior art keywords
- access
- interface
- verification
- envoy
- gateway
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/33—User authentication using certificates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/45—Structures or tools for the administration of authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
- H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2151—Time stamp
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The embodiment of the application discloses a micro-service interface authentication system, a method and a device based on an Evnoy architecture, and the technical scheme provided by the embodiment of the application is that an LDS interface is matched with a right verification center, a monitor and a Lua filter are configured for the LDS interface and are associated with an Envoy gateway, so that access right verification rules locally stored in the Envoy gateway are dynamically updated according to right configuration of each Api interface of the right verification center, and the mapping of the Api interface right configuration to self filtering verification configuration in the Envoy gateway is realized; the method and the device have the advantages that the dynamic update management of the Api interface authority configuration is supported, and meanwhile, the additional overhead of carrying out an authentication request when each Api interface call is avoided.
Description
Technical Field
The embodiment of the application relates to the technical field of interface communication, in particular to an Envoy-based micro-service interface authentication system, an Envoy-based micro-service interface authentication method, an Envoy-based micro-service interface authentication device and a storage medium.
Background
With the continuous development of cloud computing basic setting and micro-service architecture in recent years, micro-service development focuses more on services themselves, and some framework functions of service discovery, service invocation, service authority management and unified login authentication centers are unified into infrastructure construction.
Currently, service authority authentication is gradually changed from a Cookie (data stored on a local terminal of a user)/Session (Session control, session object stores attributes and configuration information required by a specific user Session) mechanism to a Token authentication mode which tends to be stateless. The general flow of Token authentication method is: the client uses the user name and the password to request login, the server receives the request, verifies the user name and the password, after the user name and the password are successfully verified, the server signs a token, sends the token to the client, stores the token after the client receives the token, such as in a Cookie or a local storage, the client needs to carry the token issued by the server each time when requesting resources from the server, the server verifies the token carried by the client when receiving the request, and if the user is successfully verified, the data requested by the client is returned. For example JWT (json web tokens) technology, leverages the stateless design theory of micro-services. Most of the Api gateways, such as Kong, nginx, envoy, can parse and verify the JWT currently to implement the preliminary access authentication of the service Api interface.
However, in the application scenario of rights management of the interface layer, with the continuous online of new interfaces, the gradual development of daily micro-service services such as rights adjustment of old interfaces, etc., a service API interface rights management center is needed to intervene, so that operators uniformly manage the rights change of the interfaces and support the verification of the access rights of the interfaces. And most of the Api gateways support access to an external authority verification center so as to verify the access authority of the Api interface through the external authority verification center when the access authority of the Api interface is serviced each time, and the cost is that each time the access of the Api interface is invoked, an additional authentication request is brought.
Disclosure of Invention
The embodiment of the application provides a micro-service interface authentication system, a method, a device, equipment and a storage medium based on an Evnoy architecture, so that access permission verification is not required to be carried out by calling a third party permission verification interface each time, and the expenditure of calling time of an Api interface to a service per se is reduced.
In a first aspect, an embodiment of the present application provides a micro-service interface authentication system based on an Evnoy architecture, including a client, an Envoy gateway, and a rights verification center, where the Envoy gateway and the rights verification center are both connected with the client;
the right verification center is used for configuring the access right of each Api interface and adapting an LDS interface associated with the Envoy gateway; the LDS interface is provided with a monitor and a Lua filter to collect the access rights, generate an access rights verification rule and transmit the access rights verification rule to the Envoy gateway, so that the Envoy gateway dynamically updates the locally stored access rights verification rule according to the access rights verification rule; the Envoy gateway is used for verifying the legitimacy of the access token in the access request from the client according to the locally stored access right verification rule.
In a second aspect, an embodiment of the present application provides a micro service interface authentication method based on an evnon architecture, including:
receiving an access right verification rule from a right verification center through an LDS interface, wherein the access right verification is obtained by the right verification center through configuration and collection of access rights of all Api interfaces;
dynamically updating the local storage access right verification rule according to the access right verification rule;
receiving an access request of a client, wherein the access request comprises an access token and a payload, and the access token comprises any one or more of access timeliness, an issuing mechanism, a security protocol, a check code, a random character string, a permission identifier and a user ID;
analyzing the access token, and verifying the legitimacy of the analyzed access token based on the locally stored access right verification rule.
In a third aspect, an embodiment of the present application provides a micro service interface authentication device based on an evnon architecture, including:
an access rule association module: the access right verification rule is used for receiving access right verification rules from the right verification center through the LDS interface, and the access right verification is obtained by the right verification center through configuration and collection of the access right of each Api interface;
an access rule updating module: the local storage access right verification rule is used for dynamically updating the local storage access right verification rule according to the access right verification rule;
an access request receiving module: the method comprises the steps that an access request of a client is received, wherein the access request comprises an access token and a payload, and the access token comprises any one or more of access timeliness, an issuing mechanism, a security protocol, a check code, a random character string, a permission identifier and a user ID;
an access token verification module: the method is used for analyzing the access token and verifying the legitimacy of the analyzed access token based on the locally stored access right verification rule.
In a third aspect, an embodiment of the present application provides a micro service interface authentication device based on an evnon architecture, including: a memory and one or more processors;
the memory is used for storing one or more programs;
the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the micro-service interface authentication method based on the evnon architecture as described in the first aspect.
In a fourth aspect, embodiments of the present application provide a storage medium containing computer-executable instructions, which when executed by a computer processor, are for performing the micro-service interface authentication method based on the evnon architecture as described in the first aspect.
According to the embodiment of the application, the LDS interface is adapted to the authority verification center, the monitor and the Lua filter are configured for the LDS interface and are associated with the Envoy gateway, so that the access authority verification rule locally stored in the Envoy gateway is dynamically updated according to the authority configuration of each Api interface of the authority verification center, and the filtering verification configuration of mapping the authority configuration of the Api interface into the Envoy gateway is realized; the method and the device have the advantages that the dynamic update management of the Api interface authority configuration is supported, and meanwhile, the additional overhead of carrying out an authentication request when each Api interface call is avoided.
Drawings
Fig. 1 is a schematic structural diagram of a micro service interface authentication system based on an Evnoy architecture according to an embodiment of the present application;
fig. 2 is a schematic diagram of a micro service interface authentication system based on an Evnoy architecture according to an embodiment of the present application;
fig. 3 is a schematic structural diagram of another micro service interface authentication system based on the Evnoy architecture according to an embodiment of the present application;
fig. 4 is a flowchart of a micro service interface authentication method based on the Evnoy architecture according to an embodiment of the present application;
FIG. 5 is a flow chart of a method for generating an access token by a rights verification center provided by an embodiment of the present application;
FIG. 6 is a flowchart of a method for verifying the validity of an parsed access token according to an embodiment of the present application;
fig. 7 is a schematic flow chart of obtaining access rights by the rights verification center according to an embodiment of the present application;
fig. 8 is a schematic structural diagram of a micro service interface authentication device based on an Evnoy architecture according to an embodiment of the present application;
fig. 9 is a schematic structural diagram of a micro service interface authentication device based on the Evnoy architecture according to an embodiment of the present application.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the following detailed description of specific embodiments thereof is given with reference to the accompanying drawings. It is to be understood that the specific embodiments described herein are merely illustrative of the application and not limiting thereof. It should be further noted that, for convenience of description, only some, but not all of the matters related to the present application are shown in the accompanying drawings. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although a flowchart depicts operations (or steps) as a sequential process, many of the operations can be performed in parallel, concurrently, or at the same time. Furthermore, the order of the operations may be rearranged. The process may be terminated when its operations are completed, but may have additional steps not included in the figures. The processes may correspond to methods, functions, procedures, subroutines, and the like.
The embodiment of the application provides a micro-service interface authentication system, a method, a device, equipment and a storage medium based on an Evnoy architecture, wherein the embodiment of the application is characterized in that an LDS interface is matched with a right verification center, a monitor and a Lua filter are configured for the LDS interface and are associated with an Envoy gateway, so that access right verification rules locally stored in the Envoy gateway are dynamically updated according to right configuration of each Api interface of the right verification center, and the mapping of the Api interface right configuration to self filtering verification configuration in the Envoy gateway is realized; the method and the device have the advantages that the dynamic update management of the Api interface authority configuration is supported, and meanwhile, the additional overhead of carrying out an authentication request when each Api interface call is avoided.
The following detailed description is given respectively.
Fig. 1 shows a schematic structural diagram of a micro service interface authentication system based on an Evnoy architecture according to an embodiment of the present application, and fig. 2 shows a schematic diagram of a micro service interface authentication system based on an Evnoy architecture according to an embodiment of the present application. Referring to fig. 1 and fig. 2, the micro service interface authentication system provided in the embodiment of the present application includes a client 101, an Envoy gateway 102, and a rights verification center 103. Wherein Envoy is an L7 proxy and communication bus specially designed for large modern service-oriented architecture, and is a side car mode as gateway and cloud storage. The sidecar is a form of application design that divides the functionality of an application into separate processes, i.e., single-node, multi-container. The client as a user end is often carried on the terminal as an application program, and provides services for users. More common clients include web browsers, email clients, instant messaging client software, and the like. As a terminal carrying a client, a desktop computer, a notebook computer, an apple computer, a smart bracelet, a smart watch, or the like is generally included. The rights verification center is also commonly referred to as an authentication center, and in this embodiment of the present application, is used to manage the rights of the individual Api interfaces. The service implementation 1 and the service implementation 2 shown in fig. 2 represent services provided for two different access requests.
Specifically, the Envoy gateway 102 and the rights verification center 103 are both connected to the client 101. The rights verification center 103 verifies the login request sent by the user through the client 101, and in this embodiment of the present application, the rights of the Api interface configured by the rights verification center 103 are creatively mapped into the Envoy gateway 102. The authority verification center 103 is used for configuring the access authority of each Api interface and adapting an LDS interface associated with the Envoy gateway 102; the LDS interface is configured with a monitor and a Lua filter to collect the access rights, generate an access rights verification rule and transmit the access rights verification rule to the Envoy gateway, so that the Envoy gateway 102 dynamically updates the locally stored access rights verification rule according to the access rights verification rule; the Envoy gateway 102 is configured to legally verify an access token in an access request from a client according to a locally stored access rights verification rule.
In the embodiment of the application, the authority verification center is configured by operation and maintenance staff. The access permission configuration of the Api interface includes that an operation and maintenance staff newly adds the Api interface permission configuration or modifies the Api interface permission configuration in a permission verification center, and the Api interface permission configuration is used as an update of an Api interface permission rule in the embodiment of the application no matter whether the Api interface permission configuration is newly added or modified, and is dynamically updated to an Envoy gateway through an LDS interface later. The configuration of the permission of the newly added Api interface is mainly to newly add the Api interface and configure permission rules for the newly added Api interface. Modifying the Api interface permission configuration is often performed by modifying permission rules of an existing Api interface, including but not limited to deleting rules, adding rules, and adjusting rules.
The operation and maintenance staff also adapts LDS (Listener Discovery Service) interface at the rights verification center, in this embodiment, the LDS interface can be used to control the configuration of the plane dynamically updating Envoy listener, typically in both GRPC and REST implementations. The LDS interface is provided with a listener and a Lua filter. Because the operation and maintenance staff configures the access rights of each Api interface in the rights verification center, the access rights of each Api interface can be monitored and collected through a monitor on the LDS interface. In the Envoy gateway, a static filtering template is actually configured, and the collected access rights and the static filtering template are combined in the LDS interface, so that the access rights are embedded into the static filtering template.
In the embodiment of the application, for a user of a client, firstly, logging in to a permission verification center is needed, user identity information verification is carried out, after logging in is successful, role information and permission identification of the user are queried according to the user identity information, and an access token is generated by combining the user identity information, the role information, the permission identification and the like and is issued to the client. When the user of the client subsequently performs other specific business operations and needs to call the Api interface of the back-end micro-service, the client automatically brings an access token to be used as the authority verification credential of the Api interface.
For operation staff, operation and maintenance configuration such as authority setting, api interface and authority management is required to be performed in the authority verification center according to operation requirements such as the online and offline of the service interface and the authority setting, and the configuration comprises the configuration of an LDS interface, the configuration of a monitor and a Lua filter of the LDS interface, the configuration of access authorities of all Api interfaces and the like. After the configuration is successful, the authority verification center generates new listener configuration of the Envoy gateway according to the configuration, and notifies the listener configuration to the Envoy gateway for updating by means of the LDS interface, so that the Envoy gateway has the latest authority verification rule, and can directly verify the access request of the user without authentication request.
Fig. 3 shows another micro service interface authentication system based on the Evnoy architecture disclosed in the embodiment of the present application, and in combination with fig. 2 to fig. 3, the micro service interface authentication system provided in the embodiment of the present application includes a client 301, an Envoy gateway 302, and a rights verification center 303, where the Envoy gateway 302 and the rights verification center 303 are both connected with the client 301. Similarly, the rights verification center 303 is configured to configure access rights of each Api interface, and is adapted to an LDS interface associated with the Envoy gateway; a monitor and a Lua filter are configured on the LDS interface to collect the access rights, generate an access rights verification rule and transmit the access rights verification rule to the Envoy gateway 302, so that the Envoy gateway 302 dynamically updates the locally stored access rights verification rule according to the access rights verification rule; the Envoy gateway 302 is configured to perform legal authentication on the access token in the access request from the client 301 according to the locally stored access rights authentication rule.
Specifically, the Envoy gateway 302 in the embodiment of the present application is provided with a host cluster 3021 and a local listener 3022 that are connected to each other, where the local listener 3022 is associated with the LDS interface; the host cluster 3021 is configured to configure a local rights verification center, and the local listener 3022 is configured to configure a static filtering template, receive, via an LDS interface, an access rights verification rule generated by the rights verification center according to the static filtering template and the access rights, and dynamically update the access rights verification rule to the local rights verification center.
In this embodiment, the function that the Envoy gateway 302 can dynamically update the locally stored access right verification rule according to the access right verification rule and perform legal verification on the access token in the access request from the client according to the locally stored access right verification rule is specifically expressed by the host cluster 3021 and the local listener 3022, the access right verification rule is dynamically updated by the local listener 3022, and the access right verification rule is stored by the host cluster 3021, so that when the access request from the client is received, the legal verification can be performed by the host cluster 3021 without performing an authentication request again.
Fig. 4 is a flowchart of a micro service interface authentication method based on an Evnoy architecture according to an embodiment of the present application, where the micro service interface authentication method based on an Evnoy architecture according to an embodiment of the present application may be executed by a micro service interface authentication device based on an Evnoy architecture, and the micro service interface authentication device based on an Evnoy architecture may be implemented by hardware and/or software and integrated in a computer device.
The following describes an example of a method for executing the micro service interface authentication method based on the Evnoy architecture by the micro service interface authentication device based on the Evnoy architecture. Referring to fig. 4, the micro service interface authentication method based on the Evnoy architecture includes:
401: and receiving access right verification rules from a right verification center through the LDS interface, wherein the access right verification is obtained by the right verification center through configuration and collection of the access right of each Api interface.
The micro-service interface authentication method based on the Evnoi architecture provided by the embodiment of the application is applied to an Envoy gateway of the micro-service interface authentication system based on the Evnoi architecture provided by the embodiment of the application. The Envoy gateway is connected with the client and also is connected with the authority verification center. In the Envoy gateway, a host cluster and a local monitor are mutually connected, wherein the host cluster is used for configuring a local authority verification center, the local monitor is used for configuring a static filtering template, and the static filtering module is used for providing a framework for the authority verification center to generate an authority verification rule, so that the authority verification center embeds the access authority into the static filtering module to generate the access authority verification rule.
In the embodiment of the application, an LDS interface is configured in the authority verification center, and the LDS interface is associated with the Envoy gateway and can map the access authority verification rule generated in the authority verification center into the Envoy gateway. Therefore, the Envoy gateway can acquire the access right verification rule through the LDS interface.
402: and dynamically updating the local storage access right verification rule according to the access right verification rule.
Because the host cluster and the local monitor are arranged in the Envoy gateway, the configuration of the local monitor is actually modified into a dynamic configuration mode, namely, the monitor of the authority verification center is mapped to the local monitor through the LDS. The access right verification rule is generated by a right verification center based on the collection of the access right of each Api interface and the combination of the static filter template of the Envoy gateway, and after the right verification center generates the access right verification rule, the access right verification rule is updated to a local right verification center in the host cluster through the LDS interface so as to verify the validity of the access request of the subsequent user.
403: and receiving an access request of the client, wherein the access request comprises an access token and a payload, and the access token comprises any one or more of access timeliness, an issuing mechanism, a security protocol, a check code, a random character string, a permission identifier and a user ID.
The access request of the client is generated by inputting the user at the client, and is generated after the user passes the identity information verification of the client and the authority verification center, and the access token carried in the access request is issued by the authority verification center after the login request is provided for the user to the authority verification center and the login is successful.
Wherein, the access token in the access request of the client is generated by the authority verification center, and the mode of generating the access token by the authority verification center is shown in fig. 5, and the mode is applied in the authority verification center and comprises the following steps:
501: a login request of a user is received, wherein the login request comprises user identity information, and the user identity information comprises a user ID and a login password.
The user inputs a login request through the client, and the login request is sent to the authority verification center through the client. The user information verification method is that the user input request is received, the user input request is provided for the input box of the user input account number and the password at the client, and the user inputs the login request through the client, so that the login request contains the user identity information. In the embodiment of the application, the user identity information includes a user ID and a login password. The user ID generally refers to a code that characterizes the user's uniqueness, such as a unique user name, or a corresponding user code based on user name. Before the user logs in, the user is often required to register, and during this operation, a login password and a user ID are generated.
502: checking whether user identity information consistent with the user identity information is stored, and when there is no user identity information consistent with the user identity information, executing 503: and feeding back login failure information to the client.
User identity information of different users from different clients is stored in the authority verification center. After receiving a login request of a user, traversing all user identity information stored in the user, matching the user identity information in the login request of the user with the user identity information stored in the user, and marking that the user is successfully registered before as a legal user when the user can be matched with the consistent user identity information. When the user identity information consistent with the user identity information in the login request cannot be searched, the user identity information is marked as failed in verification, login failure information is fed back to the client side to remind the user, and as a further supplement, the user can be reminded to perform account registration to obtain legal user identity information.
On the other hand, when there is user identity information consistent with the user identity information, 504 is performed: inquiring the role information and authority identification of the user.
Corresponding to users of different levels, the authority verification center is provided with role information and authority identification matched with the authority verification center in advance. For example, for a government work unit employee, the authority identification and role information to which he responds is configured according to his identity information, so that he can access the micro-service interface within the authority, or the corresponding resource. The corresponding ordinary users are often lower in level, the permission identification and the role information are configured for the ordinary users, when the users access the micro service interface, the access can only access links disclosed to people, and the information between the corresponding employee intranets can not be accessed and shared.
505: and acquiring current time stamp information and an issuing mechanism, and generating an access token according to the role information, the authority identification, the current time stamp information and the issuing mechanism.
According to the current time stamp information, access timeliness can be generated according to preset access time length, and the access timeliness indicates a time stamp used for indicating that the maximum time limit of the access timeliness is reached when the time stamp is reached, namely, the access cannot be performed any more. The embodiment of the application combines the role information, the authority identification, the current time stamp information and the issuing mechanism to jointly generate the access token.
Specifically, in the embodiment of the present application, the access token includes token load information and response header information, where the token load information includes a permission identifier and a user ID, and the response header information includes verification information generated according to the role information, current timestamp information, and issuing authorities. The generated token is encrypted with a key.
For example, the original access token before encryption is:
“iss:example.company.com
exp:2020.10.12 15:36:45
user:02343
authorities:["sys.i18n.update","hot.video.query"]”。
the access token after being encrypted by the HS512 algorithm and the key is as follows:
“eyJhbGciOiJIUzUxMiJ9.
eyJpc3MiOiJleGFtcGxlLmNvbXBhbnkuY29tIiwiZXhwIjoxNjAzODQ1NzcwLCJ1c2VyIjoiMDIzNDMiLCJjcmVhdGVkIjoxNjAzODAyNTcwMzA1LCJhdXRob3JpdGllcyI6WyJzeXMuaTE4bi51cGRhdGUiLCJob3QudmlkZW8ucXVlcnkiXX0.
NoqSq0E43F2WKFl6cxmLMzuPruyiPwuc1zCWqz-
rNQMJ4Jjv1P5VOBg5IR-
CRjIrx0YkCcKwsvZDyGQ2wUI9fQNjJcnZ6jLw9hQ”。
506: and after the access token is generated, the access token is sent to the client. Therefore, when the user makes an access request again next time, the access token can be carried, and the Envoy gateway can perform authority verification according to the access token.
404: analyzing the access token, and verifying the legitimacy of the analyzed access token based on the locally stored access right verification rule.
In the embodiment of the application, the Envoy gateway and the authority verification center are configured, the authority verification center collects the authority configuration information of each configured Api interface and maps the authority configuration information to the Envoy gateway, so that when an access request sent by a user through a client is received, the access can be directly and additionally validated at the Envoy gateway, and the authority verification center does not need to be called for more authentication requests.
Specifically, fig. 6 shows a flowchart of a method for verifying validity of an parsed access token according to an embodiment of the present application. As shown in fig. 6, the method for verifying the validity of the parsed access token based on the locally stored access right verification rule specifically includes:
601: and acquiring the response header information of the access token and analyzing the response header information.
In the process of verifying the access token, the response header information of the access token is verified first, and as described above, the response header information includes verification information generated according to the role information, the current timestamp information and the issuing authority.
602: verifying the access validity of the parsed response header information, and when the verification is passed, executing 603: analyzing token load information of an access token to acquire a permission identifier and a user ID, and generating a permission request based on the permission identifier and the user ID; when the verification is not passed, execution 604: feeding back verification failure information of the client; the payload contains access resource information.
And analyzing the response header information to obtain the verification information, wherein the verification information comprises verification whether access timeliness is exceeded, whether the user ID is legal ID, whether an issuing mechanism meets requirements, and the like. If the verification is not passed in the step, the verification failure information is fed back to the client to inform the client that the current verification fails. On the contrary, if the authentication is passed, the token load information in the access request needs to be verified in the next step.
The token load information is analyzed because the token load information carries the user ID and the permission identification, and the user ID and the permission identification carried in the token load information can be obtained. Generating a permission request according to the user ID and the permission identification, and verifying the permission request.
605: and verifying whether the access right of the corresponding resource interface is provided according to the right identification in the right request and the access resource information on the payload, marking the corresponding resource interface when the verification is passed, forwarding the right request to the resource interface so that the resource interface responds to the access request, and feeding back the insufficient right information of the client when the verification is not passed. The access resource information may include an access path for the client to access the resource.
And according to whether the permission identification in the permission request is matched with the access resource information, if not, the verification is not passed. A user ID often corresponds to a plurality of different permissions, for example, when a user a makes a login request before, all Api interfaces corresponding to the application layer 1 and the application layer 2 are matched in the permission identifier allocated to the user a, and the Api interfaces include an Api interface 1, an Api interface 2, an Api interface 3, an Api interface 4, an Api interface 5 and an Api interface 6. At this time, the user a puts forward an access request, and the access request includes a payload, where the payload includes access resource information, that is, a resource that the user a wants to access, and if the interface corresponding to the access resource information of the current user a includes an Api interface 7, an Api interface 8, and an Api interface 9, and the user a fails to match the Api interface 7, the Api interface 8, and the Api interface 9 in comparison with the authority identifier of the user, it indicates that the authentication is not passed, and when the interface corresponding to the access resource information of the user a is an Api interface 6, it can be obtained by matching from the authority identifier, so that the authentication is passed, the resource can be accessed through the Api interface 6, and the Api interface 6 is a resource interface of the resource.
In this embodiment of the present application, as a preferred implementation manner, as shown in fig. 7, the rights verification center obtains access rights by configuring and collecting access rights of each Api interface, including:
701: receiving access rights of all Api interfaces input by a user, and dynamically generating a Lua authentication script based on the access rights; the access rights of each Api interface comprise Api interface resource description and rights identification.
In this step, the user refers to an operation and maintenance staff member of a specific authority configuration authority, and is not a user of a client. And the operation and maintenance staff configures access rights of each Api interface in the rights verification center, and a Lua authentication script is generated based on the configuration. Lua is a compact, lightweight, extensible scripting language with a relatively simple C language, and the Api interface is thus easily embedded in an application. The access rights include an Api interface resource description and a rights identification, where the Api interface resource description also generally represents the resources, or access paths, that the Api interface is capable of requesting.
702: acquiring a static filtering template in an Envoy gateway, and combining a Lua authentication script with the static filtering template to generate an access right verification rule; the static filtering template is used for providing a template for verifying the validity of the access token in the access request according to the authority identification and the access path in the access request. The Envoy gateway is provided with a local monitor which contains a static filtering template for combining with a dynamically generated Lua authentication script of the authority verification center to form an access authority verification rule. The access path may be contained in the payload of the access request.
703: and transmitting the access right verification rule to an Envoy gateway through an LDS interface.
Fig. 8 shows a micro service interface authentication device based on the Evnoy architecture according to an embodiment of the present application, which includes an access rule association module 801, an access rule update module 802, an access request receiving module 803, and an access token verification module 804. The access rule association module 801 is configured to receive, through the LDS interface, an access right verification rule from a right verification center, where the access right verification is obtained by the right verification center through configuring and collecting access rights of each Api interface. The access rule updating module 802 is configured to dynamically update the local storage access right verification rule according to the access right verification rule. The access request receiving module 803 is configured to receive an access request of a client, where the access request includes an access token and a payload, and the access token includes any one or more of access timeliness, issuing authority, security protocol, check code, random string, rights identifier, and user ID. The access token verification module 804 is configured to parse the access token, and verify validity of the parsed access token based on a locally stored access right verification rule.
As a further preferred embodiment, in the access rule association module 801, the access token in the access request is obtained by the rights verification center in the following way: receiving a login request of a user, wherein the login request comprises user identity information, and the user identity information comprises a user ID and a login password; checking whether user identity information consistent with the user identity information is stored or not, and feeding back login failure information to a client when the user identity information consistent with the user identity information does not exist; inquiring role information and authority identification of the user when user identity information consistent with the user identity information exists; acquiring current time stamp information and an issuing mechanism, and generating an access token according to the role information, the authority identification, the current time stamp information, the issuing mechanism and the user ID; the access token is sent to the client.
The access token comprises token load information and response header information, the token load information comprises authority identification and user ID, and the response header information comprises verification information generated according to the role information, the current time stamp information and an issuing authority.
In the access token verification module 804, verifying the validity of the parsed access token includes: acquiring the response header information of the access token and analyzing the response header information; verifying the access legitimacy of the analyzed response header information, and analyzing the token load information of the access token to obtain a permission identifier and a user ID when the verification is passed, and generating a permission request based on the permission identifier and the user ID; when the verification is not passed, feeding back verification failure information of the client; the payload contains access resource information; and verifying whether the access right of the corresponding resource interface is provided according to the right identification in the right request and the access resource information on the payload, marking the corresponding resource interface when the verification is passed, forwarding the right request to the resource interface so that the resource interface responds to the access request, and feeding back the insufficient right information of the client when the verification is not passed.
In the access rule association module 801, the rights verification center obtains access rights by configuring and collecting access rights of each Api interface, including: receiving access rights of all Api interfaces input by a user, and dynamically generating a Lua authentication script based on the access rights; the access rights of each Api interface comprise Api interface resource description and rights identification; acquiring a static filtering template in an Envoy gateway, and combining a Lua authentication script with the static filtering template to generate an access right verification rule; the static filtering template is used for providing a template for verifying the validity of the access token in the access request according to the authority identification and the access path in the access request; and transmitting the access right verification rule to an Envoy gateway through an LDS interface.
As shown in fig. 9, an embodiment of the present application further provides a computer device, including: memory 901 and one or more processors 902; the memory 901 is configured to store one or more programs; the one or more programs, when executed by the one or more processors 902, cause the one or more processors to implement the micro-service interface authentication method based on the evnon architecture as described herein.
Embodiments of the present application also provide a storage medium containing computer-executable instructions, which when executed by a computer processor, are for performing the micro-service interface authentication method based on the evnon architecture as provided by the above embodiments.
Storage media-any of various types of memory devices or storage devices. The term "storage medium" is intended to include: mounting media such as CD-ROM, floppy disk or tape devices; computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, lanbas (Rambus) RAM, etc.; nonvolatile memory such as flash memory, magnetic media (e.g., hard disk or optical storage); registers or other similar types of memory elements, etc. The storage medium may also include other types of memory or combinations thereof. In addition, the storage medium may be located in a first computer system in which the program is executed, or may be located in a second, different computer system connected to the first computer system through a network such as the internet. The second computer system may provide program instructions to the first computer for execution. The term "storage medium" may include two or more storage media that may reside in different locations (e.g., in different computer systems connected by a network). The storage medium may store program instructions (e.g., embodied as a computer program) executable by one or more processors.
Of course, the storage medium containing the computer executable instructions provided in the embodiments of the present application is not limited to the micro service interface authentication method based on the evnon architecture as described above, and may also perform the related operations in the micro service interface authentication method based on the evnon architecture provided in any embodiment of the present application.
The micro service interface authentication system, the device, the equipment and the storage medium based on the Evnoy architecture provided in the foregoing embodiments may perform the micro service interface authentication method based on the Evnoy architecture provided in any embodiment of the present application, and technical details not described in detail in the foregoing embodiments may refer to the micro service interface authentication method based on the Evnoy architecture provided in any embodiment of the present application.
The foregoing description is only of the preferred embodiments of the present application and the technical principles employed. The present application is not limited to the specific embodiments described herein, but is capable of numerous obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the present application. Therefore, while the present application has been described in connection with the above embodiments, the present application is not limited to the above embodiments, but may include many other equivalent embodiments without departing from the spirit of the present application, and the scope of the present application is determined by the scope of the claims.
Claims (10)
1. The micro-service interface authentication system based on the Evnoy architecture is characterized by comprising a client, an Envoy gateway and a right verification center, wherein the Envoy gateway and the right verification center are connected with the client;
the right verification center is used for configuring the access right of each Api interface and adapting an LDS interface associated with the Envoy gateway; the LDS interface is provided with a monitor and a Lua filter, the monitor is used for collecting the access rights, the rights verification center is used for generating access rights verification rules according to the access rights and a static filtering template configured by the Envoy gateway and transmitting the access rights verification rules to the Envoy gateway, and the Envoy gateway dynamically updates the locally stored access rights verification rules according to the access rights verification rules; the Envoy gateway is used for verifying the legitimacy of the access token in the access request from the client according to the locally stored access right verification rule.
2. The micro service interface authentication system according to claim 1, wherein the Envoy gateway is provided with a host cluster and a local listener which are connected with each other, and the local listener is associated with the LDS interface; the host cluster is used for configuring a local right verification center, the local monitor is used for configuring a static filtering template, receiving an access right verification rule generated by the right verification center according to the static filtering template and the access right through the LDS interface, and dynamically updating the access right verification rule to the local right verification center.
3. The micro-service interface authentication method based on the Evnoy architecture is applied to an Envoy gateway and is characterized by comprising the following steps of:
receiving access right verification rules from a right verification center through an LDS interface, wherein the access right verification rules are generated by the right verification center based on the collected access rights of all Api interfaces and combined with a static filtering template configured by the Envoy gateway, the right verification center is adapted with an LDS interface associated with the Envoy gateway, a monitor and a Lua filter are configured on the LDS interface, and the monitor is used for collecting the access rights;
dynamically updating the local storage access right verification rule according to the access right verification rule;
receiving an access request of a client, wherein the access request comprises an access token and a payload, and the access token comprises any one or more of access timeliness, an issuing mechanism, a security protocol, a check code, a random character string, a permission identifier and a user ID;
analyzing the access token, and verifying the legitimacy of the analyzed access token based on the locally stored access right verification rule.
4. A micro service interface authentication method according to claim 3, characterized in that the access token in the access request is obtained by the rights verification center in the following way:
receiving a login request of a user, wherein the login request comprises user identity information, and the user identity information comprises a user ID and a login password;
checking whether user identity information consistent with the user identity information is stored or not, and feeding back login failure information to a client when the user identity information consistent with the user identity information does not exist;
inquiring role information and authority identification of the user when user identity information consistent with the user identity information exists;
acquiring current time stamp information and an issuing mechanism, and generating an access token according to the role information, the authority identification, the current time stamp information, the issuing mechanism and the user ID;
the access token is sent to the client.
5. The method of claim 4, wherein the access token includes token payload information including a permission identification and a user ID, and response header information including verification information generated from the role information, current timestamp information, issuing authority.
6. The method of microservice interface authentication of claim 5 wherein verifying the legitimacy of the parsed access token comprises:
acquiring the response header information of the access token and analyzing the response header information;
verifying the access legitimacy of the analyzed response header information, and analyzing the token load information of the access token to obtain a permission identifier and a user ID when the verification is passed, and generating a permission request based on the permission identifier and the user ID; when the verification is not passed, feeding back verification failure information of the client; the payload contains access resource information;
and verifying whether the access right of the corresponding resource interface is provided according to the right identification in the right request and the access resource information on the payload, marking the corresponding resource interface when the verification is passed, forwarding the right request to the resource interface so that the resource interface responds to the access request, and feeding back the insufficient right information of the client when the verification is not passed.
7. The method of claim 6, wherein the process of generating access rights verification rules by the rights verification center based on the collected access rights of each Api interface in combination with the static filter template configured by the Envoy gateway comprises:
receiving access rights of all Api interfaces input by a user, and dynamically generating a Lua authentication script based on the access rights; the access rights of each Api interface comprise Api interface resource description and rights identification;
acquiring a static filtering template in an Envoy gateway, and combining a Lua authentication script with the static filtering template to generate an access right verification rule; the static filtering template is used for providing a template for verifying the validity of the access token in the access request according to the authority identification and the access path in the access request;
and transmitting the access right verification rule to an Envoy gateway through an LDS interface.
8. The micro-service interface authentication device based on the Evnoy architecture is applied to an Envoy gateway and is characterized by comprising the following components:
an access rule association module: the access right verification rule is generated by the right verification center based on the collected access rights of all Api interfaces and combined with a static filtering template configured by the Envoy gateway, the right verification center is adapted with an LDS interface associated with the Envoy gateway, a monitor and a Lua filter are configured on the LDS interface, and the monitor is used for collecting the access rights;
an access rule updating module: the local storage access right verification rule is used for dynamically updating the local storage access right verification rule according to the access right verification rule;
an access request receiving module: the method comprises the steps that an access request of a client is received, wherein the access request comprises an access token and a payload, and the access token comprises any one or more of access timeliness, an issuing mechanism, a security protocol, a check code, a random character string, a permission identifier and a user ID;
an access token verification module: the method is used for analyzing the access token and verifying the legitimacy of the analyzed access token based on the locally stored access right verification rule.
9. A micro service interface authentication device based on an Evnoy architecture, comprising: a memory and one or more processors;
the memory is used for storing one or more programs;
the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the evnon architecture-based micro-service interface authentication method as recited in any one of claims 3-7.
10. A storage medium containing computer executable instructions which, when executed by a computer processor, are for performing the evnon architecture based microservice interface authentication method of any of claims 3-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110033305.2A CN112788031B (en) | 2021-01-11 | 2021-01-11 | Micro-service interface authentication system, method and device based on Envoy architecture |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110033305.2A CN112788031B (en) | 2021-01-11 | 2021-01-11 | Micro-service interface authentication system, method and device based on Envoy architecture |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112788031A CN112788031A (en) | 2021-05-11 |
| CN112788031B true CN112788031B (en) | 2023-06-16 |
Family
ID=75756530
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110033305.2A Active CN112788031B (en) | 2021-01-11 | 2021-01-11 | Micro-service interface authentication system, method and device based on Envoy architecture |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112788031B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11798001B2 (en) | 2021-09-20 | 2023-10-24 | International Business Machines Corporation | Progressively validating access tokens |
| CN114465895A (en) * | 2022-03-03 | 2022-05-10 | 上海微盟企业发展有限公司 | Request distribution method, device, equipment and storage medium based on micro service |
| CN116405573B (en) * | 2023-06-07 | 2023-08-15 | 北京集度科技有限公司 | Service-oriented architecture based system, communication method and computer program product |
| CN116980480B (en) * | 2023-09-25 | 2024-02-27 | 上海伊邦医药信息科技股份有限公司 | Method and system for processing fusing information based on micro-service network model |
| CN117254977B (en) * | 2023-11-16 | 2024-03-01 | 联通(广东)产业互联网有限公司 | Network security monitoring method and system and storage medium |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10057246B1 (en) * | 2015-08-31 | 2018-08-21 | EMC IP Holding Company LLC | Method and system for performing backup operations using access tokens via command line interface (CLI) |
| CN112039909A (en) * | 2020-09-03 | 2020-12-04 | 平安科技（深圳）有限公司 | Authentication method, device, equipment and storage medium based on unified gateway |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109039880A (en) * | 2018-09-05 | 2018-12-18 | 四川长虹电器股份有限公司 | A method of simple authentication authorization is realized using API gateway |
| IN201911007700A (en) * | 2019-02-27 | 2019-03-22 | ||
| CN110086822B (en) * | 2019-05-07 | 2021-07-27 | 北京智芯微电子科技有限公司 | Method and system for implementing micro-service architecture-oriented unified identity authentication strategy |
| CN110995450B (en) * | 2020-02-27 | 2020-06-23 | 中科星图股份有限公司 | Authentication and authorization method and system based on Kubernetes |
-
2021
- 2021-01-11 CN CN202110033305.2A patent/CN112788031B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10057246B1 (en) * | 2015-08-31 | 2018-08-21 | EMC IP Holding Company LLC | Method and system for performing backup operations using access tokens via command line interface (CLI) |
| CN112039909A (en) * | 2020-09-03 | 2020-12-04 | 平安科技（深圳）有限公司 | Authentication method, device, equipment and storage medium based on unified gateway |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112788031A (en) | 2021-05-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112788031B (en) | Micro-service interface authentication system, method and device based on Envoy architecture | |
| US7721322B2 (en) | Enterprise service-to-service trust framework | |
| US8347378B2 (en) | Authentication for computer system management | |
| CN108476216B (en) | System and method for integrating a transactional middleware platform with a centralized access manager for single sign-on in an enterprise-class computing environment | |
| US8141140B2 (en) | Methods and systems for single sign on with dynamic authentication levels | |
| CN103299594B (en) | System and method for extendible authentication framework | |
| US8955037B2 (en) | Access management architecture | |
| US10778603B2 (en) | Systems and methods for controlling access to broker resources | |
| CN110765484B (en) | Credit data processing method and electronic equipment | |
| US11368462B2 (en) | Systems and method for hypertext transfer protocol requestor validation | |
| CN112612629A (en) | Method and system for realizing component type data interface | |
| US20140059174A1 (en) | Method and System for Automatic Distribution and Installation of A Client Certificate in A Secure Manner | |
| US10430390B1 (en) | Method and system for managing mutual distributed ledgers in a system of interconnected devices | |
| US9237156B2 (en) | Systems and methods for administrating access in an on-demand computing environment | |
| JP2020035079A (en) | System and data processing method | |
| CN108287894A (en) | Data processing method, device, computing device and storage medium | |
| CN113472794A (en) | Multi-application system authority unified management method based on micro-service and computer readable storage medium | |
| CN113381866A (en) | Service calling method, device, equipment and storage medium based on gateway | |
| US20130191894A1 (en) | Integrating Server Applications with Multiple Authentication Providers | |
| US7506162B1 (en) | Methods for more flexible SAML session | |
| US10554789B2 (en) | Key based authorization for programmatic clients | |
| US20230376628A1 (en) | Privacy Manager for Connected TV and Over-the-Top Applications | |
| US20230078436A1 (en) | Efficient initiation of automated processes | |
| US10594570B1 (en) | Managed secure sockets | |
| CN117097540A (en) | Campus identity verification safety management method based on intelligent network connection |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |