Authority control system, method and device, computer equipment and storage medium

Abstract

The invention relates to an authority control system, method and device, computer equipment and a storage medium. The system comprises an SaaS platform and at least one sub-platform, the SaaS platform is used for distributing initial permission information to the sub-platform according to a permission template configured for the sub-platform in advance, the sub-platform is used for distributing corresponding permission to at least one user role according to the initial permission information, and the sub-platform is further used for receiving a data access request and sending the data access request to the SaaS platform. The sub-platform is used for acquiring a data access request and extracting role information in the data access request, the sub-platform is also used for acquiring a target permission corresponding to the role information, and when a permission corresponding to the data access request exists in the target permission, a corresponding data access operation is executed. By adopting the system, permission distribution and configuration of the SaaS platform to a plurality of SP platforms can be supported, and each SP platform can customize permissions according to requirements.

Description

Technical Field

[0001] The present application relates to the technical field of cloud computing technology, and in particular to an authority control system, method, apparatus, computer equipment, and storage medium. Background Art

[0002] With the development of cloud computing technology, SaaS platforms have gradually become the mainstream choice for modern information management architectures. Their advantages lie in their convenient cross-platform distribution capabilities, scalability, and real-time update capabilities. However, as their businesses expand, many organizations have created multiple sub-platforms within the SaaS platform, each with complex permissions and resource allocation requirements. For example, different sub-platforms may target different user groups and business content, resulting in different page access and data permissions. In this case, SaaS platform permissions need to be distributed to each sub-platform, and each sub-platform's requirements may vary. For example, if a SaaS platform has 100 resources, sub-platform A may require 10 of them, while sub-platform B may require 20 resources. Existing permission management solutions struggle to meet these dynamic and differentiated distribution requirements. Summary of the Invention

[0003] Based on this, it is necessary to provide a permission control system, method, device, computer equipment and storage medium that can support permission configuration and distribution on multiple platforms to address the above technical problems.

[0004] In a first aspect, a permission control system is provided, the system including a SaaS platform and at least one sub-platform, wherein:

[0005] The SaaS platform is used to distribute initial permission information to the sub-platforms based on the permission template pre-configured for the sub-platforms;

[0006] The sub-platform is used to assign corresponding permissions to at least one user role according to the initial permission information;

[0007] The sub-platform is also used to receive data access requests and extract role information from the data access requests;

[0008] The sub-platform is also used to obtain the target permissions corresponding to the role information, and when the target permissions contain permissions corresponding to the data access request, the corresponding data access operation is performed.

[0009] In one embodiment, the sub-platform is used to obtain the level of the user role, and assign corresponding permissions to the user role according to the initial permission information and the level of the user role, wherein the permissions of each level are assigned according to the permissions of the previous level.

[0010] In one embodiment, the sub-platform is used to monitor permissions at various levels using a permission merging algorithm, and when multiple duplicate permissions corresponding to the same user role are detected, the multiple duplicate permissions are merged.

[0011] In one embodiment, the sub-platform is further configured to generate an alarm prompt message and send it to the SaaS platform when the target permissions do not contain permissions corresponding to the data access request;

[0012] The SaaS platform is used to adjust initial permission information based on alarm prompt information.

[0013] In one embodiment, the sub-platform is further configured to record access logs corresponding to data access operations and send the access logs to the SaaS platform;

[0014] The SaaS platform is used to adjust initial permission information based on access logs and alarm prompts.

[0015] In one embodiment, the SaaS platform is used to send the permission template to the sub-platform;

[0016] The sub-platform is used to send the permission template to the user end for display, receive the user end's modification instructions for the permission template, modify the permission template accordingly, and send the modified permission information to the SaaS platform.

[0017] In a second aspect, a permission control method is provided, which is applied to a sub-platform of a SaaS platform. The permission control method includes:

[0018] Receive the initial permission information distributed by the SaaS platform. The initial permission information is generated by the SaaS platform based on the permission template pre-configured for the sub-platform;

[0019] Assign corresponding permissions to at least one user role according to the initial permission information;

[0020] Receive a data access request and extract role information from the data access request;

[0021] Get the target permissions corresponding to the role information;

[0022] When the target permission contains a permission corresponding to the data access request, the corresponding data access operation is performed.

[0023] In a second aspect, a permission control device is provided, which is applied to a sub-platform of a SaaS platform. The permission control device includes:

[0024] A receiving module is used to receive the initial permission information distributed by the SaaS platform. The initial permission information is generated by the SaaS platform based on the permission template pre-configured for the sub-platform;

[0025] An allocation module, configured to allocate corresponding permissions to at least one user role according to the initial permission information;

[0026] An access module, configured to receive a data access request and extract role information from the data access request;

[0027] The acquisition module is used to obtain the target permissions corresponding to the role information;

[0028] The execution module is used to execute the corresponding data access operation when the target permission contains the permission corresponding to the data access request.

[0029] In a third aspect, the present application provides a computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the permission control method provided in any embodiment of the present application in the second aspect are implemented.

[0030] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the permission control method provided in any embodiment of the second aspect of the present application.

[0031] The above-mentioned permission control system, method, device, computer equipment and storage medium generate initial permission information for each sub-platform through the SaaS platform according to the permission template pre-configured for each sub-platform. After receiving the initial permission information, each sub-platform further subdivides it into each user role on its own platform, thereby realizing differentiated setting of permission information for each sub-platform through SaaS. Subsequently, each sub-platform is further subdivided based on the initial permission information, thereby realizing autonomous control of permissions by each sub-platform. It can be seen that by adopting this application, the SaaS platform can support the distribution and configuration of permissions to multiple sub-platforms, and each sub-platform can customize permissions according to needs. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 A structural block diagram of an authority control system in some embodiments;

[0033] Figure 2 Schematic diagram of the flow of the permission control method in some embodiments;

[0034] Figure 3 is a structural block diagram of an authority control device in some embodiments;

[0035] Figure 4 1 is a diagram of the internal structure of a computer device in some embodiments. DETAILED DESCRIPTION

[0036] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0037] In a first aspect, the present application provides a permission control system, such as Figure 1 As shown, the system includes a SaaS platform and at least one sub-platform, wherein the SaaS platform is used to distribute initial permission information to the sub-platform according to a permission template pre-configured for the sub-platform, and the sub-platform is used to assign corresponding permissions to at least one user role according to the initial permission information. The sub-platform is also used to receive data access requests and extract role information in the data access requests. The sub-platform is also used to obtain target permissions corresponding to the role information, and when the target permissions contain permissions corresponding to the data access request, the corresponding data access operation is executed.

[0038] Among them, the SaaS platform (Software as a Service platform) is a platform that provides software services through the Internet. Multiple users can access and use the software on the platform through a browser or other means without having to install it locally.

[0039] Sub-platforms (Service Platforms): In this context, these are the various service platforms that rely on the SaaS platform. They obtain permissions and data distribution from the SaaS platform, much like different rooms in an apartment. Each room (equivalent to a sub-platform) has its own relatively independent functions and resource management, and this management is carried out within the rules and framework of the entire apartment (equivalent to the SaaS platform). Together with the SaaS platform, they form a multi-layered service system to meet complex business needs.

[0040] A permissions template is a set of pre-set rules used by SaaS platforms to assign permissions and configure resources. It's like a blueprint or recipe, defining what permissions different sub-platforms can have and what resources they can access.

[0041] For example, a permissions template might specify that sub-platform M can perform add, delete, modify, and query operations on resources, while sub-platform N can only perform view operations. When distributing permissions to sub-platforms, the SaaS platform uses this template and the specific needs of the sub-platforms to determine the corresponding permissions for each sub-platform, thereby achieving dynamic and flexible permission allocation.

[0042] Initial permission information refers to the permission information distributed by the SaaS platform to the sub-platform. Subsequently, each sub-platform will be further subdivided based on the initial permission information.

[0043] Specifically, system administrators or relevant configuration personnel pre-customize permission templates for each sub-platform based on the business needs and functional characteristics of each sub-platform. These templates define in detail the access rights of various resources (such as data and functional modules) for different sub-platforms, such as which roles can read, write, and delete specific resources.

[0044] For example, for an e-commerce sub-platform, the "merchant" role may be set in the permission template to have the permissions to upload product information and view order status, while the "buyer" role has permissions such as placing orders and viewing product details.

[0045] Furthermore, when a new sub-platform is added or an existing sub-platform requires an update, the SaaS platform reads the permissions template configured for that sub-platform. Based on the template content, the corresponding initial permissions information is packaged in a data format (such as a structured JSON or XML file) and sent to the corresponding sub-platform. For example, the initial permissions information for the "Merchant" and "Buyer" roles in the aforementioned e-commerce sub-platform is distributed to the corresponding e-commerce sub-platform according to the specified format.

[0046] Furthermore, the sub-platform receives the initial permission information data packet distributed by the SaaS platform through the network communication interface, parses the received data, and converts it into a permission data structure that can be recognized and processed within the sub-platform, such as storing it in a specific permission table in the database.

[0047] Furthermore, when a new user registers on the sub-platform or an existing user's role changes, the sub-platform determines the permissions corresponding to each user role based on the initial permission information received. For example, if a newly registered user is marked as a "merchant" role, the sub-platform will extract all permissions of the "merchant" role from the parsed and stored permission data and assign them to the new user, allowing them to operate within the specified permission range.

[0048] Furthermore, the sub-platform receives data access requests from the user end through its external service interface (such as a web service interface). These requests may be triggered by user operations on the interface (such as clicking to view an order, uploading a product, etc.). The sub-platform then extracts key role information from the received request data, typically by parsing the identity authentication identifier or related parameters in the request to determine which user role issued the request. For example, from a request containing a user login token, it can parse out whether the corresponding role is "buyer" or "merchant."

[0049] Furthermore, based on the extracted role information, the sub-platform searches its internally stored permission data structure (e.g., a permission table in a database) for all permissions corresponding to that role and identifies them as target permissions. For example, if the extracted role is "buyer," the permission table will be used to find all permissions previously assigned to the "buyer" role, including which order data can be accessed, which product information can be viewed, etc.

[0050] Furthermore, the sub-platform compares the specific operation content in the data access request (such as viewing the detailed information of a specific order) with the obtained target permissions. If the target permissions contain permissions corresponding to the data access request (for example, the target permissions contain the permission to view the detailed information of an order), the sub-platform will call the relevant business logic module and data access layer to perform the actual data access operation, such as querying the detailed information of the order from the database and returning it to the user. If the corresponding permissions do not exist, the sub-platform will refuse to perform the operation and may return a corresponding prompt message to the user to inform them that they do not have such permissions.

[0051] In one embodiment, the sub-platform is used to obtain the level of the user role, and assign corresponding permissions to the user role according to the initial permission information and the level of the user role, wherein the permissions of each level are assigned according to the permissions of the previous level.

[0052] The user's level refers to a classification method used to divide the scope of user permissions within the sub-platform. For example, it can be divided according to the level of management permissions, such as ordinary users, advanced users, and administrators; it can also be divided according to business roles, such as front-line employees, department heads, and company executives. Different levels correspond to different responsibilities and scopes of permissions. Low-level users have relatively fewer permissions, while high-level users have more permissions. Permission allocation is usually hierarchical, and the permissions of high-level users include some or all of the permissions of low-level users, as well as additional privileges. These level definitions help to more finely manage user access and operations to data, functional modules, and other resources within the sub-platform.

[0053] The permissions of each level are allocated according to the permissions of the previous level, which means that the permissions of each level should be within the scope of the permissions corresponding to the previous level and cannot exceed the permissions corresponding to the previous level.

[0054] Specifically, in this application, different user role levels are pre-defined during the sub-platform system design phase. For example, they can be set as primary user, intermediate user, advanced user, etc., or divided into different levels according to management authority, such as ordinary employee, department head, platform administrator, etc., with each level having its corresponding responsibilities and authority scope.

[0055] These level definitions are usually stored in a specific table in the sub-platform database, such as the "Role Level Definition Table", which records information such as the name of each level, a brief description of the corresponding responsibilities, and an overview of the scope of authority.

[0056] Furthermore, when a new user registers on the sub-platform or an existing user's role changes, the sub-platform will determine the user's level based on the user's registration information, position information or other relevant attributes.

[0057] For example, if the job title filled in by the user when registering is "department manager", the sub-platform can determine that the level of the user role is "intermediate user" (assuming that the department manager corresponds to the intermediate user level) by querying the pre-set position and level correspondence (which may be stored in another "position level mapping table").

[0058] Furthermore, after receiving the initial permission information distributed by the SaaS platform, the sub-platform first parses and processes it. If the initial permission information is sent in a certain data format (such as JSON), the sub-platform will use the corresponding parsing tools (such as a JSON parsing library) to convert it into an internally processable data structure, which is usually stored in the "initial permission information table" in the database for subsequent query and use.

[0059] The parsed initial permission information clearly presents the access permissions of different resources (such as data resources, functional modules, etc.) for various roles, such as which resources can be accessed by all roles and which can only be accessed by specific roles.

[0060] Furthermore, based on the determined user role level, the sub-platform queries the database for an overview of the permissions corresponding to that level. Simultaneously, combined with the parsed initial permissions information, it identifies specific permissions that are both within the permissions for that level and within the initial permissions range, and then assigns these permissions to the corresponding user role.

[0061] For example, for an "Intermediate User" role, the sub-platform first queries the "Role Level Definition Table" to determine that the scope of permissions for the intermediate user level is access to some core data resources and some common functional modules. Then, based on the specific initial permissions parsed from the "Initial Permission Information Table," the sub-platform determines the specific core data resources (such as data for certain specific projects) and common functional modules (such as the report generation module) that the "Intermediate User" role can access, and grants these permissions to the user role.

[0062] Furthermore, within the sub-platform, user roles that have been assigned initial permissions, such as administrators, can be further subdivided based on actual needs. For example, administrators can manually set specific permissions for different types of ordinary users (such as regular employees, temporary employees, etc.) and privileged users (such as senior consultants) through the permissions management interface provided by the sub-platform.

[0063] This process may involve updating records in the "User Permission Details Table" in the database to accurately associate the newly set permissions with the corresponding user roles. For example, an administrator may use the permissions management interface to set up access for ordinary employees to only basic data resources, while privileged users can also access advanced analytical tools in addition to basic data resources. These settings will be updated in the "User Permission Details Table."

[0064] Among them, when the sub-platform performs any permission distribution operation, whether it is the allocation of initial permissions or the distribution of further refined permissions internally, it will continuously compare the permission content to be distributed with the initial permission information received from the SaaS platform.

[0065] Before each permission is assigned, check whether it exceeds the permission scope specified by the SaaS platform. For example, if the SaaS platform stipulates that users of a sub-platform cannot access a certain type of sensitive data resource, then when assigning permissions to the sub-platform, even during the internal permission refinement process, it will ensure that no user role is assigned permission to access this sensitive data resource, thereby ensuring that the permission distribution does not exceed the restrictions of the SaaS platform.

[0066] The beneficial effect of this embodiment is that each level of permissions is allocated based on the permissions of the previous level. This design helps to ensure the consistency of permissions throughout the entire system. All levels of permissions are built on a core permission chain, avoiding permission conflicts or logical confusion.

[0067] Furthermore, after receiving overall permissions from the SaaS platform, the sub-platform must further subdivide these permissions based on the specific needs of different roles within the sub-platform in actual business operations. This can involve two or even multiple levels of permissions. This design enables refined permission control: through the progressive allocation of permissions, user access to and operations on system resources can be more precisely controlled. For sensitive resources or critical operations, effective management can be achieved by restricting permissions for lower-level users while appropriately granting permissions to higher-level users.

[0068] In one embodiment, the sub-platform is used to monitor permissions at various levels using a permission merging algorithm, and when multiple duplicate permissions corresponding to the same user role are detected, the multiple duplicate permissions are merged.

[0069] Among them, the permission merging algorithm is a calculation rule used to handle permission allocation. This algorithm comes into play when permissions at different levels are integrated or users at the same level have multiple sources of permissions. The permission merging algorithm can carefully check all permissions to be merged. For example, in an enterprise resource management system, users may obtain different permission sets due to various factors such as the department they belong to and the projects they participate in. The permission merging algorithm will first find the duplicate parts in these permission sets. For example, if a user obtains the permission to view financial statements from the department permission configuration and then obtains the permission to view the same statement again from the project group permission configuration, the algorithm will recognize that this is a duplicate permission, and then the sub-platform can merge multiple duplicate permissions.

[0070] For conflicting permissions, such as one permission setting that allows users to modify a document and another that only allows users to view it, the algorithm automatically adjusts to the most appropriate setting based on pre-defined rules (such as higher permissions first, latest settings first, etc.). This may mean that the end user gains permission to modify the document, or retains permission to view the document, depending on the system's priority settings. In short, the purpose of the permission merging algorithm is to ensure that the permissions ultimately granted to the user are reasonable and conflict-free.

[0071] In this application, for duplicate permissions, the sub-platform will retain the most reasonable one, or select one based on factors such as the importance of the role. For conflicting permissions, the permission merging algorithm will use the SaaS platform's permission limits as the highest priority. For example, if a sub-platform attempts to grant a user delete permissions that exceed the SaaS platform's limits, the algorithm will prevent this assignment, ensuring that permission configuration remains within the scope allowed by the SaaS platform, thereby avoiding security risks and confusion caused by permissions exceeding the limits.

[0072] Specifically, the permission merging algorithm of this application may include:

[0073] Permission merging algorithm based on bitwise operation

[0074] Permissions are represented as binary bits, with each bit representing a permission, such as read permission as bit 0 and write permission as bit 1. Permissions can be combined using the bitwise OR operator, and checked using the bitwise AND operator. This algorithm is simple and efficient, and is widely used in various scenarios, such as operating systems and databases, making it easy to represent and manipulate various permission combinations.

[0075] Tree-based permission merging algorithm

[0076] For example, in a distributed file system metadata service, this can improve the space efficiency of dedicated permission servers. It organizes permissions hierarchically into a tree structure, with nodes representing permission objects or scopes. The path from the root node to the leaf nodes represents permission inheritance and inclusion relationships. When merging permissions, the permissions and inheritance relationships of each node are comprehensively considered to achieve efficient and accurate permission merging.

[0077] Rule-based permission merging algorithm

[0078] Permission merging is handled based on predefined rules, including permission priority, conflict resolution strategies, etc.

[0079] In one embodiment, the sub-platform is also used to generate an alarm prompt message and send it to the SaaS platform when the target permission does not exist in the permission corresponding to the data access request. The SaaS platform is used to adjust the initial permission information according to the alarm prompt message.

[0080] Specifically, when the sub-platform receives a data access request, it obtains the target permissions corresponding to the requested role and compares them. If it is found that there is no permission corresponding to the request, the sub-platform will trigger an alarm mechanism.

[0081] Specifically, the sub-platform can generate warning information based on preset templates or rules. The information content may include the details of the access request (such as the name of the resource requested to be accessed, the type of operation), the role information of the requesting user, and a timestamp.

[0082] For example, the alert message format could be: "[Time] - User [Role Name] attempted to access [Resource Name] to perform [Operation Type], but lacked the corresponding permissions."

[0083] Furthermore, the sub-platform uses a communication interface (such as a network API) to send the generated alarm prompt information to the SaaS platform. This communication interface can use a secure communication protocol, such as HTTPS, to ensure the security of information transmission.

[0084] Furthermore, the -SaaS platform receives alarm information from the sub-platform through the corresponding endpoint. It verifies and analyzes the received information to ensure its integrity and accuracy.

[0085] The SaaS platform then analyzes the cause of the missing permissions based on the alert information. This may involve reviewing permission templates, sub-platform permission configuration rules, and historical changes to the current user role permissions.

[0086] For example, if the same user role across multiple sub-platforms frequently generates alerts indicating a lack of access rights to a specific resource, the SaaS platform may suspect a problem with the permissions template used to allocate permissions for that resource. Based on the analysis, the SaaS platform adjusts the initial permissions. This adjustment process may include modifying the permissions template and reallocating resource permissions.

[0087] For example, if it is discovered that some user roles have insufficient permissions due to the launch of a new feature, the SaaS platform can update the permission template, add appropriate permissions for the new feature resources to the relevant user roles, and then redistribute the updated initial permission information to the sub-platforms. This may involve database operations, modifying and updating the data tables that store permission templates and initial permission information.

[0088] In one embodiment, the sub-platform is also used to record access logs corresponding to data access operations and send the access logs to the SaaS platform. The SaaS platform is used to adjust the initial permission information based on the access logs and alarm prompt information.

[0089] Specifically, we will establish an access logging mechanism. Whenever each sub-platform accesses data, we will record in detail information such as the time of access, the IP address (Internet Protocol Address), the specific data resource accessed, and the type of operation (e.g., read, write, delete). These logs can be stored on a dedicated log server for subsequent query, analysis, and auditing. By regularly reviewing access logs, we can promptly identify unusual access behaviors and take appropriate measures.

[0090] When security issues occur, such as unusual data access behavior or signs of data leakage, these detailed log records can be quickly traced back to which user on which sub-platform performed the relevant operations, at what time, and by what method, allowing for timely identification of the source of the problem and implementation of appropriate measures. Furthermore, regular analysis of these logs can also reveal potential security vulnerabilities. For example, if a user frequently accesses sensitive data outside of normal business hours, this could indicate a potential security risk, such as account theft, allowing for timely prevention and resolution.

[0091] In addition, this application can also use appropriate data encryption algorithms (such as AES, RSA, etc.) to encrypt data stored on the server and during transmission. When storing data, the data is encrypted before being stored in a database or other storage medium; when transmitting data, ensure that the data between the sender and the receiver is transmitted in an encrypted form, and only the receiver with the correct decryption key can restore the original data.

[0092] In addition, this application can also adopt Fine-Grained Access Control (FGAC) to set different access permissions for each data item to ensure that users of each sub-platform can only access data within their permission range.

[0093] Fine-grained access control enables highly granular permissions by assigning different access permissions to each data item. For example, in an enterprise resource management SaaS architecture, different types of data items may exist, such as sales data and financial data. For sales personnel working on the sales sub-platform, access can be restricted to customer order information within the sales data area they are responsible for, while preventing access to orders or financial data from other areas. This precisely ensures that users on each sub-platform can only access data within their authorized scope, preventing unauthorized access.

[0094] Because access permissions for each data item are individually configured and matched to specific sub-platforms and user roles, data access boundaries between different sub-platforms are clearly defined. For example, users on the R&D sub-platform cannot access data within the permissions scope of the production sub-platform. Even if this data is stored in the same centrally managed data store, it is effectively isolated due to the different permissions set by fine-grained access control, thus preventing cross-platform data leakage.

[0095] In one embodiment, the SaaS platform is used to send the permission template to the sub-platform, and the sub-platform is used to send the permission template to the user end for display, and receive the user end's modification instructions for the permission template, modify the permission template accordingly, and send the modified permission information to the SaaS platform.

[0096] SaaS platform administrators or configuration personnel pre-define permission templates based on business needs, the characteristics of different sub-platforms, and other factors. These templates are stored in a structured data format, such as JSON or XML, and clearly define the access permissions for various resources (data, functional modules, etc.) for different roles.

[0097] The SaaS platform sends the prepared permission template to the corresponding sub-platform. It packages the permission template data according to the agreed-upon communication protocol (such as HTTP), specifies relevant information in the request header (such as the permission template being sent and the target sub-platform identifier), and then sends it to the sub-platform's designated receiving endpoint. Data encryption may be performed during transmission to ensure the security of the permission template during transmission and prevent tampering or theft.

[0098] The sub-platform receives permission template data from the SaaS platform. After receiving the data, the sub-platform uses appropriate parsing tools (such as JSON parsing libraries or XML parsing libraries, depending on the received data format) to parse the permission template and convert it into an internally processable data structure for subsequent operations.

[0099] Based on the user-side display requirements and technical framework, the sub-platform will convert and process the parsed permission templates into appropriate formats so that they can be displayed clearly and intuitively on the user side. This may involve converting permission information into user-friendly tables, lists, or graphics. For example, the permissions of different roles can be presented in a table with column headings such as "Role Name," "Accessible Resources," and "Executable Operations." Each row corresponds to a specific role and its permission content, making it easier for users to view.

[0100] The sub-platform sends the prepared presentation content to the user through established communication channels with the user (e.g., web services, mobile app push services, etc.). For web applications, the permission template presentation content might be embedded in an HTML page and then sent to the user's browser. For mobile applications, the permission template information might be presented to the user via push notifications or displayed on a specific page within the app.

[0101] After viewing the permissions template display content, if the user believes that certain permissions need to be adjusted, the user will issue modification instructions through the interactive interface provided by the user (such as buttons, text boxes, drop-down menus, etc.). These modification instructions will be sent back to the sub-platform through the communication channel between the user and the sub-platform.

[0102] For example, after seeing the permission settings for resources accessible to the "Ordinary User" role, the user clicks the "Modify" button, selects the resources to be added or deleted in the pop-up dialog box, and then clicks "OK". At this time, a modification instruction will be generated and sent to the sub-platform.

[0103] After receiving a modification instruction from the user, the sub-platform first parses the instruction to determine the specific content the user wants to modify (such as which role's permissions, which resources or operations to add or delete, etc.). At the same time, the sub-platform verifies the instruction according to pre-set rules to ensure that the modification instruction meets the system's security and logic requirements. For example, the sub-platform verifies whether the user has sufficient permissions to issue the modification instruction and whether the modified permission settings will cause permission conflicts or other unreasonable situations.

[0104] After parsing and verification, if the modification instruction is valid, the sub-platform will actually modify the permission template based on the instruction content. This may involve updating the previously parsed and stored data structures, such as modifying the corresponding role's list of accessible resources and the set of executable operations. For example, if the user instruction is to add access to a specific data resource for the "Ordinary User" role, the sub-platform will add the specific data resource to the list of accessible resources in the data structure storing the "Ordinary User" role's permissions.

[0105] After the sub-platform completes the modification of the permission template, it will organize and prepare the modified permission information in a certain format. The sub-platform will send the prepared modified permission information to the SaaS platform for storage to facilitate subsequent problem analysis and template adjustment.

[0106] In one of the embodiments, the present application not only meets current needs, but also supports a variety of expansion solutions. As the sub-platform business continues to develop, new permission requirements or resource requirements may arise. The configurable permission and resource model can easily perform configuration operations to add, modify or delete permissions and resources. For example, when the document processing sub-platform subsequently wants to add the function of multiple people editing the same document at the same time, the SaaS platform can adjust the configurable permission and resource model to add corresponding permission settings and resource allocation to support this new expansion requirement, ensuring that the unified permission allocation and data access control mechanism can always be maintained between different platforms, while meeting the scalability requirements of the system.

[0107] In the second aspect, Figure 2 As shown, a permission control method is provided, which is applied to the sub-platform of the SaaS platform. The permission control method includes:

[0108] Step S21: receiving initial permission information distributed by the SaaS platform. The initial permission information is generated by the SaaS platform according to a permission template pre-configured for the sub-platform.

[0109] Step S22: assign corresponding permissions to at least one user role according to the initial permission information.

[0110] Step S23: receiving a data access request and extracting role information from the data access request.

[0111] Step S24: Obtain the target authority corresponding to the role information.

[0112] Step S25: When there is a permission corresponding to the data access request in the target permission, the corresponding data access operation is executed.

[0113] The specific implementation method of each step can be found in the above specific embodiment of the authority control system, which will not be described in detail here.

[0114] In a third aspect, the present application provides a permission control device, such as Figure 3 As shown, the device is applied to a sub-platform of a SaaS platform. The permission control device includes a receiving module 31, an allocation module 32, an access module 33, an acquisition module 34, and an execution module 35, wherein:

[0115] The receiving module 31 is used to receive the initial permission information distributed by the SaaS platform. The initial permission information is generated by the SaaS platform according to the permission template pre-configured for the sub-platform.

[0116] The allocation module 32 is configured to allocate corresponding permissions to at least one user role according to the initial permission information.

[0117] The access module 33 is configured to receive a data access request and extract role information from the data access request.

[0118] The acquisition module 34 is used to acquire the target authority corresponding to the role information.

[0119] The execution module 35 is configured to execute a corresponding data access operation when there is a permission corresponding to the data access request in the target permission.

[0120] In a fourth aspect, the present application provides a computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the permission control method provided in any embodiment of the present application in the second aspect are implemented.

[0121] In one embodiment, the computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. 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 and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, it implements the permission control method.

[0122] In a fifth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the permission control method provided in any embodiment of the second aspect of the present application.

[0123] The computer readable storage medium may be Figure 4 A computer-readable storage medium in the computer device shown.

[0124] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the above-mentioned 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 memory, storage, database or other media used in the embodiments provided in this application may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0125] The technical features of the above embodiments can 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 specification.

[0126] The above embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the spirit of the present application, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of the present patent application shall be determined by the appended claims.

Claims

1. A permission control system, characterized in that: The system includes a SaaS platform and at least one sub-platform, wherein: The SaaS platform is used to distribute initial permission information to the sub-platform according to the permission template pre-configured for the sub-platform; The sub-platform is used to assign corresponding permissions to at least one user role according to the initial permission information; The sub-platform is also used to receive a data access request and extract role information in the data access request; The sub-platform is further used to obtain target permissions corresponding to the role information, and when permissions corresponding to the data access request exist in the target permissions, perform corresponding data access operations.

2. The method according to claim 1, characterized in that The sub-platform is used to obtain the level of the user role, and allocate corresponding permissions to the user role according to the initial permission information and the level of the user role, wherein permissions of each level are allocated according to permissions of the previous level.

3. The method according to claim 2, characterized in that The sub-platform is used to monitor permissions at various levels using a permission merging algorithm, and when it is detected that there are multiple duplicate permissions corresponding to the same user role, the multiple duplicate permissions are merged.

4. The method according to claim 1, characterized in that The sub-platform is further used to generate an alarm prompt message and send it to the SaaS platform when the target permission does not have the permission corresponding to the data access request; The SaaS platform is used to adjust the initial permission information according to the alarm prompt information.

5. The method according to claim 4, characterized in that The sub-platform is also used to record the access log corresponding to the data access operation and send the access log to the SaaS platform; The SaaS platform is used to adjust the initial permission information according to the access log and the alarm prompt information.

6. The method according to claim 1, characterized in that The SaaS platform is used to send the permission template to the sub-platform; The sub-platform is used to send the permission template to the user end for display, and receive the modification instruction of the permission template from the user end to modify the permission template accordingly, and send the modified permission information to the SaaS platform.

7. A permission control method, characterized in that: The method is applied to a sub-platform of a SaaS platform, and the method includes: Receiving initial permission information distributed by the SaaS platform, where the initial permission information is generated by the SaaS platform according to a permission template pre-configured for the sub-platform; assigning corresponding permissions to at least one user role according to the initial permission information; receiving a data access request and extracting role information in the data access request; Obtaining target permissions corresponding to the role information; When there is a permission corresponding to the data access request in the target permission, the corresponding data access operation is performed.

8. A permission control device, characterized in that: The device is applied to a sub-platform of a SaaS platform, and the device includes: A receiving module, configured to receive initial permission information distributed by the SaaS platform, wherein the initial permission information is generated by the SaaS platform according to a permission template pre-configured for the sub-platform; An allocation module, configured to allocate corresponding permissions to at least one user role according to the initial permission information; An access module, used to receive a data access request and extract role information in the data access request; An acquisition module, used to acquire target permissions corresponding to the role information; The execution module is used to execute the corresponding data access operation when there is a permission corresponding to the data access request in the target permission.

9. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method described in claim 7 are implemented.

10. 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 described in claim 7 are implemented.

Images