Access authority management method and system and related equipment

Abstract

The invention relates to the technical field of computers, and provides an access authority management method and system and related equipment. The access authority management method comprises the following steps: a gateway side performs source identification on a received first request, adds an identifier representing the source of the first request in a request header of the first request, and distributes the first request to a corresponding service side; the service side receives the second request, and performs permission verification on the second request according to the permission annotation marked by the target access interface of the second request and the identifier carried by the request header of the second request; and if the target access interface marks the intranet access annotation and the request header of the second request carries the extranet identifier, refusing the access of the second request to the target access interface. According to the invention, the request source is identified at the gateway side, and the judgment of the interface authority sinks to the service side, so that the calculation load of the gateway side is reduced, and the system response speed is improved; in addition, the corresponding annotation is added to the intranet access interface to realize authority control, and the control accuracy is improved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and more particularly, to an access right management method, system and related devices. Background Art

[0002] When an enterprise system develops business, it often encounters the situation that a certain interface cannot be exposed externally and can only be called between internal network services. Generally, requests pass through the gateway and are then distributed to the specific business side, and the calls between internal services do not pass through the external gateway.

[0003] If we want to control the access rights of the interface, the current common practice is to implement permission control through the gateway whitelist or microservice isolation. However, the overall cost performance is relatively low, which not only increases the system complexity, but also increases the call time consumption and consumes the gateway response rate.

[0004] It should be noted that the information disclosed in the above background art section is only used to strengthen the understanding of the background of the present invention, and thus may include information that does not constitute the prior art known to those of ordinary skill in the art. Summary of the Invention

[0005] In view of this, the present invention provides an access right management method, system and related devices, which identify the request source on the gateway side, sink the interface permission judgment to the business side, avoid the logical judgment on the gateway side, thereby simplifying the system configuration and improving the system response time.

[0006] According to one aspect of the present invention, there is provided an access right management method, including the following steps: the gateway side identifies the source of the received first request, adds an identifier representing the source of the first request to the request header of the first request, and distributes the first request to the corresponding business side; the business side receives a second request, and performs permission verification on the second request according to the permission annotation marked on the target access interface of the second request and the identifier carried in the request header of the second request; if the target access interface is marked with an internal network access annotation and the request header of the second request carries an external network identifier, the access of the second request to the target access interface is rejected.

[0007] In some embodiments, adding an identifier representing the source of the first request to the request header of the first request includes: if the first request comes from the external network, adding an external network identifier to the request header of the first request.

[0008] In some embodiments, the gateway side identifies the source of the first request according to the IP address or routing rule of the first request.

[0009] In some embodiments, the permission annotation is written based on aspect-oriented programming (AOP); the access permission management method further includes: marking a permission annotation on a method or class on the service side that needs to control access permissions.

[0010] In some embodiments, configuring a permission annotation on a method or class on the service side that needs to control access permissions includes: adding an intranet access annotation to a method or class that needs to restrict external network access; after the service side receives a request, intercepting the marked method or class through an AOP aspect, and performing permission verification based on the identifier carried in the request header of the request.

[0011] In some embodiments, the access permission management method further includes: if the target access interface is not marked with a permission annotation or the identifier carried in the request header of the second request matches the permission annotation marked on the target access interface, then release the second request.

[0012] According to another aspect of the present invention, there is provided an access permission management system for implementing the access permission management method as described in any of the above embodiments. The access permission management system includes: a gateway for identifying the source of a received first request, adding an identifier representing the source of the first request to the request header of the first request, and distributing the first request to the corresponding service side; a service server for receiving a second request, and performing permission verification on the second request according to the permission annotation marked on the target access interface of the second request and the identifier carried in the request header of the second request; if the target access interface is marked with an intranet access annotation and the request header of the second request carries an external network identifier, then reject the access of the second request to the target access interface.

[0013] According to another aspect of the present invention, there is provided an electronic device including: a processor; a memory in which executable instructions are stored; wherein, when the executable instructions are executed by the processor, the access permission management method as described in any of the above embodiments is implemented.

[0014] According to another aspect of the present invention, there is provided a computer-readable storage medium for storing a program, and when the program is executed by a processor, the access permission management method as described in any of the above embodiments is implemented.

[0015] According to another aspect of the present invention, there is provided a computer program product including a computer program, and when the computer program is executed by a processor, the access permission management method as described in any of the above embodiments is implemented.

[0016] The beneficial effects of the present invention compared with the prior art at least include:

[0017] The access permission management solution provided by the present invention identifies the request source on the gateway side, sinks the interface permission judgment to the service side, reduces the computing load on the gateway side, and avoids the logical judgment on the gateway side, thereby simplifying the system configuration and improving the system response speed. Distributing the processing of internal and external network access permissions to each service side can eliminate the systematic bottleneck processed by the gateway, and at the same time can meet the determination of internal and external network access permissions for interfaces between service sides, improving development efficiency. In addition, adding corresponding annotations to the internal network access interfaces to implement permission control realizes the permission control granularity at the interface dimension and improves the control accuracy.

[0018] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present invention, and are used together with the specification to explain the principles of the present invention. Obviously, the drawings described below are only some embodiments of the present invention, and those of ordinary skill in the art can obtain other drawings without creative efforts based on these drawings.

[0020] Figure 1 The schematic diagram of the steps of the access permission management method in the embodiment of the present invention is shown;

[0021] Figure 2 The schematic diagram of the architecture of the access permission management method in the embodiment of the present invention is shown;

[0022] Figure 3 The schematic diagram of the modules of the access permission management system in the embodiment of the present invention is shown;

[0023] Figure 4 The schematic diagram of the structure of the electronic device in the embodiment of the present invention is shown. DETAILED DESCRIPTION OF THE INVENTION

[0024] Example embodiments will now be described more fully with reference to the accompanying drawings. However, the example embodiments can be implemented in various forms and should not be construed as limited to the embodiments described herein. On the contrary, these embodiments are provided to make the present invention more complete and comprehensive, and to fully convey the concept of the example embodiments to those skilled in the art.

[0025] The accompanying drawings are only schematic illustrations of the present invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus the repeated descriptions thereof will be omitted. Some of the block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software form, or implemented in one or more hardware modules or integrated circuits, or implemented in different networks and / or processor devices and / or microcontroller devices.

[0026] In addition, the processes shown in the accompanying drawings are only exemplary illustrations and do not necessarily include all steps. For example, some steps can be decomposed, some steps can be combined or partially combined, and the actual execution order may be changed according to the actual situation. The "first", "second" and similar terms used in the specific description do not denote any order, quantity or importance, but are only used to distinguish different components.

[0027] It should be noted that, without conflict, the embodiments of the present invention and the features in different embodiments can be combined with each other.

[0028] Figure 1 Schematically showing the main steps of the access permission management method, Figure 2 Schematically showing the system architecture of the access permission management method. As shown in combination with Figure 1 and Figure 2 the access permission management method provided by the embodiments of the present invention includes:

[0029] S110, the gateway side identifies the source of the received first request, adds an identifier representing the source of the first request to the request header of the first request, and distributes the first request to the corresponding service side.

[0030] The first request can be initiated by the client 210. After receiving the first request, the gateway 220 can identify the source of the first request according to the IP address or routing rule of the first request. After identifying the source, the gateway 220 adds a corresponding identifier to the request header of the first request to identify the source of the first request. In some cases, when it is identified that the first request comes from the external network, an external network identifier can be added to the request header of the first request.

[0031] Specifically, the process of adding an external network identifier to the request header (header) of the received request on the gateway side is as follows:

[0032] @component

[0033] public class AuthFilter implements GlobalFilter,Ordered{

[0034] @Override

[0035] public Mono <void>filter(ServerWebExchange exchange, GatewayFilterChain chain) {

[0036] return chain.filter(

[0037] exchange.mutate().request(

[0038] exchange.getRequest().mutate().header("id", "").header("from", "public").build())

[0039] .build() );

[0041] }

[0042] @Override

[0043] public int getOrder() {

[0044] return 0;

[0045] }

[0046] }

[0047] In some cases, when it is recognized that the first request comes from the internal network, an internal network identifier can also be added to the request header of the first request. Here, the internal network refers to the local area network where the business servers (230a, 230b) are located, and the external network is the Internet.

[0048] S120, the business side receives the second request and performs permission verification on the second request according to the permission annotation marked on the target access interface of the second request and the identifier carried in the request header of the second request; S130, if the target access interface is marked with an internal network access annotation and the request header of the second request carries an external network identifier, the access of the second request to the target access interface is rejected.

[0049] Among them, the permission annotation is written based on aspect-oriented programming AOP; the access permission management method also includes: marking permission annotations on the methods or classes that need to control access permissions on the business side, including: adding internal network access annotations to the methods or classes that need to restrict external network access. After the business side receives a request, it intercepts the marked methods or classes through the AOP aspect and performs permission verification according to the identifier carried in the request header of the request. If it is an internal network request, business access is allowed. Using AOP and annotation methods to write internal and external network access permissions and implementing access permission control on methods or classes can reduce the business intrusion degree.

[0050] Specifically, the process of writing AOP and annotations for intranet and extranet access permission judgment is as follows:

[0051] @Aspect

[0052] @Component

[0053] @s1f4j

[0054] public class OnlyIntranetAccessAspect{

[0055] @Pointcut

[0056] ("@within(org.openmmlab.platform.common.annotation.onlyIntranetAccess)”)

[0057] public void onlyIntranetAccessonclass(){}

[0058] @Pointcut

[0059] ("@annotation(org.openmmlab.platform.common.annotation.onlyIntranetAccess)”)

[0060] public void onlyIntranetAccessOnMethed(){

[0061] }

[0062] @Before(value="onlyIntranetAccessOnMethed()||onlyIntranetAccessOnClass()”)

[0063] public void before(){

[0064] HttpServletRequest hsr=((ServletRequestAttributes)RequestContextHolder.getRequestAt String from=hsr.getHeader("from”);

[0065] It should be noted that there is a syntax error in the original text at "HttpServletRequest hsr=((ServletRequestAttributes)RequestContextHolder.getRequestAt String from=hsr.getHeader("from”);", which is an incomplete and incorrect statement. The translation is done based on the original text as much as possible while maintaining its integrity.if (!StringUtils.isEmpty(from) && "public".equals(from)) {

[0066] log.error("This api is only allowed to be invoked by intranet source");

[0067] throw new MMException

[0068] (ReturnEnum.C_NETWORK_INTERNET_ACCESS_NOT_ALLOWED_ERROR);

[0069] }

[0070] }

[0071] }

[0072] @Target({ElementType.METHOD})

[0073] @Retention(RetentionPolicy.RUNTIME)

[0074] @Documented

[0075] public @interface OnlyIntranetAccess {

[0076] }

[0077] The process of adding the corresponding annotation to the interface for intranet access includes:

[0078] @GetMapping(" / role / add")

[0079] @onlyIntranetAccess

[0080] public String onlyIntranetAccess() {

[0081] return "This interface is only allowed to be invoked by internal services";

[0082] }

[0083] In some cases, the access permission management method further includes: after the service side receives a request, it performs permission verification on the second request according to the permission annotation marked on the target access interface of the second request and the identifier carried in the request header of the second request. If the target access interface is not marked with a permission annotation or the identifier carried in the request header of the second request matches the permission annotation marked on the target access interface, the second request is released.

[0084] In summary, the access permission management solution provided by the present invention has the following advantages:

[0085] Efficiency improvement: The gateway side identifies the request source, sinks the permission judgment logic to the service side, avoids the logical judgment on the gateway side, reduces the computing load on the gateway side, and improves the system response speed;

[0086] Reducing business intrusion: Using the AOP and annotation methods to implement permission judgment control at the method level and class level;

[0087] Fine-grained control: Adding annotations to the interfaces or classes that need to control access can achieve permission control and improve the control accuracy.

[0088] The embodiment of the present invention also provides an access permission management system, which can be used to implement the access permission management method described in any of the above embodiments. The features and principles of the access permission management method described in any of the above embodiments can be applied to the following access permission management system embodiments. In the following access permission management system embodiments, the features and principles regarding access permission management that have been clarified will not be repeated.

[0089] Figure 3 Schematically showing the main modules of the access permission management system, referring to Figure 3 and combining Figure 1 and Figure 2 As shown, the access permission management system 300 provided by the embodiment of the present invention includes:

[0090] A gateway 220, configured to identify the source of the received first request, add an identifier representing the source of the first request to the request header of the first request, and distribute the first request to the corresponding service side;

[0091] Service servers (230a, 230b), configured to receive a second request, and perform permission verification on the second request according to the permission annotation marked on the target access interface of the second request and the identifier carried in the request header of the second request; if the target access interface is marked with an intranet access annotation and the request header of the second request carries an extranet identifier, the access of the second request to the target access interface is rejected.

[0092] Among them, there may be multiple service servers, not limited to 230a and 230b shown in the figure.

[0093] The access permission management system 300 of the present invention identifies the request source on the gateway side, sinks the interface permission judgment to the service side, reduces the computing load on the gateway side, avoids the logical judgment on the gateway side, and improves the system response speed; distributes the processing of internal and external network access permissions to each service side, can eliminate the systematic bottleneck processed by the gateway, and at the same time can meet the determination of internal and external network access permissions of interfaces between service sides, improving the development efficiency; uses AOP and annotation methods to write internal and external network access permissions, realizes control permission judgment at the method level and class level, and reduces the business intrusion degree; in addition, adds corresponding annotations to the internal network access interface to implement permission control, realizes the permission control granularity at the interface dimension, and improves the control accuracy.

[0094] The embodiment of the present invention also provides an electronic device, including a processor and a memory. An executable instruction is stored in the memory. When the executable instruction is executed by the processor, the access permission management method described in any of the above embodiments is implemented.

[0095] The electronic device of the present invention can achieve: identifying the request source on the gateway side, sinking the interface permission judgment to the service side, reducing the computing load on the gateway side, avoiding the logical judgment on the gateway side, and improving the system response speed; distributing the processing of internal and external network access permissions to each service side, can eliminate the systematic bottleneck processed by the gateway, and at the same time can meet the determination of internal and external network access permissions of interfaces between service sides, improving the development efficiency; uses AOP and annotation methods to write internal and external network access permissions, realizes control permission judgment at the method level and class level, and reduces the business intrusion degree; in addition, adds corresponding annotations to the internal network access interface to implement permission control, realizes the permission control granularity at the interface dimension, and improves the control accuracy.

[0096] Figure 4 Schematically shows the structure of the electronic device. Referring to Figure 4 As shown, the electronic device 400 is presented in the form of a general computing device. The components of the electronic device 400 include but are not limited to: at least one processing unit 410, at least one storage unit 420, a bus 430 connecting different platform components (including the storage unit 420 and the processing unit 410), etc.

[0097] The storage unit 420 stores program code, and the program code can be executed by the processing unit 410, so that the processing unit 410 executes the steps of the access permission management method described in any of the above embodiments.

[0098] The storage unit 420 may include a readable medium in the form of a volatile storage unit, such as a random access storage unit (RAM) and / or a cache storage unit, and may further include a read-only storage unit (ROM).

[0099] The storage unit 420 may also include a program / utilities having one or more program modules. Such program modules include, but are not limited to: an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment.

[0100] The bus 430 may represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus structures.

[0101] The electronic device 400 may also communicate with one or more external devices, which may be one or more of devices such as a keyboard, a pointing device, a Bluetooth device, etc. These external devices enable a user to interact with the electronic device 400. The electronic device 400 can also communicate with one or more other computing devices, and the shown computing devices include a router, a modem. Such communication may be through an input / output (I / O) interface. Also, the electronic device 400 may communicate with one or more networks (such as a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) through a network adapter. The network adapter may communicate with other modules of the electronic device 400 through the bus 430. It should be understood that although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 400, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage platforms, etc.

[0102] An embodiment of the present invention also provides a computer-readable storage medium for storing a program, which when executed implements the access right management method described in any of the above embodiments.

[0103] When the storage medium of the present invention is executed by a processor, it can be realized that: by identifying the request source on the gateway side, sinking the interface permission judgment to the service side, reducing the computing load on the gateway side, avoiding the logical judgment on the gateway side, and improving the system response speed; distributing the processing of the internal and external network access rights to each service side can eliminate the systematic bottleneck processed by the gateway, and at the same time can meet the determination of the internal and external network access rights of the interface between service sides, improving the development efficiency; using AOP and annotation methods to write the internal and external network access rights, realizing the control permission judgment at the method level and class level, reducing the business intrusion degree; in addition, adding corresponding annotations to the internal network access interface to implement permission control, realizing the permission control granularity at the interface dimension, and improving the control accuracy.

[0104] The storage medium can be a portable compact disc read-only memory (CD-ROM) and include program code, and can run on a terminal device such as a personal computer. However, the storage medium of the present invention is not limited thereto, and it can be any tangible medium that contains or stores a program, and the program can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0105] The storage medium can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the readable storage medium include, but are not limited to: an electrical connection having one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0106] The readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, which carries the readable program code. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The readable signal medium can also be any readable medium other than the readable storage medium, and the readable medium can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the readable signal medium can be transmitted by any appropriate medium, including but not limited to wireless, wired, optical fiber cable, RF, etc., or any suitable combination of the above.

[0107] The program code for performing the operations of the present invention can be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, C++, etc., and also including conventional procedural programming languages such as the C language or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, executed as an independent software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user's computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device, for example, by connecting through the Internet using an Internet service provider.

[0108] An embodiment of the present invention further provides a computer program product, including a computer program, which implements the access right management method described in any of the above embodiments when executed by a processor.

[0109] When the computer program product of the present invention runs, it can achieve the following: by identifying the request source on the gateway side, sinking the interface permission judgment to the service side, reducing the computing load on the gateway side, avoiding the logical judgment on the gateway side, and improving the system response speed; distributing the processing of internal and external network access rights to each service side can eliminate the systematic bottleneck processed by the gateway, and at the same time can meet the determination of the internal and external network access rights of the interface between service sides, improving the development efficiency; using AOP and annotation methods to write the internal and external network access rights, implementing the control permission judgment at the method level and class level, reducing the business intrusion degree; in addition, adding corresponding annotations to the internal network access interface to implement permission control, achieving the permission control granularity at the interface dimension and improving the control accuracy.

[0110] The above content is a further detailed description of the present invention in combination with specific preferred embodiments. It cannot be determined that the specific implementation of the present invention is only limited to these descriptions. For those of ordinary skill in the technical field to which the present invention belongs, without departing from the concept of the present invention, several simple deductions or substitutions can be made, which should all be regarded as belonging to the protection scope of the present invention.< / void>

Claims

1. A method for access right management, characterized in that, It includes the following steps: The gateway side identifies the source of the received first request, adds an identifier representing the source of the first request to the request header of the first request, and distributes the first request to the corresponding service side; The service side receives the second request and performs permission verification on the second request according to the permission annotation marked on the target access interface of the second request and the identifier carried in the request header of the second request; If the target access interface is marked with an intranet access annotation and the request header of the second request carries an extranet identifier, the access of the second request to the target access interface is rejected.

2. The access right management method according to claim 1, characterized in that, Adding an identifier representing the source of the first request to the request header of the first request includes: If the first request comes from the extranet, an extranet identifier is added to the request header of the first request.

3. The access right management method according to claim 1, characterized in that The gateway side identifies the source of the first request according to the IP address or routing rule of the first request.

4. The access right management method according to claim 1, characterized in that, The permission annotation is written based on aspect-oriented programming (AOP); The access permission management method further includes: marking a permission annotation on a method or class that needs to control access permission on the service side.

5. The access right management method according to claim 4, characterized in that, Configuring a permission annotation on a method or class that needs to control access permission on the service side includes: adding an intranet access annotation to a method or class that needs to restrict extranet access; After receiving the request, the service side intercepts the marked method or class through an AOP aspect and performs permission verification according to the identifier carried in the request header of the request.

6. The access right management method according to claim 1, wherein It also includes: If the target access interface is not marked with a permission annotation or the identifier carried in the request header of the second request matches the permission annotation marked on the target access interface, the second request is released.

7. An access right management system for implementing the access right management method according to any one of claims 1 to 6, characterized in that, The access permission management system includes: A gateway, which is used to identify the source of the received first request, add an identifier representing the source of the first request to the request header of the first request, and distribute the first request to the corresponding service side; A service server, which is used to receive the second request, perform permission verification on the second request according to the permission annotation marked on the target access interface of the second request and the identifier carried in the request header of the second request; if the target access interface is marked with an intranet access annotation and the request header of the second request carries an extranet identifier, the access of the second request to the target access interface is rejected.

8. An electronic device, characterized in that, It includes: A processor; A memory, in which executable instructions are stored; Wherein, when the executable instructions are executed by the processor, the access permission management method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium for storing a program, characterized in that, When the program is executed by the processor, the access permission management method according to any one of claims 1 to 6 is implemented.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, the access permission management method according to any one of claims 1 to 6 is implemented.

Images