Distributed authority control method and system for double-cross-platform multi-team SaaS application scene

Abstract

The invention discloses a distributed permission control method and system for a double-cross-platform multi-team SaaS application scene. The method comprises the steps that a platform adaptation layer is designed; constructing a multi-dimensional variable permission control model (MDVM); optimizing a distributed architecture; and constructing authority monitoring and auditing. According to the invention, the real Internet of Things factory data is accessed into the double-cross system to simulate the equipment access authorization in normal operation and the cross-team cooperation scene, and the security compliance permission boundary is set, so that the risk of permission dispute and data leakage is effectively avoided, the overall working efficiency and the project advancing speed are greatly improved, and the project implementation cost is reduced. And a firm and powerful support is provided for multi-team collaborative operation. And finally, the application effects of high safety, high efficiency, high precision and precise authorization are achieved, and a traditional scheme is greatly improved and used in a wider range.

Description

Technical Field

[0001] The present invention relates to the technical field of distributed permission control. Specifically, it is a distributed permission control method and system for a dual-cross platform multi-team SaaS application scenario. Background Art

[0002] In the field of distributed permission control, the main control technical methods include role-based access control (RBAC), attribute-based access control (ABAC), and access control list (ACL). RBAC first defines roles and permissions and then associates users. Its defects are rigid roles, easy role explosion, and over-authorization because it does not fully consider individual and dynamic requirements due to relying on predefined roles. ABAC determines user, resource, and environmental attributes and judges permissions according to rules, having problems such as complex attribute management, high performance overhead, and difficult rule formulation, which stem from the high requirements of the system for comprehensive judgment of multiple attributes. ACL sets an access control list for resources, having defects such as poor scalability, lack of dynamics, and permission redundancy because it binds permissions based on resources and its flexibility is easily limited.

[0003] Generally speaking, the above-mentioned several types of control methods can be summarized as adopting a general fixed mode according to different dimensions. With the rapid development of software applications, a single control method can solve qualitative and quantitative permission problems, but it is difficult to cope with complex scenarios such as multiple teams, multiple roles, multiple scenarios, and cross-platform. This also poses a higher challenge to the distributed permission control for a dual-cross platform multi-team SaaS application scenario. How to enable tenants to have legal permission flexibility so that they can set fine-grained permissions according to multiple aspects such as teams, projects, and data scopes is also the core problem to be solved by this patent.

[0004] For example, in CN115208646B: A SaaS Application Permission Management Method and System, the control method of ACL is used to bind user information and application information and grant SaaS application permissions of tenant information to user information. Although it solves the problem of data isolation for multiple tenants, it cannot achieve dynamic authorization, the authorization is rigidified, and the extensibility of its system model is poor. In CN115906053A: A Distributed Permission Control System and Method, the control method of ACL is used, and security protection measures are added. Through the user permission consensus component, the relevant mutual recognition systems reach an agreement on the common state of user identity permissions, and unified identity permission management is carried out. Through relationship mutual recognition, after a user registers for identity and sets permissions in a unified security area, the user can directly enter any system in the security area, which reduces the burden on users and administrators, but its scalability is weak and it cannot cope with complex application scenarios of multiple tenants and multiple roles. Summary of the Invention

[0005] The object of the present invention is to provide a distributed permission control method and system for a dual-cross-platform multi-team SaaS application scenario, which is used to solve technical problems such as rigid authorized roles and complex and poorly scalable attribute management in the field of permission control in composite scenarios in the dual-cross-platform multi-team SaaS application scenario.

[0006] The present invention solves the above problems through the following technical solutions:

[0007] A distributed permission control method for a dual-cross-platform multi-team SaaS application scenario includes:

[0008] A. Platform adaptation layer design: Handle platform differences through interface abstraction and encapsulation, construct a general permission control interface specification, and create adaptation layer modules for different platforms. Automatically adapt according to the platform feature library to achieve stable operation of the dual-cross platform;

[0009] B. Construction of a multi-dimensional variable permission control model MDVM: Include team-level permission setting, multi-dimensional role permission allocation, and fine-grained data permission management, accurately configure permissions for each team and member, promote efficient cooperation among multiple teams, and ensure data security;

[0010] C. Distributed architecture optimization: Adopt an improved distributed consistency algorithm to ensure data consistency, establish an efficient data synchronization mechanism to reduce network overhead, and combine caching and load balancing strategies to improve system performance to handle large-scale concurrent access;

[0011] D. Construction of permission monitoring and auditing: Conduct real-time monitoring, record audit logs, and use machine learning and rule engines for anomaly detection and traceability to enhance system security and compliance.

[0012] As a further improvement, the specific steps of the platform adaptation layer design include:

[0013] A1.1) Interface abstraction and encapsulation: Develop a set of general permission control interface specifications, which define standard methods and data formats for various permission operations;

[0014] A1.2) Platform difference processing: Establish a platform feature library, classify and record the characteristic differences of different platforms in permission management; The adaptation layer automatically selects appropriate processing strategies according to the characteristics of the current platform during operation.

[0015] As a further improvement, the interface abstraction and encapsulation is: Construct platform adaptation layer modules for different platforms respectively, and these platform adaptation layer modules are responsible for mapping and converting the general interface specification with platform-specific system calls and APIs.

[0016] As a further improvement, the construction of the multi-dimensional variable permission control model MDVM specifically includes the following steps:

[0017] B2.1) Team top-level permission setting: Create an independent top-level permission domain for each team, and this top-level permission domain determines the permission scope of the team as a whole in the entire SaaS application;

[0018] B2.2) Multi-dimensional role permission allocation:

[0019] Define multiple role types, including team management roles, business roles, project roles, and custom roles; for each role type, based on its responsibilities in the team and project, allocate corresponding permissions, which not only cover the operation permissions of functional modules but also include the access permissions to data resources; data analysts can query, statistically analyze, etc. data, but cannot modify the original data;

[0020] Adopt a rule-based permission allocation engine, which dynamically generates and updates permission allocation rules according to multiple factors such as team structure, project progress, and user identity;

[0021] B2.3) Fine-grained data permission management:

[0022] Classify and label data resources, and determine different data levels according to factors such as the sensitivity of data resources and the business fields they belong to;

[0023] Set data access permission rules for different roles and team permission domains; in cross-team collaboration projects, set the access scope and operation permissions of specific teams to shared data according to project agreements.

[0024] As a further improvement, the permission scope at least includes the access permission to specific functional modules and the basic access level to shared data resources.

[0025] As a further improvement, the team top-level permission setting also includes:

[0026] Within the team, the tenant can further divide sub-permission domains according to actual needs. Each sub-permission domain can inherit part of the permissions of the team top-level permission domain and refine and expand them according to its own application scenarios.

[0027] As a further improvement, the optimization of the distributed architecture specifically includes the following steps:

[0028] C3.1) Improved distributed consistency algorithm:

[0029] Adopt a variant based on the Paxos algorithm to achieve data consistency in a multi-node permission data storage cluster;

[0030] In the preparation stage of the Paxos algorithm, nodes negotiate and determine a unique proposal number through message passing to ensure that only one node can propose a permission data update proposal at the same time;

[0031] In the acceptance stage of the Paxos algorithm, nodes verify and accept the received proposals;

[0032] At the same time, a pre-commit mechanism is introduced to reduce unnecessary message passing and verification steps;

[0033] C3.2) Efficient data synchronization mechanism:

[0034] Establish a permission data change log to record each update operation of the permission data; when a node updates the permission data, broadcast the change log to other nodes;

[0035] After other nodes receive the change log, update the local permission data according to the information in the log;

[0036] Utilize incremental synchronization technology to reduce the network overhead of data synchronization;

[0037] C3.3) Cache and load balancing strategy:

[0038] Set up a permission data cache on each node to cache the frequently accessed permission data, so as to reduce the access pressure on the underlying storage system and improve the speed of permission verification; adopt a cache eviction mechanism that combines the least recently used frequency and time expiration strategy to ensure that the data in the cache is always hot data and maintains a certain freshness;

[0039] Deploy a load balancer; evenly distribute permission verification requests to different nodes according to the load conditions of the nodes; the load balancer communicates with the nodes regularly to obtain the load information of the nodes, and performs request allocation according to the preset load balancing algorithm, and distributes more requests to the nodes with lighter loads.

[0040] As a further improvement to it, the construction of permission monitoring and auditing specifically includes the following steps:

[0041] D4.1) Real-time monitoring function:

[0042] Perform real-time monitoring on all permission operations in the permission system, capture information related to permission operations by instrumenting at key permission control interfaces;

[0043] Establish a monitoring metric system to statistically analyze the frequency, type distribution, and abnormal situation ratio of permission operations;

[0044] D4.2) Audit log recording:

[0045] Record all permission operation information in the audit log. The audit log adopts a structured storage format for easy subsequent query and analysis;

[0046] Regularly back up and archive the audit log to ensure the security and integrity of the log data. At the same time, set a log retention policy. According to requirements and the compliance needs within the enterprise, determine the retention period of the audit log, and the expired log data will be securely deleted;

[0047] D4.3) Anomaly Detection and Tracing:

[0048] Use a combination of machine learning algorithms and rule engines to perform anomaly detection on permission operations;

[0049] When an abnormal operation is detected, the audit module can quickly trace the source of the abnormal operation.

[0050] As a further improvement, the machine learning algorithm learns from historical permission operation data to establish a model of normal permission operations. When a new permission operation deviates significantly from the model prediction result, it is marked as an abnormal operation;

[0051] The rule engine checks permission operations according to predefined security rules, and an operation that violates the rules is an abnormal operation.

[0052] Meanwhile, the present invention also solves the above problems through the following technical solutions:

[0053] A distributed permission control system for a dual-cross-platform multi-team SaaS application scenario, used to implement the distributed permission control method for the dual-cross-platform multi-team SaaS application scenario as described above. The distributed permission control system includes:

[0054] A platform adaptation layer module for platform adaptation layer design: handle platform differences through interface abstraction and encapsulation, build a general permission control interface specification, and create an adaptation layer module for different platforms. Automatically adapt according to the platform feature library to achieve stable operation on dual-cross platforms;

[0055] An MDVM construction module for constructing a multi-dimensional variable permission control model MDVM: including team-level permission setting, multi-dimensional role permission allocation, and fine data permission management, accurately configure permissions for each team and member, promote efficient cooperation among multiple teams, and ensure data security;

[0056] A distributed architecture optimization module for ensuring data consistency by using an improved distributed consensus algorithm, establishing an efficient data synchronization mechanism to reduce network overhead, and combining caching and load balancing strategies to improve system performance to handle large-scale concurrent access;

[0057] A privilege monitoring and auditing module is used to construct privilege monitoring and auditing to monitor in real time, record audit logs, and perform anomaly detection and traceability using machine learning and rule engines, enhancing system security and compliance.

[0058] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0059] By accessing real Internet of Things factory data in a dual-cross system to simulate device access authorization during normal operation and cross-team cooperation scenarios, the present invention effectively avoids the risks of privilege disputes and data leakage by setting secure and compliant privilege boundaries, greatly improving the overall work efficiency and project progress speed, and providing strong support for multi-team collaborative operations. Ultimately, it achieves the application effects of high security, high efficiency, high precision, and precise authorization, with significant improvements and broader usage scenarios compared to traditional solutions. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] Figure 1 It is a flowchart of authorization for a distributed privilege control method for a dual-cross platform multi-team SaaS application scenario of the present invention;

[0061] Figure 2 It is a flowchart of implementation for a distributed privilege control method for a dual-cross platform multi-team SaaS application scenario of the present invention;

[0062] Figure 3 It is a block diagram of a distributed privilege control system for a dual-cross platform multi-team SaaS application scenario of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0063] To make the objectives, technical solutions, and advantages of the present application clearer, the technical solutions in the preferred embodiments of the present application will be described in more detail below with reference to the accompanying drawings in the preferred embodiments of the present application. In the drawings, the same or similar reference numerals represent the same or similar components or components with the same or similar functions throughout. The described embodiments are some, but not all, of the embodiments of the present application. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to explain the present application, and should not be construed as limiting the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts shall fall within the scope of protection of the present application.

[0064] The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0065] In the description of the present application, it should be noted that, unless otherwise clearly specified and limited, the terms "installation", "connection", and "coupling" should be understood in a broad sense. For example, it can be a fixed connection, or indirectly connected through an intermediate medium, and can be the communication inside two components or the interaction relationship between two components. For those of ordinary skill in the art, the specific meanings of the above terms in the present application can be understood according to specific circumstances.

[0066] In the description of the present application, it should be understood that the orientation or positional relationship indicated by the terms "upper", "lower", "front", "rear", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc. is the orientation or positional relationship based on the drawings, and is only for the convenience of describing the present application and simplifying the description, rather than indicating or implying that the device or component referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus cannot be understood as a limitation to the present application.

[0067] In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or display that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products, or displays.

[0068] The following will be combined with Figures 1-3 to elaborate in detail on a distributed permission control method and system for a dual-cross-platform multi-team SaaS application scenario involved in the embodiments of the present application. It should be noted that the following embodiments are only used to explain the present application and do not constitute a limitation to the present application.

[0069] Embodiment:

[0070] Combined with the attached Figures 1-2 shown, a distributed permission control method for a dual-cross-platform multi-team SaaS application scenario mainly covers the following four core parts:

[0071] A. Platform adaptation layer design: Handle platform differences through interface abstraction and encapsulation, construct a general permission control interface specification, and create an adaptation layer module for different platforms. Automatically adapt according to the platform feature library to achieve stable operation of the dual-cross platform;

[0072] Specifically, the following is the detailed implementation process:

[0073] 1.1) Interface abstraction and encapsulation:

[0074] Develop a set of general permission control interface specifications, which define the standard methods and data formats for various permission operations, such as user permission acquisition interfaces, permission verification interfaces, permission update interfaces, etc.

[0075] For different platforms including but not limited to Windows, Linux, iOS, Android, etc., construct platform adaptation layer modules respectively. These platform adaptation layer modules are responsible for mapping and converting the general interface specifications to platform-specific system calls and APIs. For example, on the iOS platform, the platform adaptation layer uses the iOS security framework and local storage mechanism to implement the storage and reading of permission data, and converts the general permission verification request into code logic recognizable by the iOS system for processing; on the Linux platform, it completes the corresponding adaptation work by means of its file system permission management and user authentication mechanism.

[0076] 1.2) Platform difference handling:

[0077] Establish a platform feature library to classify and record the characteristic differences of different platforms in permission management, such as the user authentication methods of different platforms (differences in password encryption algorithms, support levels of biometric technologies, etc.), permission data storage formats (differences in registry, configuration files, databases, etc.), and differences in permission granularity.

[0078] The adaptation layer automatically selects appropriate processing strategies according to the characteristics of the current platform at runtime. For example, when it is detected that the platform is Android and the device supports fingerprint recognition, the adaptation layer will preferentially enable the fingerprint recognition permission verification process and return the verification result to the upper-layer permission control module according to the general interface specification.

[0079] B. Construction of the multi-dimensional variable permission control model MDVM: including team-level permission setting, multi-dimensional role permission allocation, and fine-grained data permission management, accurately configure permissions for each team and its members, promote efficient cooperation among multiple teams, and ensure data security;

[0080] Specifically, the following is the detailed implementation process:

[0081] 2.1) Team top-level permission setting:

[0082] Create an independent top-level permission domain for each team, which determines the overall permission scope of the team in the entire SaaS application, such as access permissions to specific function modules, basic access levels to shared data resources, etc.

[0083] Within the team, tenants can further divide sub - permission domains according to actual needs, such as by role. Each sub - permission domain can inherit some permissions of the team's top - level permission domain and be refined and extended according to its own application scenario. For example, Project A team under a R & D team inherits the team's access permission to the code repository and adds the permission to modify specific branch codes on this basis.

[0084] 2.2) Multi - dimensional role - based permission allocation:

[0085] Define multiple role types, including team management roles (such as team leaders, administrators), business roles (such as data entry clerks, data analysts), project roles (such as project managers, project members), etc. and custom roles to make it highly extensible.

[0086] For each role type, based on its responsibilities in the team and project, allocate corresponding permissions. These permissions not only cover the operation permissions of function modules but also include the access permissions to data resources. For example, the data entry clerk role may have the permission to create and edit specific data forms but not the permission to delete data; while the data analyst role can query, statistically analyze, etc. the data but cannot modify the original data.

[0087] Adopt a rule - based permission allocation engine that dynamically generates and updates permission allocation rules according to various factors such as team structure, project progress, user identity, etc. For example, when a project enters the testing phase, the permission allocation engine will automatically adjust the permissions of project members, restrict developers' access to production environment data, and grant testers more testing - related permissions.

[0088] 2.3) Fine - grained data permission management:

[0089] Classify and label data resources, and determine different data levels according to factors such as data sensitivity and the business domain to which it belongs. For example, mark the financial data of customers as high - sensitive level and the basic information of products as low - sensitive level.

[0090] Set data access permission rules for different roles and team permission domains. These rules can be defined based on conditions such as data level, the project or department to which the data belongs, etc. For example, only the financial staff of the team can access high - sensitive financial data, while other team members can only access low - sensitive data; in cross - team collaboration projects, set the access scope and operation permissions (such as read - only or editable) of specific teams to shared data according to the project agreement.

[0091] C. Distributed architecture optimization:

[0092] Adopt an improved distributed consistency algorithm to ensure data consistency, establish an efficient data synchronization mechanism to reduce network overhead, and combine caching and load balancing strategies to improve system performance to handle large-scale concurrent access;

[0093] Specifically, the following is the detailed implementation process:

[0094] 3.1) Improved distributed consistency algorithm:

[0095] Adopt a variant based on the Paxos algorithm to achieve data consistency in a multi-node permission data storage cluster. In the preparation stage of the algorithm, nodes negotiate to determine a unique proposal number through message passing to ensure that only one node can propose a permission data update proposal at the same time.

[0096] In the acceptance stage, nodes verify and accept the received proposals. If the majority of nodes accept the same proposal, the permission data update operation in the proposal will be applied to all nodes. At the same time, to improve the efficiency of the algorithm, a pre-commit mechanism is introduced to reduce unnecessary message passing and verification steps. For example, after a node receives a proposal, it first performs a pre-commit. If the pre-commit is successful, it means that the proposal has a high probability of being accepted by the majority of nodes, and thus some local preparatory work can be carried out in advance, such as pre-updating the local cache, etc.

[0097] 3.2) Efficient data synchronization mechanism:

[0098] Establish a permission data change log to record each permission data update operation, including information such as the update time, update content, and update initiator. When a node updates permission data, it broadcasts the change log to other nodes.

[0099] After other nodes receive the change log, they update the local permission data according to the information in the log. To ensure the accuracy and integrity of data synchronization, a data dynamic version number mechanism is adopted. Each permission data has a corresponding version number. When a node updates data, it first compares the local data version number with the version number in the change log. If the local version number is lower than the version number in the change log, it performs the update; otherwise, it means that the local data is already the latest and ignores the change log.

[0100] Utilize incremental synchronization technology to reduce the network overhead of data synchronization. For example, when a permission update only involves the modification of some data fields, only the modified field content is synchronized instead of the entire permission data record.

[0101] 3.3) Caching and load balancing strategies:

[0102] Set permission data cache on each node to cache frequently accessed permission data, reducing the access pressure on the underlying storage system and improving the speed of permission verification. Adopt a cache eviction mechanism that combines the least recently used (LRU) and time expiration strategies to ensure that the data in the cache is always hot data and maintains a certain freshness.

[0103] 3.4) Deploy a load balancer to evenly distribute permission verification requests to different nodes according to the load conditions of the nodes (such as CPU usage, memory usage, the number of current permission requests being processed, etc.). The load balancer communicates with the nodes regularly to obtain the load information of the nodes and distributes requests according to the preset load balancing algorithms (such as round-robin, weighted round-robin, least connections, etc.). For example, when it is found that the CPU usage of a certain node is too high, the load balancer will reduce the number of requests allocated to that node and allocate more requests to the nodes with lighter loads.

[0104] D. Build permission monitoring and auditing: For real-time monitoring, record audit logs and use machine learning and rule engines for anomaly detection and tracing to enhance system security and compliance.

[0105] Specifically, the following is the detailed implementation process:

[0106] 4.1) Real-time monitoring function:

[0107] Conduct real-time monitoring on all permission operations in the permission system, including events such as user login, permission acquisition, permission update, permission verification failure, etc. By inserting monitoring points at key permission control interfaces, capture information related to permission operations, such as the operation time, the user or system component performing the operation, and the permission resources involved in the operation.

[0108] Establish a monitoring metric system to statistically analyze the frequency, type distribution, proportion of abnormal situations, etc. of permission operations. For example, count the number of permission acquisitions of a specific user within a certain time period, analyze the proportion of different types of permission operations (such as data access permissions, function operation permissions), and promptly discover abnormal permission operation patterns, such as a certain user frequently requesting highly sensitive permission resources within a short period of time.

[0109] 4.2) Audit log recording:

[0110] Record all permission operation information in the audit log. The audit log adopts a structured storage format for easy subsequent query and analysis. The log content includes detailed permission operation records, operation results (success or failure), and the corresponding request and response data of the operation (if any).

[0111] Regularly back up and archive the audit logs to ensure the security and integrity of the log data. At the same time, set a log retention policy to determine the retention period of the audit logs according to requirements and the compliance needs within the enterprise. Expired log data will be securely deleted.

[0112] 4.3) Anomaly Detection and Tracing:

[0113] Use a combination of machine learning algorithms and rule engines to detect anomalies in permission operations. The machine learning algorithm learns from historical permission operation data to establish a model of normal permission operations. When a new permission operation deviates significantly from the model prediction result, it is marked as an abnormal operation. The rule engine checks permission operations according to predefined security rules, such as prohibiting certain permission operations within a specific time period and allowing specific users to perform permission operations only within a specific IP address range. An operation that violates the rules is considered an abnormal operation.

[0114] When an abnormal operation is detected, the audit module can quickly trace the source of the abnormal operation. By querying the audit logs and relevant system records, it can determine information such as the initiator of the abnormal operation, the operation path, and the permission resources involved, providing strong support for the investigation and handling of security incidents.

[0115] In a specific embodiment, a distributed permission control method for a dual-cross-platform multi-team SaaS application scenario. The following is the specific implementation method of the distributed permission control method for building digital smart factory groups such as H, S, and J:

[0116] I. Design and Implementation of the Platform Adaptation Layer:

[0117] For different industrial platforms used by factories such as H, S, and J, such as the specific industrial Linux platform of Factory H, the industrial Windows system of Factory S, and the industrial Android system of Factory J, deeply explore their underlying permission management mechanisms and interface specifications. Based on this, carefully design a unified and highly adaptable general permission control interface specification, clearly defining the standard processes and data formats for key permission operations such as obtaining device operation permissions, verifying production data access permissions, and updating system function permissions. For example, for the device operation permission acquisition interface, determine to transmit data such as device identification, user identity information, and the requested permission type in a standardized XML format, so that each platform adaptation layer can accurately understand and process.

[0118] Build the adaptation layer module. In the industrial Linux adaptation layer of Factory H, make full use of the security modules of Linux (such as SELinux) and its powerful command-line tools and system call interfaces to convert the operations in the general permission control interface specification into permission management instructions recognizable by the Linux system. For example, when processing the production data access permission verification, the adaptation layer interacts with the Linux file system permission mechanism, determines whether to allow access based on the permission settings of the data storage directory and the user group information to which the user belongs, and returns the result after formatting according to the general interface specification. For the industrial Windows adaptation layer of Factory S, with the help of Windows domain management policies, group policies, and rich API sets, achieve the permission control adaptation of enterprise resource management systems (ERP), manufacturing execution systems (MES), etc. on the Windows platform. For example, through the combination of Windows services and relevant permission management APIs, achieve the permission verification and control of users logging in to specific systems. The industrial Android adaptation layer of Factory J uses the Android security framework and permission management APIs, such as the permission declarations in AndroidManifest.xml and the runtime permission request mechanism, to dock the general permission control interface specification with the Android system. For example, when controlling the remote operation permission of intelligent handheld devices for production workshop equipment, the adaptation layer determines the permission based on the Bluetooth or Wi-Fi connection status of the device and the authentication information of the user in the Android system, and feeds back the result to the upper layer. The adaptation layer monitors the characteristic information of each factory platform in real time, such as system version, network configuration, device type, etc., matches it with the pre-built factory group platform characteristic library, and selects the optimal permission processing strategy. If it is detected that the network environment of Factory H is upgraded to support a higher-level encryption protocol, the adaptation layer automatically switches the permission data transmission method to ensure data security and integrity.

[0119] II. Construction and implementation of the multi-dimensional variable permission control model MDVM:

[0120] System administrators create independent and highly customized top-level permission domains for teams within each factory (such as production teams, R & D teams, quality control teams, etc.) and cross-factory collaboration teams according to the respective organizational structures of factories H, S, J, etc. and the collaborative production business processes of the entire factory group. For example, the production team of Factory H can access its internal MES system and has corresponding permissions for adjusting production line equipment parameters, querying and modifying production progress, etc.; the R & D team of Factory S can operate its dedicated product R & D platform and perform permission operations such as new product design and formulation of process improvement plans; the quality control team of Factory J has the right to view inspection standards, enter inspection data, and generate quality reports, etc. in the quality management system.

[0121] In terms of the subdivision of internal team permission domains, fine-grained division is carried out driven by production tasks, R & D projects, etc. Taking the production team of H Factory as an example, sub-permission domains are created for different product production lines (such as the home appliance production line and the electronic equipment production line). The sub-permission domain of the home appliance production line inherits the access permission of the top-level permission domain of the production team to the home appliance production module in the MES system and refines it to the permissions of different production process positions. For example, employees in the front-end material preparation position of the production line can only perform operations such as material inventory query and application, while employees in the middle-section assembly position can perform operations such as component assembly, preliminary quality inspection, and adjustment of some equipment parameters. At the same time, multiple role types are defined. For example, the line leader role in the production team can temporarily allocate the permissions of personnel on this production line, view production reports, and conduct preliminary handling of abnormal situations; ordinary production workers can only perform specified production operations on the equipment corresponding to their own positions. The rule-based permission allocation engine dynamically generates and updates permission allocation rules based on factors such as team structure, project progress (such as the trial production stage and mass production stage of new products), and user identity (such as employee skill level and training experience). For example, when a new product is in trial production at H Factory, R & D team members may be temporarily granted the permission to fine-tune the parameters of new equipment at the production site, and this permission will be withdrawn during the mass production stage to ensure production stability. In cross-factory collaboration teams, such as the joint product R & D project jointly carried out by H, S, and J, different sub-permission domains are set for members according to the characteristics of members from different factories and project requirements. Members from S Factory with strong R & D capabilities may be given more editing permissions for the core technology R & D part of the project, while members from H Factory with rich production and manufacturing experience have more permissions in process verification and production feasibility assessment to give full play to the advantages of each member and promote the smooth progress of cross-factory projects.

[0122] III. Optimization and Implementation of Distributed Architecture

[0123] Adopt a distributed consensus algorithm based on a variant of the Paxos algorithm. In a multi-node permission data storage cluster such as factory clusters H, S, and J (including data center nodes, edge computing nodes, etc. within each factory), in the preparation phase, nodes send proposal number requests through a reliable message passing protocol based on industrial Ethernet or 5G industrial private network and wait for responses. Determine the proposal eligibility according to the importance of the factory where the node is located, the data processing capacity, and the role in the collaborative production of the factory cluster. For example, the data center node of Factory H has a higher priority when processing proposals for updating permission data across the entire factory cluster. The proposal content includes details such as modifications to the production permission policy for a certain type of product. After broadcasting it to other nodes, in the acceptance phase, multiple verifications are carried out, such as verifying whether it complies with the safety specifications and production process requirements of the factory cluster. When the majority of nodes accept the proposal, apply the update operation, and through the pre-commit mechanism, nodes simulate the execution of the update locally and record performance metrics. If the pre-commit is successful, other nodes can prepare resources in advance, such as pre-updating the relevant production permission data index in the local cache.

[0124] Establish a permission data change log to record information such as modifications to production process parameter permissions and adjustments to personnel position permissions. When the permission data of a certain factory node is updated, broadcast the change log through the industrial network of the factory cluster. After other nodes receive it, judge whether to update according to the data version number mechanism. If the local version number is low, update the local permission data according to the incremental information in the log (such as only updating the modified production process parameter permission field) to reduce the network overhead of data synchronization. For example, after Factory S optimizes and adjusts a certain production process parameter and updates the permission data, Factory H and Factory J only need to update the part of the permission data related to this process parameter according to the incremental information in the change log, without reloading the entire process permission data set.

[0125] Set up a production permission data cache at each node, and adopt a cache eviction mechanism that combines the least recently used frequency and time expiration strategy. For example, the permission data of production line equipment that is frequently accessed is preferentially retained in the cache. Deploy a load balancer, and distribute permission verification requests to different nodes according to algorithms such as weighted round-robin based on the CPU usage rate, memory usage rate, and the current number of production permission requests processed by the node. For example, during the production peak period, distribute more permission verification requests to the data center node of Factory H with stronger data processing capabilities to ensure the overall production efficiency.

[0126] IV. Build Permission Monitoring and Audit Implementation

[0127] Implement data logging at key permission control interfaces, such as production equipment login interfaces and MES system permission operation interfaces, to capture permission operation information, including operation time, operator ID, production resources involved in the operation (such as equipment number, product batch number), etc., and establish a monitoring index system. For example, count the permission operation frequency of different factories within a unit time and analyze the proportion of abnormal permission operations. If a large number of abnormal permission operations occur on a certain production line in Factory J within a short period (such as frequent attempts to exceed job permissions), issue a warning in a timely manner.

[0128] Record the permission operation information in a structured format (such as a database table) in the audit log and regularly back it up to the data backup server shared by the factory group. Determine the retention period of the audit log according to relevant regulations and internal regulations of the factory group, such as retaining it for 3 years. Delete the expired log data through a secure deletion program to ensure data security.

[0129] Use machine learning algorithms (such as clustering analysis algorithms) to learn from historical permission operation data and establish a normal permission operation model. For example, cluster according to the permission operation patterns of employees in different positions during the normal production cycle. When a new permission operation deviates significantly from the model (such as an employee performing high-privilege operations during non-working hours), mark it as an abnormal operation. At the same time, the rule engine checks according to predefined security rules (such as certain permissions are prohibited in a specific production area at a specific time). When an abnormal operation is detected, trace the source of the abnormal operation by querying the audit log and relevant system records, such as determining which factory, which production line, which equipment, and which employee initiated the abnormal operation, providing strong support for the investigation and handling of security incidents.

[0130] In an optional embodiment, a distributed permission control system for a dual-cross-platform multi-team SaaS application scenario, combined with the attached Figure 3 As shown, it is used to implement the distributed permission control method for the dual-cross-platform multi-team SaaS application scenario as described above. The distributed permission control system includes:

[0131] A platform adaptation layer module for platform adaptation layer design: handle platform differences through interface abstraction and encapsulation, build a general permission control interface specification, and create an adaptation layer module for different platforms. Automatically adapt according to the platform feature library to achieve stable operation of the dual-cross platform;

[0132] An MDVM construction module for constructing a multi-dimensional variable permission control model MDVM: including team-level permission setting, multi-dimensional role permission allocation, and fine-grained data permission management, accurately configure permissions for each team and member, promote efficient cooperation among multiple teams, and ensure data security;

[0133] The distributed architecture optimization module is used to ensure data consistency by adopting an improved distributed consensus algorithm, establish an efficient data synchronization mechanism to reduce network overhead, combine caching and load balancing strategies to improve system performance, and cope with large-scale concurrent access;

[0134] The permission monitoring and auditing module is used to construct permission monitoring and auditing to monitor in real time, record audit logs, and use machine learning and rule engines for anomaly detection and traceability, enhancing system security and compliance.

[0135] Although the present invention has been described herein with reference to illustrative embodiments of the present invention, the above embodiments are only preferred embodiments of the present invention, and the embodiments of the present invention are not limited by the above embodiments. It should be understood that those skilled in the art can design many other modifications and embodiments, which will fall within the scope of the principles and spirit disclosed in this application.

Claims

1. A distributed permission control method for SaaS application scenarios of dual-cross platforms and multiple teams, characterized in that Including: A. Platform Adaptation Layer Design: Handle platform differences through interface abstraction and encapsulation, build a general permission control interface specification, create adaptation layer modules for different platforms, and automatically adapt according to the platform feature library to achieve stable operation across dual platforms; B. Construction of the Multidimensional Variable Permission Control Model MDVM: Include team-level permission setting, multi-dimensional role permission allocation, and fine-grained data permission management, accurately configure permissions for each team and member, promote efficient collaboration among multiple teams, and ensure data security; C. Distributed Architecture Optimization: Use an improved distributed consistency algorithm to ensure data consistency, establish an efficient data synchronization mechanism to reduce network overhead, combine caching and load balancing strategies to improve system performance, and handle large-scale concurrent access; D. Construction of Permission Monitoring and Auditing: Conduct real-time monitoring, record audit logs, and use machine learning and rule engines for anomaly detection and traceability to enhance system security and compliance.

2. The distributed permission control method for the SaaS application scenario facing two cross-platform multi-teams according to claim 1, characterized in that, The specific steps of the platform adaptation layer design include: A1.1) Interface Abstraction and Encapsulation: Develop a set of general permission control interface specifications that define the standard methods and data formats for various permission operations; A1.2) Platform Difference Handling: Establish a platform feature library, classify and record the characteristic differences of different platforms in permission management; the adaptation layer automatically selects appropriate processing strategies according to the characteristics of the current platform during operation.

3. The distributed permission control method for the dual-cross-platform multi-team SaaS application scenario according to claim 2, wherein, The interface abstraction and encapsulation means: Build platform adaptation layer modules for different platforms respectively, and these platform adaptation layer modules are responsible for mapping and converting the general interface specification with platform-specific system calls and APIs.

4. The distributed permission control method for the dual-cross-platform multi-team SaaS application scenario according to claim 1, characterized in that, The specific steps of the construction of the Multidimensional Variable Permission Control Model MDVM include: B2.1) Team Top-Level Permission Setting: Create an independent top-level permission domain for each team, and this top-level permission domain determines the overall permission scope of the team in the entire SaaS application; B2.2) Multi-Dimensional Role Permission Allocation: Define multiple role types, including team management roles, business roles, project roles, and custom roles; for each role type, based on its responsibilities in the team and project, allocate corresponding permissions, which not only cover the operation permissions of function modules but also include the access permissions to data resources; data analysts can query, statistically analyze, etc. data but cannot modify the original data; Adopt a rule-based permission allocation engine that dynamically generates and updates permission allocation rules according to multiple factors such as team structure, project progress, and user identity; B2.3) Fine-Grained Data Permission Management: Classify and label data resources, and determine different data levels according to factors such as the sensitivity of data resources and the business areas they belong to; Set data access permission rules for different roles and team permission domains; in cross-team collaboration projects, set the access scope and operation permissions of specific teams to shared data according to the project agreement.

5. The distributed permission control method for the dual-cross-platform multi-team SaaS application scenario according to claim 4, characterized in that, The permission scope includes at least the access permission to specific function modules and the basic access level to shared data resources.

6. The distributed permission control method for the dual-cross-platform multi-team SaaS application scenario according to claim 4, wherein The team top-level permission setting also includes: Within the team, tenants can further divide sub - permission domains according to actual needs. Each sub - permission domain can inherit some permissions of the team's top - level permission domain and refine and expand them according to its own application scenarios.

7. The distributed permission control method for the dual-cross-platform multi-team SaaS application scenario according to claim 1, wherein The optimization of the distributed architecture specifically includes the following steps: C3.1) Improved distributed consistency algorithm: Adopt a variant based on the Paxos algorithm to achieve data consistency in the permission data storage cluster of multiple nodes; In the preparation stage of the Paxos algorithm, nodes negotiate to determine a unique proposal number through message passing to ensure that only one node can propose a permission data update proposal at the same moment; In the acceptance stage of the Paxos algorithm, nodes verify and accept the received proposals; At the same time, introduce a pre - submission mechanism to reduce unnecessary message passing and verification steps; C3.2) Efficient data synchronization mechanism: Establish a permission data change log to record each update operation of the permission data; when a node updates the permission data, broadcast the change log to other nodes; After other nodes receive the change log, update the local permission data according to the information in the log; Utilize incremental synchronization technology to reduce the network overhead of data synchronization; C3.3) Cache and load - balancing strategy: Set up a permission data cache on each node to cache frequently accessed permission data, reducing the access pressure on the underlying storage system and improving the speed of permission verification; adopt a cache eviction mechanism that combines the least recently used frequency and time - expiration strategy to ensure that the data in the cache is always hot data and maintains a certain freshness; C3.4) Deploy a load - balancer; evenly distribute permission verification requests to different nodes according to the load conditions of the nodes; the load - balancer communicates with the nodes regularly to obtain the load information of the nodes and performs request distribution according to the preset load - balancing algorithm, distributing more requests to the nodes with lighter loads.

8. The distributed permission control method for the dual-cross-platform multi-team SaaS application scenario according to claim 1, characterized in that, The construction of permission monitoring and auditing specifically includes the following steps: D4.1) Real - time monitoring function: Perform real - time monitoring on all permission operations in the permission system by embedding points at key permission control interfaces to capture information related to permission operations; Establish a monitoring index system to statistically analyze the frequency, type distribution, and proportion of abnormal situations of permission operations; D4.2) Audit log recording: Record all permission operation information into the audit log. The audit log adopts a structured storage format for easy subsequent query and analysis; Regularly back up and archive the audit log to ensure the security and integrity of the log data; at the same time, set a log retention policy to determine the retention period of the audit log according to requirements and the compliance needs within the enterprise, and the expired log data will be safely deleted; D4.3) Anomaly detection and traceability: Use a combination of machine - learning algorithms and rule engines to perform anomaly detection on permission operations; When an abnormal operation is detected, the audit module can quickly trace the source of the abnormal operation.

9. The distributed permission control method for the dual-cross-platform multi-team SaaS application scenario according to claim 8, wherein The machine - learning algorithm learns from historical permission operation data to establish a model of normal permission operations. When a new permission operation deviates significantly from the model prediction result, it is marked as an abnormal operation; The rules engine checks the permission operations according to predefined security rules, and any operation that violates the rules is regarded as an abnormal operation.

10. A distributed permission control system for the SaaS application scenario of dual cross-platform and multi-team, characterized in that, For implementing the distributed permission control method for the dual-cross platform multi-team SaaS application scenario as described in any one of claims 1-9, the distributed permission control system includes: A platform adaptation layer module for designing the platform adaptation layer: handling platform differences through interface abstraction and encapsulation, constructing a general permission control interface specification and creating an adaptation layer module for different platforms, and automatically adapting according to the platform feature library to achieve stable operation across dual platforms; An MDVM construction module for constructing the multi-dimensional variable permission control model MDVM: including team-level permission setting, multi-dimensional role permission allocation, and fine-grained data permission management, accurately configuring permissions for each team and member, promoting efficient cooperation among multiple teams and ensuring data security; A distributed architecture optimization module for ensuring data consistency by adopting an improved distributed consensus algorithm, establishing an efficient data synchronization mechanism to reduce network overhead, and combining caching and load balancing strategies to improve system performance to handle large-scale concurrent access; A permission monitoring and auditing module for constructing permission monitoring and auditing to monitor in real time, record audit logs, and use machine learning and rules engines for anomaly detection and traceability to enhance system security and compliance.

Images