Project function permission management method and device, electronic equipment and storage medium

Abstract

The application relates to the technical field of permission management, in particular to a project function permission management method and device, electronic equipment and a storage medium, wherein the method comprises the following steps: logging in a unified authentication server by using an sdk software package encapsulated by a unified authentication end through an API; judging whether a login identifier of a current user exists based on a shiro interceptor of a preset open source security framework; and when the login identifier exists, responding to a function permission access operation of the current user on a target project. Therefore, the problems that the authorization management has a high cost or cannot customize functions in the related art are solved, the unified authentication and the shiro framework are combined to perform user authentication and permission verification functions, the shortcomings of the two are effectively made up, the repeated construction work of authentication, permission tables and the like is saved, some permission controls can be customized, and good assistance functions are provided for web server authentication and authorization.

Description

Technical Field

[0001] This application relates to the field of access control technology, and in particular to a method, apparatus, electronic device and storage medium for managing the functional access rights of a project. Background Technology

[0002] Projects requiring identity authentication and authorization management might consider using the Shiro framework, but large enterprise projects typically have a unified authentication framework. Therefore, integration of the two is necessary. Unified authentication generally provides an authentication API (Application Programming Interface) / URL (Uniform Resource Locator). Taking JWT (JSON Web Token) as an example, it generally includes modules such as JWT validation, application token management, authentication and authorization, and application caching. The Shiro framework typically manages authentication through modules such as subject, realm, interceptors, and SecurityManager.

[0003] However, the Shiro framework generally requires users to create their own user, role, and resource tables, and use Shiro's connectors, Realm, and other modules to complete authentication and authorization, which is costly. In contrast, unified authentication usually provides a set of user, role, and resource tables, and the system only needs to connect the front-end and back-end APIs to use it, but it cannot customize some functions, such as button authorization, which urgently needs to be addressed.

[0004] Application content

[0005] This application provides a method, apparatus, electronic device, and storage medium for managing project function permissions, in order to solve the problems of high cost or inability to customize functions in related technologies for authorization management. It integrates unified authentication and the Shiro framework to perform user authentication and permission verification functions, effectively making up for the shortcomings of both. It can save the repetitive construction work of authentication and permission tables, and can also customize some permission controls, providing a good assist function for web server authentication and authorization.

[0006] The first aspect of this application provides a method for managing the functional permissions of a project, including the following steps:

[0007] Log in to the unified authentication server via the unified authentication terminal's encapsulated SDK (Software Development Kit) software package through the API;

[0008] Based on a pre-defined open-source security framework, the Shiro interceptor determines whether the current user's login identifier exists; and

[0009] When the login identifier exists, respond to the current user's access permission operation for the target project.

[0010] Optionally, before responding to the current user's access permission operation for the target project, the following steps are included:

[0011] The unified authentication framework of the unified authentication server is invoked to verify whether the login identifier meets the validity conditions;

[0012] After verifying the validity of the login identifier, the first permission information of the current user is obtained based on the preset open-source security framework;

[0013] The first permission information is verified according to the Shiro annotation in the preset open-source security framework, so that the function permission access operation is responded to based on the verified first permission information.

[0014] Optionally, the step of calling the unified authentication framework of the unified authentication server to verify whether the login identifier meets the validity conditions includes:

[0015] In the Shiro interceptor or in the preset interceptor, the unified authentication verification API is called to verify whether the login identifier meets the validity conditions.

[0016] Optionally, it also includes:

[0017] If the login identifier does not exist, obtain the current user's identity identifier;

[0018] The system verifies the second permission information of the current user based on the current user's identity identifier, and responds to the corresponding function permission access operation of the current user based on the second permission information after successful verification.

[0019] Optionally, the default open-source security framework is the Shiro framework.

[0020] A second aspect of this application provides a device for managing the functional permissions of a project, comprising:

[0021] The login module is used to log in to the unified authentication server via API using the SDK package encapsulated by the unified authentication terminal;

[0022] The judgment module is used to determine whether the current user's login identifier exists based on the Shiro interceptor within a pre-defined open-source security framework; and

[0023] The response module is used to respond to the current user's access permission operation for the target project when the login identifier exists.

[0024] Optionally, before responding to the current user's access permission operation for the target project, the response module is specifically used for:

[0025] The unified authentication framework of the unified authentication server is invoked to verify whether the login identifier meets the validity conditions;

[0026] After verifying the validity of the login identifier, the first permission information of the current user is obtained based on the preset open-source security framework;

[0027] The first permission information is verified according to the Shiro annotation in the preset open-source security framework, so that the function permission access operation is responded to based on the verified first permission information.

[0028] Optionally, the response module is specifically used for:

[0029] In the Shiro interceptor or in the preset interceptor, the unified authentication verification API is called to verify whether the login identifier meets the validity conditions.

[0030] Optionally, it also includes:

[0031] The acquisition module is used to acquire the identity identifier of the current user when the login identifier does not exist;

[0032] The verification module is used to verify the second permission information of the current user based on the current user's identity identifier, and respond to the corresponding function permission access operation of the current user according to the second permission information after successful verification.

[0033] Optionally, the default open-source security framework is the Shiro framework.

[0034] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the function permission management method for items as described in the above embodiments.

[0035] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the above-described method for managing the functionality and permissions of an item.

[0036] Therefore, the unified authentication server can be accessed via the unified authentication SDK package through the API. It then uses a Shiro interceptor based on a pre-defined open-source security framework to determine if a login identifier exists for the current user. If such an identifier exists, it responds to the user's access permissions for the target project. This approach, combining unified authentication and the Shiro framework for user authentication and permission verification, effectively compensates for the shortcomings of both. It saves on the redundant construction of authentication and permission tables and allows for customized permission controls. It provides excellent assistance for web server authentication and authorization.

[0037] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0038] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0039] Figure 1 This is a flowchart illustrating a method for managing project functionality permissions according to an embodiment of this application.

[0040] Figure 2 This is a flowchart of a method for managing the functional permissions of a project according to an embodiment of this application;

[0041] Figure 3 This is an example diagram of a function permission management device for a project according to an embodiment of this application;

[0042] Figure 4 This is an example diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0043] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0044] The following description, with reference to the accompanying drawings, outlines a method, apparatus, electronic device, and storage medium for managing project functionality permissions according to embodiments of this application. Addressing the issues of high costs or lack of customizable functionality in authorization management within the related technologies mentioned in the background section, this application provides a method for managing project functionality permissions. In this method, the user can log in to the unified authentication server via an API using an SDK package encapsulated by the unified authentication endpoint. Based on a pre-defined Shiro interceptor within the open-source security framework, the method determines whether a login identifier for the current user exists. If a login identifier exists, the method responds to the current user's access to the target project's functionality permissions. This integrates unified authentication and the Shiro framework for user authentication and permission verification, effectively overcoming the shortcomings of both. It saves on the repetitive construction of authentication and permission tables and allows for customizable permission controls. It also provides excellent assistance for web server authentication and authorization.

[0045] Specifically, Figure 1 This is a flowchart illustrating a method for managing project function permissions provided in an embodiment of this application.

[0046] like Figure 1 As shown, the function permission management method of this project includes the following steps:

[0047] In step S101, the user logs into the unified authentication server using the SDK package encapsulated by the unified authentication terminal via the API.

[0048] APIs are predefined interfaces (such as functions, HTTP (Hypertext Transfer Protocol) interfaces), or refer to the conventions for connecting different components of a software system.

[0049] It should be understood that different projects use different unified authentication frameworks, which generally include a front-end SDK page-level framework and a back-end SDK attachment such as a login interceptor. The login module uses a unified authentication mechanism to verify user login, and can store user login identifiers and other information in a user-defined token after successful login.

[0050] In step S102, the Shiro interceptor based on the preset open-source security framework determines whether the current user's login identifier exists.

[0051] Optionally, in some embodiments, the default open-source security framework is the Shiro framework.

[0052] It should be understood that the Shiro interceptor may pre-store the user's login identifier. After the user logs into the unified authentication server, the Shiro interceptor can determine whether the user's login token exists. If it does not exist, it will jump to the unified authentication component for permission verification.

[0053] In step S103, if a login identifier exists, the system responds to the current user's access permission operation for the target item.

[0054] Optionally, in some embodiments, before responding to the current user's access operation for the target project, the process includes: calling the unified authentication framework of the unified authentication server to verify whether the login identifier meets the validity conditions; after verifying the validity of the login identifier, obtaining the current user's first permission information based on a preset open-source security framework; verifying the first permission information according to the Shiro annotation in the preset open-source security framework, so that the access operation for the function permission is responded to based on the verified first permission information.

[0055] In some embodiments, the unified authentication framework of the unified authentication server is invoked to verify whether the login identifier meets the validity conditions. This includes: in the Shiro interceptor or a preset interceptor, the unified authentication verification API is invoked to verify whether the login identifier meets the validity conditions.

[0056] Specifically, if the token exists (i.e., the current user's login identifier exists), this application embodiment can call the unified authentication verification API in the Shiro interceptor or in a custom interceptor to verify the token's validity. After verifying the login identifier's validity, the user's permission information, i.e., the first permission information, is obtained from the Shiro realm. Subsequently, the SecurityManager module will perform permission verification based on Shiro annotations, enabling the response to functional permission access operations based on the verified first permission information.

[0057] It should be noted that the token is generated when the client frequently requests data from the server. The server then frequently queries the database for the username and password, compares them, determines whether the username and password are correct, and provides corresponding prompts. If the verification fails, please try to verify again.

[0058] Optionally, in some embodiments, the method further includes: obtaining the current user's identity identifier when no login identifier exists; verifying the current user's second permission information based on the current user's identity identifier; and responding to the current user's corresponding function permission access operation based on the verified second permission information.

[0059] It should be understood that when a user logs in for the first time, there is no login identifier. Therefore, in this embodiment of the application, the current user's identity identifier can be obtained when there is no login identifier. If the user's identity identifier is permission information with functional access permission operation, i.e., second permission information, the corresponding functional access permission operation of the current user can be responded to after the second permission information is successfully verified, allowing the user to access.

[0060] Therefore, by integrating unified authentication and the Shiro framework for user authentication and permission verification, the shortcomings of both approaches are effectively overcome. This not only saves the work of repeatedly building authentication and permission tables, but also allows for the customization of some permission controls; it provides excellent assistance for web server authentication and authorization.

[0061] To enable those skilled in the art to further understand the project function permission management method of the embodiments of this application, the following detailed description is provided in conjunction with specific embodiments.

[0062] Specifically, such as Figure 2 As shown, the function permission management method of this project includes the following steps:

[0063] S201, Unified Authentication Frontend SDK.

[0064] S202, Unified Authentication Login Backend.

[0065] S203, the Shiro interceptor checks if a login identifier exists. If it does, proceed to step S204; otherwise, proceed to step S201.

[0066] S204, invoke unified authentication to verify the validity of the token.

[0067] S205, Shiro annotation permission verification.

[0068] S206, Application System Access.

[0069] The user login authentication module uses different unified authentication frameworks across different projects, typically including a front-end SDK page-level framework and a back-end SDK attachment such as a login interceptor. The login module uses a unified authentication mechanism to verify user login, storing user login identifiers and other information in a user-defined token upon successful login. The Shiro interceptor checks if the user login token exists; if not, it redirects to the unified authentication component for permission verification.

[0070] Token validity verification: In the Shiro interceptor or a custom interceptor, call the unified authentication verification API to verify the token validity.

[0071] Shiro annotation-based authentication: User permission information is obtained from the Shiro realm, and the SecurityManager module will then perform permission authentication based on the Shiro annotations.

[0072] The functional permission management method for projects proposed in this application allows users to log in to the unified authentication server via an API using an SDK package encapsulated by the unified authentication client. Based on a pre-defined Shiro interceptor within the open-source security framework, the method determines whether a login identifier for the current user exists. If a login identifier exists, it responds to the current user's access permission operation for the target project. This method integrates unified authentication and the Shiro framework for user authentication and permission verification, effectively overcoming the shortcomings of both. It saves on the repetitive construction of authentication and permission tables and allows for customized permission controls. It provides excellent assistance for web server authentication and authorization.

[0073] Next, the functional permission management device for the project proposed according to the embodiments of this application is described with reference to the accompanying drawings.

[0074] Figure 3 This is a block diagram of a function permission management device for an embodiment of this application.

[0075] like Figure 3 As shown, the functional permission management device 10 of this project includes: a login module 100, a judgment module 200, and a response module 300.

[0076] The login module 100 is used to log in to the unified authentication server via API using the SDK package encapsulated by the unified authentication terminal.

[0077] The judgment module 200 is used by the Shiro interceptor based on a preset open-source security framework to determine whether the current user's login identifier exists; and

[0078] The response module 300 is used to respond to the current user's access permission operation for the target project when a login identifier exists.

[0079] Optionally, before responding to the current user's access permission operation for the target project, the response module 300 is specifically used for:

[0080] The unified authentication framework of the unified authentication server is invoked to verify whether the login identifier meets the valid conditions;

[0081] After verifying the validity of the login identifier, the system obtains the current user's first-level permission information based on a preset open-source security framework.

[0082] The system verifies the first permission information based on the Shiro annotation in the pre-defined open-source security framework, enabling the system to respond with access permission operations based on the verified first permission information.

[0083] Optionally, the response module 300 is specifically used for:

[0084] In the Shiro interceptor or a preset interceptor, call the unified authentication API to verify whether the login identifier meets the valid conditions.

[0085] Optionally, it also includes:

[0086] The acquisition module is used to obtain the identity identifier of the current user when no login identifier exists;

[0087] The verification module is used to verify the second permission information of the current user based on the current user's identity identifier, and respond to the current user's corresponding function permission access operation based on the second permission information after successful verification.

[0088] Optionally, the default open-source security framework is the Shiro framework.

[0089] It should be noted that the foregoing explanation of the project function permission management method embodiment also applies to the project function permission management device of this embodiment, and will not be repeated here.

[0090] The functional permission management device for a project proposed in this application can log in to the unified authentication server via an API using the SDK package encapsulated by the unified authentication terminal. Based on a preset open-source security framework's Shiro interceptor, it determines whether a login identifier for the current user exists. If a login identifier exists, it responds to the current user's access operation for the target project's functional permissions. Thus, it integrates unified authentication and the Shiro framework for user authentication and permission verification, effectively compensating for the shortcomings of both. This saves on the repetitive construction of authentication and permission tables and allows for customized permission controls. It provides excellent assistance for web server authentication and authorization.

[0091] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include:

[0092] The memory 401, the processor 402, and the computer program stored on the memory 401 and capable of running on the processor 402.

[0093] When processor 402 executes the program, it implements the project function permission management method provided in the above embodiments.

[0094] Furthermore, electronic devices also include:

[0095] Communication interface 403 is used for communication between memory 401 and processor 402.

[0096] The memory 401 is used to store computer programs that can run on the processor 402.

[0097] The memory 401 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0098] If the memory 401, processor 402, and communication interface 403 are implemented independently, then the communication interface 403, memory 401, and processor 402 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0099] Optionally, in a specific implementation, if the memory 401, processor 402, and communication interface 403 are integrated on a single chip, then the memory 401, processor 402, and communication interface 403 can communicate with each other through an internal interface.

[0100] Processor 402 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0101] This embodiment also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described method for managing the functional permissions of the project.

[0102] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0103] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0104] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0105] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0106] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0107] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0108] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0109] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A method of managing functional authority of a project, characterized by, The method comprises the following steps: logging in a unified authentication server by using an sdk software package encapsulated by a unified authentication terminal through an API; judging whether a login identifier of a current user exists based on a shiro interceptor of a preset open source security framework; and responding to a function permission access operation of the current user on a target project when the login identifier exists; before responding to the function permission access operation of the current user on the target project, comprising: calling a unified authentication framework of the unified authentication server to verify whether the login identifier meets valid conditions; after verifying that the login identifier is valid, acquiring first permission information of the current user based on the preset open source security framework; verifying the first permission information according to a shiro annotation in the preset open source security framework, so that the function permission access operation is responded based on the verified first permission information; the calling of the unified authentication framework of the unified authentication server to verify whether the login identifier meets valid conditions comprises: in the shiro interceptor, calling a verification API of the unified authentication to verify whether the login identifier meets valid conditions.

2. The method of claim 1, wherein, Further comprising: when the login identifier does not exist, acquiring an identity identifier of the current user; verifying second permission information of the current user based on the identity identifier of the current user, and responding to a corresponding function permission access operation of the current user according to the second permission information after the verification is successful.

3. The method of claim 1 or 2, wherein The preset open source security framework is a shiro framework.

4. An apparatus for managing a function authority of a project, characterized by comprising: Comprise: a login module configured to log in a unified authentication server by using an sdk software package encapsulated by a unified authentication terminal through an API; a judgment module configured to judge whether a login identifier of a current user exists based on a shiro interceptor of a preset open source security framework; and a response module configured to respond to a function permission access operation of the current user on a target project when the login identifier exists. Before responding to the function permission access operation of the current user on the target project, the response module is specifically configured to: call a unified authentication framework of the unified authentication server to verify whether the login identifier meets valid conditions; after verifying that the login identifier is valid, acquire first permission information of the current user based on the preset open source security framework; verify the first permission information according to a shiro annotation in the preset open source security framework, so that the function permission access operation is responded based on the verified first permission information; the response module is configured to call a unified authentication framework of the unified authentication server to verify whether the login identifier meets valid conditions, comprising: in the shiro interceptor, call a verification API of the unified authentication to verify whether the login identifier meets valid conditions.

5. An electronic device, comprising: Comprise: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the function permission management method of the project according to any one of claims 1-3.

6. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the function permission management method of the project according to any one of claims 1-3.

Images