Permission verification method, device, equipment, medium and program product
By introducing a comparison mechanism between target permission data and identity permission data in permission verification, the problem of inefficient permission verification in traditional technology is solved, and fast and accurate permission judgment is achieved.
Patent Information
- Application Number
- CN202411717233.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-27
- Publication Date
- 2025-02-28
AI Technical Summary
In traditional technology, the layer-by-layer comparison mechanism of user permissions leads to low permission verification efficiency, requiring multiple comparisons, which is inefficient.
By obtaining the user's access request, determine the target permission data required by the object to be accessed and the user's identity permission data. When the identity permission data contains the target permission data, determine whether the user has the permission to perform the operation, and realize a comparison to determine the permissions.
It improves the efficiency of permission verification, reduces the need for multiple step-by-step verification, and significantly improves verification speed and accuracy.
Smart Images
Figure 00000000_0000_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of data security technology, and in particular to a permission verification method, device, equipment, medium and program product. Background Art
[0002] With the development of science and technology, the amount of data in the system is getting larger and larger, and security issues such as data leakage caused by large amounts of data are also increasing. Therefore, the need to ensure data security is becoming increasingly prominent.
[0003] In traditional technologies, a user permission comparison mechanism is usually used to compare the user's permission information with the permission requirements of each level of the target object to be accessed (such as database tables, records, files, services, etc.). This means that when the user accesses a target object, the service provider needs to perform multiple permission comparisons, which reduces the efficiency of permission verification. Summary of the invention
[0004] Based on this, it is necessary to provide a permission verification method, device, equipment, medium and program product that can improve the efficiency of permission verification in response to the above technical problems.
[0005] In a first aspect, the present application provides a method for verifying permissions, including:
[0006] Obtaining an access request sent by a user, the access request including an object to be accessed, a type of operation to be performed on the object to be accessed, and identity data of the user;
[0007] In response to the access request, determining target permission data of the type of operation required to access the object to be accessed; the target permission data includes target access objects of various levels required to access the object to be accessed; and
[0008] Determine the identity authority data granted to the user based on the user's identity data; the identity authority data includes the authority access object and the authority operation type corresponding to the authority access object;
[0009] In the case where the identity authority data contains the target authority data, it is determined that the user has the authority to perform the operation corresponding to the type of operation to be performed on the object to be accessed.
[0010] In one of the embodiments, the target permission data and the identity permission data are presented in the form of a permission link; the target permission data also includes the hierarchical relationship between target access objects at each level; correspondingly, the identity permission data also includes the hierarchical relationship between permission access objects.
[0011] In one of the embodiments, the situation where the identity permission data contains the target permission data includes: the permission link of the target permission data is a sub-link of the permission link of the identity permission data.
[0012] In one of the embodiments, the identity authority data of the user is determined based on the identity data of the user, including: determining the role groups to which the identity data belongs; obtaining the role authority data of each role group, the role authority data including the authority access objects and authority operation types granted to each role member in the role group; and determining the identity authority data of the user based on the role authority data corresponding to each role group.
[0013] In one of the embodiments, the method also includes: when the role permission data of any role group needs to be changed, obtaining the role members and the latest role permission data of the corresponding role group according to the change content; obtaining the identity permission data of each role member according to the latest role permission data; performing conflict verification on the identity permission data of each role member; and when the conflict verification passes, updating the role permission data of the corresponding role group with the latest role permission data.
[0014] In one of the embodiments, before obtaining the target permission data in response to the access request, the method further includes: filtering the object to be accessed of the access request and the type of operation to be performed corresponding to the object to be accessed based on a preset sandbox filtering rule.
[0015] In a second aspect, the present application also provides a permission verification device, including:
[0016] A first acquisition module is used to acquire an access request sent by a user, where the access request includes an object to be accessed, a type of operation to be performed corresponding to the object to be accessed, and identity data of the user;
[0017] A first determination module is used to determine, in response to an access request, target authority data of a type of operation required to access the object to be accessed; the target authority data includes target access objects of various levels that need to be passed through to access the object to be accessed; and
[0018] The second determination module determines the identity authority data granted to the user according to the identity data of the user; the identity authority data includes the authority access object and the authority operation type corresponding to the authority access object;
[0019] The third determination module determines whether the user has the authority to perform the operation corresponding to the type of operation to be performed on the object to be accessed when the identity authority data contains the target authority data.
[0020] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:
[0021] Obtaining an access request sent by a user, the access request including an object to be accessed, a type of operation to be performed on the object to be accessed, and identity data of the user;
[0022] In response to the access request, determining target permission data of the type of operation required to access the object to be accessed; the target permission data includes target access objects of various levels required to access the object to be accessed; and
[0023] Determine the identity authority data granted to the user based on the user's identity data; the identity authority data includes the authority access object and the authority operation type corresponding to the authority access object;
[0024] In the case where the identity authority data contains the target authority data, it is determined that the user has the authority to perform the operation corresponding to the type of operation to be performed on the object to be accessed.
[0025] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the following steps are implemented:
[0026] Obtaining an access request sent by a user, the access request including an object to be accessed, a type of operation to be performed on the object to be accessed, and identity data of the user;
[0027] In response to the access request, determining target permission data of the type of operation required to access the object to be accessed; the target permission data includes target access objects of various levels required to access the object to be accessed; and
[0028] Determine the identity authority data granted to the user based on the user's identity data; the identity authority data includes the authority access object and the authority operation type corresponding to the authority access object;
[0029] In the case where the identity authority data contains the target authority data, it is determined that the user has the authority to perform the operation corresponding to the type of operation to be performed on the object to be accessed.
[0030] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:
[0031] Obtaining an access request sent by a user, the access request including an object to be accessed, a type of operation to be performed on the object to be accessed, and identity data of the user;
[0032] In response to the access request, determining target permission data of the type of operation required to access the object to be accessed; the target permission data includes target access objects of various levels required to access the object to be accessed; and
[0033] Determine the identity authority data granted to the user based on the user's identity data; the identity authority data includes the authority access object and the authority operation type corresponding to the authority access object;
[0034] In the case where the identity authority data contains the target authority data, it is determined that the user has the authority to perform the operation corresponding to the type of operation to be performed on the object to be accessed.
[0035] The above-mentioned permission verification method, device, equipment, medium and program product, by introducing target permission data, can integrate the data of target access objects of various levels that the object to be accessed needs to pass through into a single target permission data; by determining the target permission data under the type of operation to be performed required to access the object to be accessed, and determining the identity permission data granted to the user based on the user's identity data, so that when the identity permission data contains the target permission data, it is determined that the user has the permission to perform the operation corresponding to the type of operation to be performed on the object to be accessed. The above-mentioned process only requires one comparison to determine whether the user has the permission for the corresponding operation, without the need for multiple level-by-level verifications, thereby improving the verification efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0036] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments of the present application or the related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.
[0037] Figure 1 An application environment diagram of a permission verification method in an embodiment;
[0038] Figure 2A A flowchart of a method for verifying authority in one embodiment is shown;
[0039] Figure 2B A schematic diagram of target authority data in the form of an authority chain diagram in one embodiment;
[0040] Figure 2C A schematic diagram of identity authority data in the form of an authority chain diagram in one embodiment;
[0041] Figure 3 A flowchart of steps for determining identity authority data in one embodiment;
[0042] Figure 4 A flowchart of a method for verifying authority in another embodiment;
[0043] Figure 5 It is a structural block diagram of a permission verification device in one embodiment;
[0044] Figure 6 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION
[0045] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.
[0046] The permission verification method provided in the embodiment of the present application can be applied to Figure 1 In the application environment shown, the user side 110 communicates with the service side 120 through the network. The data storage system can store the data that the service side 120 needs to process. The data storage system can be integrated on the service side 120, or it can be placed on the cloud or other network servers. The user side 110 can be, but is not limited to, various personal computers, laptops, smart phones, and tablet computers. The service side 120 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud computing services.
[0047] In an exemplary embodiment, Figure 2A As shown, a permission verification method is provided, which is applied to Figure 1 Taking the service provider 120 in the example as an example, the permission verification method includes the following steps:
[0048] S210 , obtaining an access request sent by the user 110 , where the access request includes an object to be accessed, a type of operation to be performed corresponding to the object to be accessed, and identity data of the user 110 .
[0049] Among them, the user side 110 can send access requests to the service side 120 through ad hoc queries, dashboard / question queries, downloading data, etc. in the user side interface. Ad hoc queries refer to users creating custom queries according to their needs to obtain real-time data and answers. Ad hoc queries can include query editor query methods and native query methods. Dashboard / question queries refer to users submitting query requests to the system through the dashboard interface or specific question query functions. This application does not impose any restrictions on the specific implementation of access requests.
[0050] The object to be accessed can be understood as the data resource to be accessed, and the type to be operated can be understood as the operation or function to be performed on the object to be accessed. The number of objects to be accessed can be any number, and the number of types to be operated can be any number. The type to be operated can include at least one of viewing, reading, editing, downloading, sharing, creating queries, etc. The type of the object to be accessed can include at least one of database, mode, table, field, collection, question, dashboard, etc. The database can be understood as an ordered collection of structured information or data; the mode is used to define the structure, type and relationship of data in the database; the table is the basic unit for storing data in the database, organizing data in the form of rows and columns, each row represents a record, and each column represents a field; the field is a column in the database table, which is used to store a specific type of data, and each field has a name and data type, which is used to describe the characteristics and format of the data stored in the field; the collection can be understood as a data structure or data model for storing and organizing related data; the question can be understood as a defined data query or analysis request, and the access to the question can be controlled by permission through the collection; the dashboard is a type of visual application for data management, which usually contains multiple icons or components to display data and analysis results of different dimensions.
[0051] The identity data of the user 110 can be understood as a set of relevant information used to characterize the identity of the user 110, and these sets of relevant information together constitute the unique identity of the user 110 in the service provider 120. The identity data of the user 110 can be at least one of an account number, a mobile phone number, a user name, and identity verification information, and the present application does not impose any limitation on the specific content of the identity data.
[0052] S220 , in response to the access request, determining target authority data of the type of operation to be performed required for accessing the object to be accessed; the target authority data includes target access objects of various levels that need to be passed through in order to access the object to be accessed.
[0053] Among them, the target permission data also includes the type of operation to be performed corresponding to the object to be accessed. It is understandable that when accessing a certain object to be accessed, it is usually necessary to pass through target access objects of various levels. Exemplarily, the access object is database table t3, and the type of operation to be performed is view. Then, the target access objects of various levels that need to be passed through to access database table A3 are, for example, "database D1-mode S1-table t3" in sequence. Correspondingly, the target permission data can be "database D1-mode S1-table t3-view".
[0054] In an optional embodiment, the service provider 120 may configure global permission data based on the hierarchical relationship of all access objects. In other words, the global permission data contains all access objects and the hierarchical relationship corresponding to all access objects. When determining the required target permission data, the target permission data under the type to be operated required to access the object to be accessed is always screened out from the global permission data, thereby reducing the determination time required to determine the target permission data, which is conducive to improving the determination efficiency. In another optional embodiment, the service provider 120 may directly generate the target permission data under the type to be operated required to access the object to be accessed based on the target access objects of each level that need to be passed through to access the object to be accessed.
[0055] In an optional embodiment, before obtaining the target permission data in response to the access request, the method further includes: filtering the object to be accessed of the access request and the type of operation to be performed corresponding to the object to be accessed based on a preset sandbox filtering rule. The sandbox function corresponds to a preset sandbox filtering rule, which can be understood as a data isolation mechanism for controlling the access rights of the user 110 to a subset of feature data. Specifically, the sandbox limits the viewing rights of the user 110 to certain data by defining the access boundary of the data.
[0056] S230 . Determine identity authority data granted to the user 110 according to the identity data of the user 110 . The identity authority data includes an authority access object and an authority operation type corresponding to the authority access object.
[0057] The permission access object can be understood as the access object that the service provider 120 grants the user 110 to access, and the permission operation type can be understood as the operation type that the service provider 120 grants the user 110 to perform on the permission access object.
[0058] It should be further explained that the above-mentioned step S230 can be determined before S220, or after S220, or after step S220 responds to the access request, or both can be determined together or cross-determined. This application does not impose any limitation on the order of execution of the two processes.
[0059] In an optional embodiment, the service provider 120 may generate identity authority data for each user based on the identity data of each user in advance, and store the identity authority data in correspondence with the identity data of the user to which it belongs. When it is necessary to determine the identity authority data of the user 110, it is only necessary to call the identity authority data of the user 110 from the storage space based on the identity data of the user 110, which reduces the time for determining the identity authority data of the user 110 and helps to improve the determination efficiency. In another optional embodiment, the service provider 120 may generate the identity authority data of the user 110 based on the authority access object in the identity authority data of the user 110 and the authority operation type corresponding to the authority access object.
[0060] S240: When the identity authority data contains the target authority data, it is determined that the user 110 has the authority to perform the operation corresponding to the type of operation to be performed on the object to be accessed.
[0061] In an optional implementation, the target permission data and identity permission data may be presented in the form of a permission link; the target permission data also includes the hierarchical relationship between target access objects at each level; correspondingly, the identity permission data also includes the hierarchical relationship between permission access objects.
[0062] Optionally, the authority link form can be specifically in the form of an authority link graph. Accordingly, the hierarchical relationship between target access objects at each level in the target authority data can be presented in a line form; the hierarchical relationship between authority access objects in the identity authority data can be presented in a line form.
[0063] Optionally, the situation where the identity authority data contains target authority data includes: the authority link of the target authority data is a sub-link of the authority link of the identity authority data.
[0064] For the sake of convenience, let's take the table t3 as the object to be accessed, the operation type to be performed as viewing, and the target access objects at each level that need to be passed through to access the table t3 object as "database D1-schema S1-table t3". Figure 2B As shown in the figure, there are three levels, and based on the hierarchical relationship, the database D1, the mode S1, and the table t3 are connected in sequence. At the same time, it can be seen that the type of operation to be performed on the table t3 is viewing. Correspondingly, the identity permission data can also be presented in the form of a permission chain diagram. The identity permission data in the form of a permission chain diagram is as follows: Figure 2C As shown, the identity authority of the user 110 includes data authority and collection authority. D1-D4 represents database 1-database 4; S1-S6 represents mode 1-mode 6 under the corresponding database; S1-S9 represents database tables under the corresponding mode; C1-C6 represents collection 1-collection 6. Figure 2CThe operation type of the access object is also shown, such as view, create query, native query, block access, and edit. Figure 2B and Figure 2C It can be seen that the permission link of the target permission data is a sub-link of the permission link of the identity permission data, so it can be judged that the user party 110 has the permission to perform the operation corresponding to the type to be operated on the object to be accessed. Presenting the identity permission data and the target permission data in the form of a permission link diagram can more intuitively show the permissions authorized by the user party 110 and the permissions required to access the object to be accessed, which is conducive to improving the efficiency of determining whether the user party 110 has the permission to perform the operation corresponding to the type to be operated on the object to be accessed.
[0065] Optionally, the permission link form can be a permission path form. Accordingly, the hierarchical relationship between target access objects at each level can be distinguished by separators; the hierarchical relationship between permission access objects in identity permission data can be distinguished by separators. The permission link of the target permission data is a sub-link of the permission link of the identity permission data.
[0066] For the sake of convenience, continue to refer to the above example. The target access objects of each level that need to be passed through to access table t3 are "database D1-schema S1-table t3". The target permission data is presented in the form of permission path as "permission / db / 1 / schema / 1 / table / 3 / read". Permission refers to the permission level or type required to access the resource; db / 1 represents the database and its identifier, schema / 1 represents the schema in the database and its identifier; table / 3 represents the table in the schema and its identifier, and read represents the type of operation to be viewed. Correspondingly, the identity permission data can also be presented in the form of permission path, for example, it can be presented as "permission / db / 2 / schema / 1 / table / 2 / read". The permission link of the target permission data is not a sub-link of the permission link of the identity permission data, so it can be judged that the user party 110 does not have the permission to perform the operation corresponding to the type to be operated on the object to be accessed. Presenting the identity permission data and the target permission data in the form of permission path is convenient for comparison, which is conducive to improving the efficiency of determining whether the user party 110 has the permission to perform the operation corresponding to the type to be operated on the object to be accessed.
[0067] In an optional implementation, when the identity authority data does not include the target authority data, unauthorized information is generated to prompt the user 110 that he does not have the corresponding authority.
[0068] In the embodiment of the present application, by introducing target permission data, the data of target access objects of each level that the object to be accessed needs to pass through can be integrated into a single target permission data; by determining the target permission data under the type of operation to be operated required to access the object to be accessed, and determining the identity permission data granted to the user party 110 based on the identity data of the user party 110, so that when the identity permission data contains the target permission data, it is determined that the user party 110 has the authority to perform the operation corresponding to the type of operation to be operated on the object to be accessed. The above process only requires one comparison to determine whether the user party 110 has the authority to perform the corresponding operation, without the need for multiple level-by-level verifications, thereby improving the verification efficiency.
[0069] Based on the technical solutions of the above embodiments, the present application also provides an optional embodiment, in which the steps for determining the identity authority data are refined.
[0070] See also Figure 3 The steps for determining the identity authority data shown include:
[0071] S310: Determine each role group to which the identity data belongs.
[0072] The role group is a collection of multiple role members, and these role members share access rights granted by the service party 120 within the role group. It is easy to understand that for a user party 110, the role groups to which it belongs may be one, two or more.
[0073] S320: Obtain role permission data of each role group, where the role permission data includes permission access objects and permission operation types granted to each role member in the role group.
[0074] S320 . Determine the identity authority data of the user 110 according to the role authority data corresponding to each role group.
[0075] For example, the role group to which the user 110 belongs includes role group A and role group B. The role permission data of role group A includes: database D1-mode S1-table t3-query, and the role permission data of role group B includes: database D1-mode S1-table t2-edit. The identity permission data of the user 110 can be expressed as "database D1-mode S1-table t3-query and database D1-mode S1-table t2-edit".
[0076] In an optional embodiment, when the role permission data of any role group needs to be changed, the role members and the latest role permission data of the corresponding role group are obtained according to the change content; the identity permission data of each role member is obtained according to the latest role permission data; the identity permission data of each role member is conflict verified; and when the conflict verification passes, the role permission data of the corresponding role group is updated with the latest role permission data.
[0077] In an optional embodiment, when at least one conflict verification fails, permission update exception information is generated to prompt the staff to check whether the permission change content is correct.
[0078] Exemplarily, taking role group A as an example, the role permission data of the role group needs to be changed from "database D1-mode S1-table t3-query" to "database D1-mode S1-table t2-query only". Since the role groups to which user party 110 belongs include role group A and role group B, the identity permission data of user party 110 can be expressed as "database D1-mode S1-table t2-edit and database D1-mode S1-table t2-query only". It is not difficult to see that for table t2, both editing permission and query-only permission need to be satisfied, which leads to a permission conflict for user party 110.
[0079] In an embodiment of the present application, the service party 120 grants permission access objects and permission operation types to each role member in the role group, so that the identity permission data of the user party 110 can be determined by simply determining the role groups to which the identity data of the user party 110 belongs and the role permission data of each role group. This is beneficial to improving the efficiency of determining the identity permission data of the user party 110. At the same time, granting role members permission access objects and permission operation types through role groups facilitates permission updates or modifications.
[0080] Based on the technical solutions of the above embodiments, the present application also provides an optional embodiment, in which another specific implementation method of the permission verification method is provided.
[0081] See also Figure 4 The permission verification methods shown include:
[0082] S410: Acquire an access request sent by a user, where the access request includes an object to be accessed, a type of operation to be performed corresponding to the object to be accessed, and identity data of the user.
[0083] S420: Filter the object to be accessed of the access request and the type of operation to be performed corresponding to the object to be accessed based on a preset sandbox filtering rule.
[0084] S430. In response to the access request, determine the target permission data under the type of operation required to access the object to be accessed; the target permission data includes target access objects of each level that need to be passed through to access the object to be accessed; the target permission data also includes the hierarchical relationship between the target access objects of each level; the target permission data is presented in the form of a permission link.
[0085] S440: Determine each role group to which the identity data belongs.
[0086] S450: Obtain role permission data of each role group, where the role permission data includes permission access objects and permission operation types granted to each role member in the role group.
[0087] S460. Determine the identity permission data of the user according to the role permission data corresponding to each role group; the identity permission data includes permission access objects and permission operation types corresponding to the permission access objects; the identity permission data also includes the hierarchical relationship between the permission access objects. The identity permission data is presented in the form of a permission link.
[0088] S470: When the permission link of the target permission data is a sub-link of the permission link of the identity permission data, it is determined that the user has permission to perform an operation corresponding to the type of operation to be performed on the object to be accessed.
[0089] The detailed technical contents of the above steps S410 - S470 have been recorded in the above embodiments and will not be repeated here.
[0090] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.
[0091] Based on the same inventive concept, the embodiment of the present application also provides a permission verification device for implementing the permission verification method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more permission verification device embodiments provided below can refer to the limitations on the permission verification method above, and will not be repeated here.
[0092] In an exemplary embodiment, Figure 5 As shown, a permission verification device is provided, including: a first acquisition module 510, a first determination module 520, a second determination module 530 and a third determination module 540, wherein:
[0093] A first acquisition module 510 is used to acquire an access request sent by a user, where the access request includes an object to be accessed, a type of operation to be performed corresponding to the object to be accessed, and identity data of the user;
[0094] The first determination module 520 is used to determine the target permission data of the operation type required to access the object to be accessed in response to the access request; the target permission data includes target access objects of various levels required to access the object to be accessed; and
[0095] The second determination module 530 determines the identity authority data granted to the user according to the identity data of the user; the identity authority data includes the authority access object and the authority operation type corresponding to the authority access object;
[0096] The third determination module 540 determines whether the user has the authority to perform the operation corresponding to the type of operation to be performed on the object to be accessed when the identity authority data contains the target authority data.
[0097] In one embodiment, the target permission data and identity permission data are presented in the form of permission links; the target permission data also includes the hierarchical relationship between target access objects at each level; correspondingly, the identity permission data also includes the hierarchical relationship between permission access objects.
[0098] In one embodiment, the situation where the identity permission data contains the target permission data includes: the permission link of the target permission data is a sub-link of the permission link of the identity permission data.
[0099] In one embodiment, the second determination module 530 includes: a first determination unit, used to determine the role groups to which the identity data belongs; a first acquisition unit, used to acquire role authority data of each role group, the role authority data including the authority access objects and authority operation types granted to each role member in the role group; a second determination unit, determining the identity authority data of the user based on the role authority data corresponding to each role group.
[0100] In one embodiment, the authority verification device also includes: a second acquisition module, which is used to obtain the role members and the latest role authority data of the corresponding role group according to the change content when the role authority data of any role group needs to be changed; a third acquisition module, which is used to obtain the identity authority data of each role member according to the latest role authority data; a verification module, which is used to perform conflict verification on the identity authority data of each role member; and an update module, which is used to update the role authority data of the corresponding role group with the latest role authority data when all conflict verifications are passed.
[0101] In one embodiment, the permission verification device further includes: a filtering module for filtering the access object and the operation type corresponding to the access object in the access request based on the preset sandbox filtering rules.
[0102] Each module in the above-mentioned permission verification device can be implemented in whole or in part by software, hardware and their combination. Each of the above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules.
[0103] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 6 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store identity authority data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a permission verification method is implemented.
[0104] Those skilled in the art will understand that Figure 6 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.
[0105] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the following steps are implemented:
[0106] Obtaining an access request sent by a user, the access request including an object to be accessed, a type of operation to be performed on the object to be accessed, and identity data of the user;
[0107] In response to the access request, determining target permission data of the type of operation required to access the object to be accessed; the target permission data includes target access objects of various levels required to access the object to be accessed; and
[0108] Determine the identity authority data granted to the user based on the user's identity data; the identity authority data includes the authority access object and the authority operation type corresponding to the authority access object;
[0109] In the case where the identity authority data contains the target authority data, it is determined that the user has the authority to perform the operation corresponding to the type of operation to be performed on the object to be accessed.
[0110] In one embodiment, the target permission data and identity permission data are presented in the form of permission links; the target permission data also includes the hierarchical relationship between target access objects at each level; correspondingly, the identity permission data also includes the hierarchical relationship between permission access objects.
[0111] In one embodiment, the case where the identity authority data contains the target authority data includes: the authority link of the target authority data is a sub-link of the authority link of the identity authority data
[0112] In one embodiment, when the processor executes the computer program, the following steps are also implemented: determining the role groups to which the identity data belongs; obtaining role permission data for each role group, the role permission data including the permission access objects and permission operation types granted to each role member in the role group; and determining the identity permission data of the user based on the role permission data corresponding to each role group.
[0113] In one embodiment, the processor also implements the following steps when executing the computer program: when the role permission data of any role group needs to be changed, the role members and the latest role permission data of the corresponding role group are obtained according to the change content; the identity permission data of each role member is obtained according to the latest role permission data; the identity permission data of each role member is conflict verified; and when the conflict verification passes, the role permission data of the corresponding role group is updated with the latest role permission data.
[0114] In one embodiment, when the processor executes the computer program, the following steps are further implemented: based on preset sandbox filtering rules, filtering the objects to be accessed in the access request and the types of operations to be performed corresponding to the objects to be accessed.
[0115] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:
[0116] Obtaining an access request sent by a user, the access request including an object to be accessed, a type of operation to be performed on the object to be accessed, and identity data of the user;
[0117] In response to the access request, determining target permission data of the type of operation required to access the object to be accessed; the target permission data includes target access objects of various levels required to access the object to be accessed; and
[0118] Determine the identity authority data granted to the user based on the user's identity data; the identity authority data includes the authority access object and the authority operation type corresponding to the authority access object;
[0119] In the case where the identity authority data contains the target authority data, it is determined that the user has the authority to perform the operation corresponding to the type of operation to be performed on the object to be accessed.
[0120] In one embodiment, the target permission data and identity permission data are presented in the form of permission links; the target permission data also includes the hierarchical relationship between target access objects at each level; correspondingly, the identity permission data also includes the hierarchical relationship between permission access objects.
[0121] In one embodiment, the case where the identity permission data contains the target permission data includes: the permission link of the target permission data is a sub-link of the permission link of the identity permission data.
[0122] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: determining the role groups to which the identity data belongs; obtaining role permission data for each role group, the role permission data including the permission access objects and permission operation types granted to each role member in the role group; and determining the identity permission data of the user based on the role permission data corresponding to each role group.
[0123] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: when the role permission data of any role group needs to be changed, the role members and the latest role permission data of the corresponding role group are obtained according to the change content; the identity permission data of each role member is obtained according to the latest role permission data; the identity permission data of each role member is conflict verified; and when the conflict verification passes, the role permission data of the corresponding role group is updated with the latest role permission data.
[0124] In one embodiment, when the computer program is executed by the processor, the following steps are further implemented: based on preset sandbox filtering rules, filtering the objects to be accessed in the access request and the types of operations to be performed corresponding to the objects to be accessed.
[0125] In one embodiment, a computer program product is provided, comprising a computer program, which, when executed by a processor, implements the following steps:
[0126] Obtaining an access request sent by a user, the access request including an object to be accessed, a type of operation to be performed on the object to be accessed, and identity data of the user;
[0127] In response to the access request, determining target permission data of the type of operation required to access the object to be accessed; the target permission data includes target access objects of various levels required to access the object to be accessed; and
[0128] Determine the identity authority data granted to the user based on the user's identity data; the identity authority data includes the authority access object and the authority operation type corresponding to the authority access object;
[0129] In the case where the identity authority data contains the target authority data, it is determined that the user has the authority to perform the operation corresponding to the type of operation to be performed on the object to be accessed.
[0130] In one embodiment, the target permission data and identity permission data are presented in the form of permission links; the target permission data also includes the hierarchical relationship between target access objects at each level; correspondingly, the identity permission data also includes the hierarchical relationship between permission access objects.
[0131] In one embodiment, the case where the identity permission data contains the target permission data includes: the permission link of the target permission data is a sub-link of the permission link of the identity permission data.
[0132] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: determining the role groups to which the identity data belongs; obtaining role permission data for each role group, the role permission data including the permission access objects and permission operation types granted to each role member in the role group; and determining the identity permission data of the user based on the role permission data corresponding to each role group.
[0133] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: when the role permission data of any role group needs to be changed, the role members and the latest role permission data of the corresponding role group are obtained according to the change content; the identity permission data of each role member is obtained according to the latest role permission data; the identity permission data of each role member is conflict verified; and when the conflict verification passes, the role permission data of the corresponding role group is updated with the latest role permission data.
[0134] In one embodiment, when the computer program is executed by the processor, the following steps are further implemented: based on preset sandbox filtering rules, filtering the objects to be accessed in the access request and the types of operations to be performed corresponding to the objects to be accessed.
[0135] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.
[0136] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.
[0137] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.
[0138] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.
Claims
1. A permission verification method, characterized in that: Applied to the service side, the method includes: Acquire an access request sent by a user, wherein the access request includes an object to be accessed, a type of operation to be performed corresponding to the object to be accessed, and identity data of the user; In response to the access request, determining target permission data of the type to be operated required to access the object to be accessed; the target permission data includes target access objects of each level required to access the object to be accessed; and Determine the identity authority data granted to the user according to the identity data of the user; the identity authority data includes an authority access object and an authority operation type corresponding to the authority access object; In the case that the identity authority data contains the target authority data, it is determined that the user has the authority to perform the operation corresponding to the type to be operated on the object to be accessed.
2. The method according to claim 1, characterized in that The target authority data and identity authority data are presented in the form of authority links; The target permission data also includes the hierarchical relationship between the target access objects at each level; correspondingly, the identity permission data also includes the hierarchical relationship between the permission access objects.
3. The method according to claim 2, characterized in that The situation where the identity authority data contains the target authority data includes: The permission link of the target permission data is a sub-link of the permission link of the identity permission data.
4. The method according to any one of claims 1 to 3, characterized in that: Determining the identity authority data of the user according to the identity data of the user includes: Determining the role groups to which the identity data belongs; Acquire role permission data of each role group, wherein the role permission data includes permission access objects and permission operation types granted to each role member in the role group; The identity authority data of the user is determined according to the role authority data corresponding to each role group.
5. The method according to claim 4, characterized in that The method further comprises: When the role permission data of any role group needs to be changed, the role members and the latest role permission data of the corresponding role group are obtained according to the changed content; According to the latest role authority data, the identity authority data of each role member is obtained; Perform conflict verification on the identity and authority data of each role member; When all conflict verifications are passed, the role permission data of the corresponding role group is updated with the latest role permission data.
6. The method according to any one of claims 1 to 3, characterized in that: Before obtaining the target permission data in response to the access request, the method further includes: Based on preset sandbox filtering rules, the object to be accessed of the access request and the type of operation to be performed corresponding to the object to be accessed are filtered.
7. A permission verification device, characterized in that: The device comprises: A first acquisition module is used to acquire an access request sent by a user, wherein the access request includes an object to be accessed, a type of operation to be performed corresponding to the object to be accessed, and identity data of the user; A first determination module is used to determine, in response to the access request, target permission data of the operation type required to access the object to be accessed; the target permission data includes target access objects of each level required to access the object to be accessed; and A second determination module determines, based on the identity data of the user, identity authority data granted to the user; the identity authority data includes an authority access object and an authority operation type corresponding to the authority access object; The third determination module determines, when the identity authority data contains the target authority data, whether the user has the authority to perform the operation corresponding to the type to be operated on the object to be accessed.
8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.
10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.