Hierarchical role permission dynamic authorization management system and method

Abstract

The application relates to the technical field of role permission dynamic authorization, and discloses a hierarchical role permission dynamic authorization management and control system and method, which comprises the following steps: constructing a post ability graph according to multi-tenant organization framework data, collecting current environment data of a user to generate a scene fingerprint vector, and matching to obtain a first permission set; analyzing an application reason to generate an application form, analyzing an application risk of the application form and calculating a risk value, dynamically selecting an approval path for authorization, and generating a first drift token; in a user session process, analyzing real-time operation behavior of the user, performing permission degradation on the first drift token triggering a preset risk behavior, and obtaining a second drift token; simulating and analyzing permission use in a user operation process and calculating use entropy, screening out permissions with use entropy lower than a preset use threshold, and generating a permission deviation heat map, and canceling corresponding authorization according to the permission deviation heat map; and the application can improve permission dynamic management and control efficiency and configuration quality.

Description

Technical Field

[0001] This application relates to the field of dynamic role-based permission authorization technology, and more specifically to a hierarchical dynamic role-based permission authorization control system and method. Background Technology

[0002] Currently, the permission management of multi-tenant SaaS platforms is based on a role-based access control model for permission allocation. However, permission allocation is disconnected from the user's actual working environment and cannot be dynamically adjusted according to context such as network location, device trustworthiness, and access time. The permission application and approval process is fixed and rigid, and it cannot distinguish between low-risk read-only operations and high-risk data export operations, resulting in slow response in emergency situations and redundant processes in non-emergency situations.

[0003] Existing technologies have the following problems: a single permission allocation method cannot dynamically adjust the scope of permissions based on environmental factors such as user network location, device trustworthiness, and access time, posing security risks; a fixed approval chain cannot be dynamically adjusted according to the application risk level, resulting in slow response in emergencies and wasted approval resources in non-emergency situations; once authorized, user permissions remain unchanged during the session, making it impossible to intervene in abnormal behaviors such as large-scale data export within a short period; permissions cannot be promptly cleared after employee job changes or departures, constituting a security vulnerability. To address at least one of the above problems, this application proposes a hierarchical role-based dynamic authorization control system and method. Summary of the Invention

[0004] To address the shortcomings of existing technologies, the purpose of this application is to provide a hierarchical role-based access control system and method, which can effectively solve the problems in the background technology. The specific technical solution of this application is as follows:

[0005] Hierarchical role-based access control methods include:

[0006] A job competency graph is constructed based on multi-tenant organizational structure data. User current environment data is collected to generate scenario fingerprint vectors. The traversal results of user jobs in the job competency graph are matched with scenario fingerprint vectors to obtain the first permission set.

[0007] In response to a shadow permission request in the first permission set, the request reason is parsed to generate an application form, the application risk of the application form is analyzed and the risk value is calculated, and the approval path is dynamically selected for authorization, generating the first drift token;

[0008] During a user session, authentication is performed based on the first drift token. The user's real-time operational behavior is analyzed, and the permissions of the first drift token that triggers a preset risk behavior are downgraded to obtain the second drift token.

[0009] Based on the second drift token, the user operation process is simulated and analyzed to determine the use of permissions and calculate the usage entropy. Permissions with usage entropy lower than the preset usage threshold are selected and a permission deviation heatmap is generated. Based on the permission deviation heatmap, the corresponding authorization is cancelled to dynamically control the authorization of role permissions.

[0010] Specifically, the process involves constructing a job competency graph based on multi-tenant organizational structure data, collecting the user's current environment data to generate a scene fingerprint vector, and matching the user's job traversal results in the job competency graph with the scene fingerprint vector to obtain a first permission set, including:

[0011] Based on multi-tenant organizational structure data, analyze job relationships and construct job competency maps;

[0012] Collect the user's current environment data and input it into a preset scene fingerprint generation model to generate a scene fingerprint vector;

[0013] The first permission set is obtained by matching the traversal results of the user's job position in the job competency graph with the scene fingerprint vector.

[0014] Specifically, the step of analyzing job relationships and constructing a job competency map based on multi-tenant organizational structure data includes:

[0015] Based on multi-tenant organizational structure data, analyze job relationships, and construct the first job competency graph with each job as a node and the job relationships between jobs as edges.

[0016] Configure corresponding job attributes for each job node in the first job competency graph, and configure corresponding relationship types for each edge to obtain the job competency graph.

[0017] Specifically, the step of matching the user's job position traversal results in the job competency graph with the scene fingerprint vector to obtain the first permission set includes:

[0018] Based on the current user's job identifier, starting from the job node corresponding to the job identifier, traverse along the connection relationship in the job competency graph, integrate the permission items of the nodes on the traversal path, and obtain the user's initial permission set.

[0019] Analyze the scenario fingerprint range configured for each permission item in the initial permission set;

[0020] The scene fingerprint vector is compared with the scene fingerprint range. If the scene fingerprint vector is within the scene fingerprint range, the corresponding permission item is divided into an available permission subset. If the scene fingerprint vector is outside the scene fingerprint range, the corresponding permission item is divided into a shadow permission subset.

[0021] The available permission subset and the shadow permission subset are integrated to obtain the first permission set.

[0022] Specifically, in response to a shadow permission request in the first permission set, the request reason is parsed to generate an application form, the application risk of the application form is analyzed and a risk value is calculated, and an approval path is dynamically selected for authorization, generating a first drift token, including:

[0023] In response to a shadow permission request in the first permission set, the request is parsed to determine the operation type, resource type, and resource instance of the request, and a request form is generated.

[0024] Analyze the application risk of the application form and calculate the risk value, dynamically select the approval path for authorization, and generate the first drift token.

[0025] Specifically, in response to a shadow permission request in the first permission set, the request is parsed to determine the operation type, resource type, and resource instance, and a request form is generated, including:

[0026] In response to a request for shadow permissions in the first permission set, extract the request reason text and the target shadow permission identifier from the request;

[0027] Semantic analysis is performed on the application reason text to identify action verbs, resource nouns, and business object nouns, and to determine the operation type, resource type, and resource instance of the application.

[0028] The operation type, resource type, and resource instance are combined and matched with the target shadow permission identifier to generate an application form.

[0029] Specifically, the process of analyzing the application risk of the application form, calculating the risk value, dynamically selecting the approval path for authorization, and generating the first drift token includes:

[0030] Obtain the permission code and user identifier from the application form, determine the first risk score based on the permission code, and adjust the first risk score by combining the user's historical application records to obtain the risk value;

[0031] Based on the risk value, the approval type is determined. According to the approval type, the node of the user's department and the node of the department to which the permission resources belong are analyzed to determine the approval path and authorize it, and generate the first drift token.

[0032] Specifically, the step of simulating and analyzing user operation process based on the second drift token, calculating usage entropy, filtering out permissions with usage entropy lower than a preset usage threshold, generating a permission deviation heatmap, and canceling corresponding authorizations based on the permission deviation heatmap includes:

[0033] Based on the second drift token simulation analysis, the user operation process permission usage is analyzed, the number of permission usages and usage time are analyzed, and the usage entropy is calculated;

[0034] Filter out permissions whose usage entropy is lower than a preset usage threshold and generate a permission deviation heatmap;

[0035] If permissions deviate from the heatmap, the corresponding permissions will be revoked and authorization will be cancelled.

[0036] Specifically, the step of filtering out permissions whose usage entropy is lower than a preset usage threshold and generating a permission deviation heatmap includes:

[0037] Filter out permissions whose usage entropy is lower than the preset usage threshold, and compare them with the baseline permission list of the user's current position. If they are in the baseline permission list, mark them as idle permissions for the position; otherwise, mark them as over-configured idle permissions.

[0038] The idle permissions and over-allocated idle permissions of user departments are aggregated, and the ratio of the number of over-allocated idle permissions to the number of idle permissions of positions is calculated as the permission configuration deviation. Using department identifier and permission type as dimensions, and the degree of concentration of idle permissions and permission configuration deviation as values, a permission deviation heatmap is generated.

[0039] A hierarchical role-based access control system is used to implement the aforementioned hierarchical role-based access control method, including:

[0040] The permission analysis module constructs a job competency graph based on multi-tenant organizational structure data, collects the user's current environment data to generate a scene fingerprint vector, and matches the user's job traversal results in the job competency graph with the scene fingerprint vector to obtain the first permission set.

[0041] The permission response module responds to shadow permission requests in the first permission set, parses the request reason to generate an application form, analyzes the application risk of the application form and calculates the risk value, dynamically selects the approval path for authorization, and generates the first drift token.

[0042] The permission optimization module performs authentication based on the first drift token during the user session, analyzes the user's real-time operation behavior, downgrades the permissions of the first drift token that triggers preset risk behavior, and obtains the second drift token.

[0043] The dynamic authorization module simulates and analyzes user operation process permission usage based on the second drift token and calculates usage entropy. It filters out permissions with usage entropy lower than the preset usage threshold and generates a permission deviation heatmap. Based on the permission deviation heatmap, it cancels the corresponding authorization to dynamically control role permissions.

[0044] The beneficial effects of this application are as follows: It ensures that permissions are only effective in a trusted environment by using scene fingerprints and shadow permissions; it eliminates the risk of permission residue by using entropy-driven permission reclamation; it reduces the workload of manual configuration by automatically generating application forms through semantic parsing; it provides accurate data support for permission control optimization through permission deviation heatmaps; and it reduces the workload of manual permission auditing and cleanup by automatic reclamation, thereby improving the quality of permission configuration. Attached Figure Description

[0045] Figure 1 This is a flowchart illustrating the hierarchical role-based permission dynamic authorization and control method in Embodiment 1 of this application;

[0046] Figure 2 This is a flowchart illustrating the process of obtaining the first permission set in Embodiment 1 of this application;

[0047] Figure 3 This is a schematic diagram of the hierarchical role-based permission dynamic authorization and control system in Embodiment 1 of this application. Detailed Implementation

[0048] The present application will be further described in detail below with reference to the accompanying drawings and embodiments.

[0049] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0050] Hereinafter, the terms "first," "second," and other generic terms are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0051] Example 1

[0052] refer to Figure 1 The diagram shows a specific implementation of the hierarchical role-based permission dynamic authorization and control method of this application, including:

[0053] S101. Construct a job competency graph based on multi-tenant organizational structure data, collect the user's current environment data to generate a scenario fingerprint vector, and match the user's job traversal results in the job competency graph with the scenario fingerprint vector to obtain the first permission set.

[0054] S102. In response to the application for shadow permissions in the first permission set, the application reason is parsed to generate an application form, the application risk of the application form is analyzed and the risk value is calculated, and the approval path is dynamically selected for authorization to generate the first drift token.

[0055] S103. During the user session, authentication is performed based on the first drift token, the user's real-time operation behavior is analyzed, and the first drift token that triggers the preset risk behavior is downgraded to obtain the second drift token.

[0056] S104. Based on the second drift token, simulate and analyze the user operation process of permission usage and calculate the usage entropy. Filter out permissions with usage entropy lower than the preset usage threshold and generate a permission deviation heatmap. Cancel the corresponding authorization according to the permission deviation heatmap to dynamically authorize and control role permissions.

[0057] In this embodiment, a job competency graph is constructed based on multi-tenant organizational structure data. This involves acquiring organizational structure data for all tenants on the multi-tenant platform, including job positions in each department, reporting relationships between positions, and job descriptions. During construction, each specific job position is treated as a node. For nodes, directed edges are established based on business relationships within the organizational structure, including inheritance, mutual exclusion, dependency, and collaboration edges. Inheritance edges indicate that one job inherits all permissions from another; mutual exclusion edges indicate that two jobs cannot simultaneously grant permissions to the same user; dependency edges indicate that the existence of one job depends on another; and collaboration edges indicate that two jobs need to share permissions in specific business scenarios. After the graph is constructed, organizational structure change events are continuously monitored. When job additions, removals, adjustments, or personnel transfers occur, only the nodes involved in the change and their adjacent edges are updated, keeping the rest of the graph unchanged, ensuring the graph's real-time performance and construction efficiency.

[0058] When a user initiates a login request, current environmental data is collected, including request time, source IP address, device identifier, browser type and operating system version in the request header, etc. This environmental data is then input into a scenario fingerprint generation model for processing. The scenario fingerprint generation model transforms the raw data according to preset mapping rules, including: for request time, determining whether the current time belongs to working hours, non-working hours, or holidays based on the user's pre-configured work calendar, and generating a time period type label; for source IP address, resolving it through an IP address database to determine whether the IP is an internal network address, VPN address, or public network address, generating a network location label, and simultaneously resolving the geographical location information to generate a geographical region label; for device identifier, comparing the device identifier with a pre-registered list of trusted devices by the user or administrator, generating a high-trust device label if a match is found, and a low-trust device label if it is an unfamiliar device appearing for the first time; for request header features, extracting information such as browser name, browser version, and operating system name, performing hash calculations, and generating a device fingerprint label for subsequent identification of multiple accesses by the same device. The time period type label, network location label, geographical region label, device trust level label, and device fingerprint label are combined to obtain the scenario fingerprint vector.

[0059] Specifically, after obtaining the job identifier of the currently logged-in user, a job competency graph traversal is performed. Starting with the node corresponding to the user's current job identifier, a breadth-first traversal is conducted along inheritance and dependency edges in the graph, collecting permission items for all nodes along the traversal path to obtain a forward permission set. Simultaneously, a traversal is performed along mutual exclusion edges, collecting permission items for all nodes along the mutual exclusion path to obtain a reverse mutual exclusion set. Permission items that do not intersect with the reverse mutual exclusion set are extracted and used as the user's initial permission set. The initial permission set is matched with the scene fingerprint vector, and an environment access condition is configured for each permission item. This condition defines the range of scene fingerprints that the permission item is allowed to access. A permission item refers to a single operation or data access capability that can be granted or denied in the system, including but not limited to viewing customer information, exporting sales reports, modifying order status, and accessing server logs.

[0060] For example, for data export permissions, the environmental access conditions might be limited to a network location label of intranet or VPN, a device trust level label of high-trust device, and a time period label of working hours. For read-only viewing permissions, the environmental access conditions might be more lenient, allowing public network access but requiring the device trust level to be no lower than medium. The current user's scenario fingerprint vector is compared one by one with the environmental access conditions for each permission item. If the scenario fingerprint vector falls entirely within the environmental access conditions for that permission item, then that permission item is classified into the available permission subset; if the scenario fingerprint vector falls outside the environmental access conditions, then that permission item is classified into the shadow permission subset. For instance, when a sales specialist logs in during working hours through a trusted device on the intranet, their data export permission is classified into the available permission subset; however, if they log in outside working hours through an unfamiliar device on the public network, the same data export permission is classified into the shadow permission subset. Permissions in the shadow permission subset are presented on the user interface as visible but unusable permissions. For example, a button is not grayed out, but clicking it returns a prompt informing the user that the current environment does not meet the conditions for using the permission. At the same time, an application entry is provided for the user to initiate a permission request with one click. The available permission subset and the shadow permission subset are merged to obtain the first permission set, which serves as the initial permission state for the user's current session.

[0061] It should be noted that by constructing a job competency graph, the inheritance, mutual exclusion, and dependency relationships between jobs can automatically take effect during authorization, avoiding the tediousness and errors of manual configuration item by item; through the dynamic collection and matching of scenario fingerprint vectors, users can obtain differentiated permission experiences in different environments, which can ensure risk control of sensitive operations in low-security environments and avoid inappropriate restrictions on user operations in unnecessary scenarios; through shadow permissions, users can perceive all the permissions they have in their own job and understand in what environments they can use them, reducing the cost of repeated applications and communication caused by invisible permissions, and improving user experience.

[0062] When a user clicks on the application entry for shadow permissions, the system extracts the natural language application reason text entered by the user and the identifier of the target shadow permission requested. This text is then input into a semantic parsing engine for processing.

[0063] Specifically, the semantic parsing engine contains a pre-trained natural language processing model. The training dataset for the model comes from historical permission application records, with a large number of historical application reasons manually labeled. The labeled content includes action verbs, resource nouns, and business object nouns. The model adopts a bidirectional long short-term memory network structure, which specifically adopts a two-layer bidirectional structure. Each layer has 128 hidden nodes in both the forward and backward LSTM layers. The activation function is tanh, and the output layer uses softmax for multi-class classification. The input is a word segmentation sequence of the application reason text, and the output is the probability distribution of each word belonging to action verbs, resource nouns, business object nouns, or other categories. The model's loss function is the cross-entropy loss function. During training, the stochastic gradient descent optimization algorithm is used, with the learning rate set to 0.001, the batch size set to 32, and the training epochs set to 20. Training stops when the loss value on the validation set no longer decreases. In actual operation, the user-input application reason text is segmented and then input into the model. The model outputs the category probability of each word. Based on the preset confidence threshold, the category with the highest probability is taken as the recognition result, and action verbs, resource nouns and business object nouns are extracted. The confidence threshold is set according to the system's control accuracy requirements.

[0064] The system matches identified action verbs with a pre-defined operation terminology to determine the requested operation type, such as export, modify, delete, or view. It also matches identified resource nouns with a pre-defined resource terminology to determine the requested resource type, such as server logs, database records, or customer information. Finally, it matches identified business object nouns with the current tenant's business instance database to determine the specific resource instance requested, such as project A, customer A, or order batch B. The operation type, resource type, and resource instance are combined to obtain a permission code. This permission code is then checked for consistency with the user's requested target shadow permission identifier. If they match, the check passes; otherwise, a prompt is returned to the user, requesting them to supplement or modify key information in their request reason. After successful verification, the generated permission code is combined with the user identifier, request time, and request reason text to generate the request form.

[0065] It should be noted that the preset operation thesaurus is a pre-built verb mapping table that maps action verbs such as export, modify, delete, and view to unified operation type codes; the preset resource thesaurus is a pre-built resource noun mapping table that maps resource nouns such as server logs, database records, and customer information to unified resource type codes; the business instance database is entity data dynamically synchronized from various business systems, recording the identifiers and names of all business entities such as projects, customers, and orders under the current tenant. The permission configuration database is a configuration table with permission codes as the primary key, storing attributes such as the data sensitivity level, operation hazard level, environmental access conditions, and resource ownership department for each permission item.

[0066] Furthermore, the system performs risk calculations and selects approval paths, retrieves the permission code from the application form, and queries the permission configuration library to obtain the data sensitivity level and operational hazard level corresponding to that permission code. The data sensitivity level is pre-classified based on the confidentiality level of the data content involved in the permission; for example, permissions involving personal privacy data or financial data have a high sensitivity level, while permissions involving publicly available information have a low sensitivity level. The operational hazard level is pre-classified based on the potential system impact after the permission is executed; for example, deletion has a high hazard level, export has a medium hazard level, and read-only access has a low hazard level. The data sensitivity level and operational hazard level are weighted and summed to generate a first risk score; for example, a high sensitivity level is assigned a value of 5, a medium sensitivity level of 3, and a low sensitivity level of 1, and a high hazard level is assigned a value of 4, a medium sensitivity level of 2, and a low hazard level of 1. The sum of these two values ​​yields the first risk score.

[0067] Specifically, the system simultaneously acquires the historical behavioral profile corresponding to the user's identifier. This historical behavioral profile is continuously maintained by the system, recording the user's total number of applications, the number of rejected applications, the number of instances of permission abuse, and the number of abnormal logins over the past ninety days. The ratio of rejected applications to total applications is calculated to obtain an application credibility coefficient; a higher coefficient indicates less trustworthy application behavior. A behavioral risk coefficient is determined based on the number of permission abuse records. For example, a risk coefficient of 1 is obtained when there are 0 instances of permission abuse, 1.5 when there are 1 to 2 instances, and 2 when there are more than 2 instances. The application credibility coefficient and the behavioral risk coefficient are multiplied to obtain the user risk correction coefficient.

[0068] The system obtains the scenario fingerprint vector of the current session and extracts the network location label and device trust level label from it. A predefined scenario risk mapping table is used to map the network location label and device trust level label from the scenario fingerprint vector to corresponding risk adjustment factors. For example, the first adjustment factor is 1.5 for a public network location, 1.2 for a VPN location, and 0.8 for a private network location; the second adjustment factor is 1.5 for a low device trust level, 1.2 for a medium device trust level, and 0.8 for a high device trust level. The system multiplies the first and second adjustment factors to obtain the scenario risk adjustment factor. The first risk score is multiplied by the user risk correction coefficient, and then multiplied by the scenario risk adjustment factor to obtain the risk value.

[0069] The system compares the risk value with multiple preset threshold ranges. Based on the required control precision, the system presets an upper limit of 5 for circuit breaker authorization, 8 for rapid approval, and 12 for standard approval. Values ​​exceeding 12 are classified as joint review. The approval type is determined based on the risk value. The corresponding authorization process is executed based on the approval type. For circuit breaker authorization types, a temporary authorization record is directly generated, skipping the manual approval step. The temporary authorization record includes a unique authorization identifier, permission code, user identifier, authorization effective time, authorization expiration time, and remaining available attempts. The authorization expiration time is set to the current time plus the maximum allowed duration corresponding to the permission code; for example, the maximum allowed duration for high-risk operations is two hours, and for low-risk operations, it is eight hours. The remaining available attempts are set to the maximum allowed number of times corresponding to the permission code; for example, the maximum allowed number of export operations is five times. The system generates an authorization certificate based on the temporary authorization record, marking it as the source of the circuit breaker authorization. The maximum allowed duration and maximum allowed number of attempts can be set according to the system's control precision requirements.

[0070] For non-circuit breaker authorization types, the system retrieves the user identifier from the application form and queries the first node path of the user's department in the organizational structure tree; it also retrieves the resource-owning department corresponding to the permission code and queries the second node path of that department in the organizational structure tree. The system calculates the intersection of the first and second node paths and selects the node with the deepest hierarchy as the approval node. Depending on the approval type, standard approval types require a second approver (security officer), while multi-approval types require an additional security officer and the department head as second and third approvers, respectively. The system generates an approval task, including application form information, approver list, creation time, and approval time limit, and pushes the task to each approver's to-do list, triggering a notification. After receiving approval instructions from all approvers, the system generates an authorization credential.

[0071] After the authorization credential is generated, the first drift token is generated based on the authorization credential. The system extracts the permission code list and authorization validity period from the authorization credential. The system generates a unique session identifier by taking the current timestamp in milliseconds, generating a random integer, and taking the last four digits of the user identifier's hash value. These three values ​​are concatenated in a preset order and then Base62 encoded to obtain a fixed-length session identifier. The initial version number is set to 1. The session identifier, initial version number, authorization validity period, and user identifier are combined and then symmetrically encrypted to generate the first drift token.

[0072] Preferably, the organizational structure tree is a tree-like data structure with departments as nodes and reporting relationships as edges. The root node is the tenant's root department, and each node contains attributes such as department identifier, department head identifier, and parent department identifier. Selecting the deepest node as the approval node means choosing the node furthest from the root node in the intersection of two departmental paths; the head of this node is the common superior approver. Depending on the approval type, standard approval types require an additional security officer as a second approver, while joint review types require an additional security officer and the department head in charge as second and third approvers, respectively, to achieve hierarchical joint approval. The permission code list is a collection of multiple permission codes contained in the authorization credential, with each permission code uniquely identifying a permission item. The authorization validity period refers to the time period from the effective date of the authorization credential to its expiration date, set according to the approval type and the severity level of the permission. For example, circuit breaker authorization is usually two hours, while regular authorization can be several hours to several days.

[0073] It should be noted that by semantically parsing the application reasons, automatically identifying the operation type, resource type, and resource instance, and generating an application form, the workload of manual configuration by users and the configuration error rate can be reduced. By combining the sensitivity of the permission itself, the user's historical behavior, and the current scenario environment to calculate the risk value, the comprehensiveness and accuracy of risk assessment are improved. Dynamic approval path selection based on risk value enables differentiated processing, such as strict approval for high-risk operations, simplified approval for low-risk operations, and circuit breaker authorization in emergency situations, which ensures both security and improves approval efficiency. The generated drift token provides accurate data support for dynamic permission adjustments during the subsequent runtime.

[0074] After a user obtains the first drift token, it is carried in every subsequent request for real-time authentication of user requests and continuous monitoring of user behavior, with immediate responses to any abnormal behavior. When the system gateway layer receives a user request, it extracts the first drift token from the request, decrypts and verifies the token's signature to obtain the session identifier and initial version number. Based on the session identifier, it queries the server cache to obtain the corresponding permission code list, user identifier, authorization validity period, and current version number. First, it checks if the authorization validity period has expired; if so, it returns a token invalidation response. It compares the version number carried in the request with the version number in the cache; if they do not match, it returns a version expired response, prompting the client to obtain a newer token. Based on the target interface and request parameters, it determines whether the operation is in the permission code list; if not, it returns an insufficient permission response.

[0075] Meanwhile, the system continuously collects user action data at the gateway layer, including the action interface name, request parameters, action time, and the current session's scenario fingerprint vector. This action data is sent to the streaming engine in real time. The streaming engine aggregates the action data by session dimension and calculates behavioral metrics within a sliding window. The sliding window duration is set to five minutes, sliding once every ten seconds, calculating behavioral metrics for each user within the sliding window, including action frequency, etc.

[0076] The system is configured with a risk policy library, with each risk policy including trigger conditions and execution actions. For example, one policy is triggered when more than three export operations are performed within one minute, and the execution action is to downgrade export permissions to read-only; another policy is triggered when access to the core database is performed outside of working hours, and the execution action is to block access and log an alarm; yet another policy is triggered when three consecutive incorrect parameter inputs cause an abnormal interface return, and the execution action is to force two-factor authentication. The risk policy library is pre-configured by the security administrator and can be dynamically adjusted according to actual operational conditions.

[0077] Specifically, the streaming engine calculates behavioral metrics for each session in real time and matches them against trigger conditions in the risk policy library. When a session's behavioral metrics meet the trigger conditions of a risk policy, the streaming engine sends a risk trigger instruction to the permission management service. Upon receiving the risk trigger instruction, the permission management service updates the permission code list corresponding to the session identifier in the server cache according to the execution actions defined in the risk policy. For example, for an instruction to downgrade export permissions, the permission management service marks the export permissions in the session's permission list as unavailable while retaining read-only permissions; for an instruction to block access, the permission management service directly removes the access permissions for the corresponding interface. After updating the permission list, the permission management service increments the version number of the session in the cache, for example, from 1 to 2. The user's ongoing operations will continue, but subsequent requests will still carry the old version number. When the gateway layer verifies the version number, it will find an inconsistency and return a version expiration response. After receiving the response, the client automatically re-initiates the request using the new version number. The user will perceive that some operation buttons become unavailable or return an insufficient permissions message, but the session remains valid and does not require re-login.

[0078] The updated permission code list is combined with the updated version number to generate a second drift token, which is used for authentication of subsequent requests. The structure of the second drift token is the same as the first drift token, except that the version number and the associated permission code list change. By collecting and optimizing tokens in real time, user behavior is monitored and risks are identified; a risk policy library allows security administrators to flexibly define risky behaviors and their countermeasures; and upon detecting abnormal behavior, permissions can be tightened immediately without interrupting the user session, thus ensuring both security and maintaining a good user experience, thereby improving system security.

[0079] During user sessions, the system quantifies the actual activity level of each permission through simulated analysis of permission usage, and revokes permissions based on the quantification results. The system continuously collects operation records for each user and permission combination from audit logs, including operation timestamps, user identifiers, permission code lists, and scenario fingerprint vectors at the time of the operation. The system assigns weights to each operation record, including looking up the weight value of the operation from a pre-defined scenario weight mapping table based on the network location label and device trust level label in the scenario fingerprint vector at the time of the operation. A permission combination refers to the pairing of a user identifier and a permission code, used to represent the relationship that a specific user holds a specific permission. The system independently tracks the usage of each user and permission combination; for example, user A and the data export permission constitute a permission combination. The scenario weight mapping table is a predefined configuration table used to assign a weight value to each operation record based on the network location tag and device trust level tag in the scenario fingerprint vector at the time of the operation. For example, the weight value is 1.0 when the network location is on the intranet and the device trust level is high trust, and the weight value is 0.5 when the network location is on the public network and the device trust level is low trust. This mapping table is configured by the security administrator according to the business policy and is used to measure the difference in the value of the access rights in different scenarios.

[0080] For example, operations performed via a network location labeled as an intranet and a device with a high-trust level label are considered normal scenarios, with a weight value of 1; operations performed via a VPN are considered medium-risk scenarios, with a weight value of 0.8; and operations performed via the public internet and a device with a low-trust level label are considered high-risk scenarios, with a weight value of 0.5. These weight values ​​are appended to the operation records to generate a weighted sequence of permission usage records.

[0081] The usage of permissions is analyzed according to a preset statistical period, which can be set according to the system's control precision requirements, for example, a continuous 90-day period. For each user and permission combination, all weighted operation records of that permission combination within the statistical period are extracted from the audit logs. The cumulative number of uses, the time difference between the last use time and the current time (in days), and the sum of the cumulative weight values ​​are calculated. Usage entropy is calculated based on these three indicators. The calculation process for usage entropy includes: fewer cumulative uses, lower usage entropy; longer time since the last use, lower usage entropy; and smaller sum of cumulative weight values, lower usage entropy. Specifically, usage entropy is lowest when the cumulative number of uses is 0, gradually increasing as the cumulative number of uses increases; the negative impact on usage entropy is greatest when the time difference exceeds 90 days, but is still calculated as 90 days even after exceeding 90 days; the sum of cumulative weight values ​​reflects the quality of the operation scenario, with low-weight operations accumulating a lower total weight and contributing less to usage entropy.

[0082] In another specific implementation, the entropy calculation process includes: normalizing the three indicators separately. The normalization of the cumulative usage count uses a piecewise linear mapping, setting the maximum possible usage count within the statistical period to 100 times. When the usage count is 0, the normalization value is 0; when it reaches 100 times, the normalization value is 1; and intermediate values ​​are linearly interpolated. The normalization of the time difference in days uses a reverse linear mapping, setting the normalization value to 1 when the time difference in days is 0; when it reaches 90 days, the normalization value is 0; and intermediate values ​​are linearly interpolated, with values ​​exceeding 90 days treated as 90 days. The normalization of the cumulative weighted sum is based on the maximum possible weighted sum, which equals the number of days in the statistical period multiplied by the highest single weight value of 1.0. The normalized value is obtained by dividing the actual cumulative weighted sum by the maximum possible weighted sum. The three normalized values ​​are assigned weight coefficients: usage count weight is 0.4, time difference in days weight is 0.3, and cumulative weighted sum weight is 0.3. The entropy calculation result is the sum of three normalized values ​​multiplied by their respective weights, with a value ranging from 0 to 1. An entropy value closer to 1 indicates more active permission usage, while a value closer to 0 indicates less active usage. The system has a preset sleep threshold, for example, 0.1; permissions below this threshold are considered dormant.

[0083] The usage entropy of each user and permission combination is compared with a preset sleep threshold. The sleep threshold is set according to the system's control precision requirements, for example, 0.1. Permissions with an entropy lower than 0.1 are marked as sleep permissions, and their status is updated from active to frozen. The sleep permission record is stored in the sleep permission cache, containing the permission code, user identifier, marking time, and frozen sleep state. The server-side cached permission code list corresponding to the user session is updated based on the sleep permission record. Frozen permission codes are removed from the currently valid permission list, but are retained in the sleep permission cache as wake-up options. On the user interface, the operation entry corresponding to the permission becomes grayed out or displays a sleep prompt, but the user can still see the permission. The valid permission list refers to the set of permission codes actually available in the current user session, that is, the subset of available permissions obtained after scenario fingerprint matching, and the permission list updated after subsequent dynamic authorization or hot degradation.

[0084] Specifically, a cooling-off period is configured for each dormant permission record. The cooling-off period is set according to the system's control precision requirements, and is set to thirty days, starting from the marked time. During the cooling-off period, when a user attempts to use a frozen permission, the system returns a permission freeze status code and includes the wake-up entry information on the interface. When the user clicks the wake-up entry, the system retrieves the permission code and user identifier from the wake-up request, queries the initial permission set of the user's current position in the job competency graph, and determines whether the permission code is still in the initial permission set. If it is still in the initial permission set, for example, if the user's position has not changed, then the permission still falls within the user's appropriate permission scope. The system updates the dormant permission record's dormant status from frozen to active and moves it from the dormant permission cache to the currently valid permission list in the server cache, completing the permission recovery. The user can immediately continue to use the permission. If it is not in the initial permission set, for example, if the user has changed positions, then the permission no longer falls within the new position's permission scope. The system returns a message indicating that the permission has expired and marks the dormant permission record as pending revocation.

[0085] Sleeping permissions that remain dormant after the cooling-off period are automatically marked as pending revocation. A baseline comparison is performed between these pending permissions and the user's current job's baseline permission list. If the permission is in the baseline list, it is marked as an idle permission for that job; otherwise, it is marked as an over-allocated idle permission. Permission deviation data is aggregated by department. Each department node in the organizational structure tree is traversed, collecting lists of idle and over-allocated idle permissions for all positions within that department. The ratio of the number of over-allocated idle permissions to the number of idle job permissions within each department is calculated as the department's permission configuration deviation. The concentration of idle permissions within a department is also analyzed by permission type.

[0086] It should be noted that the job baseline refers to the standard scope of permissions that a specific job should possess in normal business activities, defined by the theoretical permission set of that job node in the job competency map. The baseline permission list is the concrete manifestation of the job baseline, that is, the set of all pre-configured permission codes on that job node, used to determine whether the permissions held by a user fall within the scope that the job should have. Concentration refers to the prevalence of a certain type of permission being idle within the department. Specifically, it is the total number of times that permission type is marked as idle among all users in the department. The higher the number, the more concentrated the idleness of that permission is in the department, and the more likely it is to be a department-level permission over-provisioning problem.

[0087] The departmental permission deviation statistics are input into the heatmap generation engine. The engine constructs a two-dimensional coordinate system with the department identifier as the first axis and the permission type as the second axis. The concentration of idle permissions of that type within the department is used as the numerical value, which is then mapped to a color gradient: light colors indicate low concentration of idle permissions, and dark colors indicate high concentration. Each cell in the heatmap displays a deviation marker for that permission type within the department, for example, as a superscript value. For departments whose permission configuration deviation exceeds a preset warning threshold of 0.3 (the warning threshold can be set according to the system's control precision requirements), a warning marker is added above the department's axis in the heatmap, resulting in the permission deviation heatmap.

[0088] Specifically, permissions are revoked based on the deviation of permission configuration. A preset first deviation threshold of 0.1 and a second deviation threshold of 0.3 are set according to the system's control precision requirements. For departments with a permission configuration deviation below 0.1, it indicates that the department's permission configuration is relatively reasonable, with only a small number of idle permissions for certain positions. An automatic revocation process is executed for these idle permissions within the department, removing them directly from the user's valid permission list without supervisor confirmation. For departments with a permission configuration deviation between 0.1 and 0.3, it indicates that the department has a certain degree of idle permissions, but not to a severe degree. A revocation confirmation task is generated for these idle permissions within the department and pushed to the department supervisor's to-do list, where the supervisor confirms each item before executing the revocation. For departments with a permission configuration deviation above 0.3, it indicates a serious over-configuration of permissions. A forced revocation process is executed for these over-configured idle permissions within the department, without supervisor confirmation. Simultaneously, the department's job competency graph nodes are marked as nodes to be optimized, triggering a partial re-verification of the job competency graph, where the security administrator re-examines the baseline permission configuration of each position in the department to ensure its reasonableness.

[0089] The revoked permission codes, department identifiers, and revocation methods are stored as revocation records in the revocation audit log. Simultaneously, the revoked permission codes, user job identifiers, revocation reasons, and usage entropy values ​​are input as feedback data into the job competency graph's optimization queue. The system periodically analyzes the feedback data in the optimization queue. For identical permissions revoked from at least two users, the system suggests to the job administrator that the permission be removed from the corresponding job's initial permission set. For frequently awakened dormant permissions, the system suggests retaining them in the theoretical permission set and adjusting their environmental access conditions. Through this closed-loop feedback mechanism, the job competency graph is continuously optimized, and the quality of permission configuration is constantly improved.

[0090] It should be noted that by calculating usage entropy and comprehensively considering the frequency, duration, and operational scenario weight of permission usage, the actual activity level of permissions can be quantitatively assessed. Through sleep permission identification and a cool-off period design, users can have their permissions restored with a single click during the cool-off period, preventing premature revocation of permissions from affecting normal work and promptly clearing long-unused permissions. By comparing job baselines, idle permissions for different roles can be distinguished from over-allocated idle permissions. By constructing a permission deviation heatmap, administrators can quickly locate high-risk departments with unreasonable permission configurations, improving the accuracy of dynamic permission authorization and system security.

[0091] This application ensures that permissions are only effective in a trusted environment by using scenario fingerprinting and shadow permissions. It eliminates the risk of permission residue by using entropy-driven permission reclamation, reduces the workload of manual configuration by automatically generating application forms through semantic parsing, provides accurate data support for permission control optimization through permission deviation heatmap, and reduces the workload of manual permission auditing and cleanup through automatic reclamation, thereby improving the quality of permission configuration.

[0092] Furthermore, a job competency graph is constructed based on multi-tenant organizational structure data. User current environment data is collected to generate scenario fingerprint vectors. The traversal results of user jobs in the job competency graph are matched with the scenario fingerprint vectors to obtain the first permission set, including:

[0093] S201. Analyze job relationships and construct a job competency map based on multi-tenant organizational structure data;

[0094] S202. Collect the user's current environmental data and input it into the preset scene fingerprint generation model to generate a scene fingerprint vector;

[0095] S203. Match the user's job position in the job competency graph with the scene fingerprint vector to obtain the first permission set.

[0096] In this embodiment, job relationships are analyzed and a job competency graph is constructed based on multi-tenant organizational structure data. By abstracting jobs as nodes and job relationships as edges into a graph structure, the mapping between permission allocation logic and organizational structure can be realized. The inheritance relationship between jobs allows permissions to be automatically passed along the organizational hierarchy, avoiding the tedious work of repeatedly configuring permissions for each job. Mutual exclusion relationships can automatically detect and prevent the allocation of conflicting permissions during authorization, ensuring compliance with the separation of duties requirements. Dependency relationships enable the linkage management of permissions, and the permissions of dependent jobs can automatically respond when the permissions of core jobs change. Collaboration relationships provide an explicit expression of permission sharing for temporary cross-job collaboration. Incremental updates ensure that the graph can be efficiently maintained when the organizational structure changes frequently, improving update efficiency.

[0097] This process is executed every time a user initiates a login request, collecting environmental data, including time data, network data, device data, and request header data. Time data is the timestamp of the request arriving at the server, obtained from the server's system time. Network data is the user's source IP address, obtained from the remote address field of the HTTP request. Device data is the device's unique identifier; the system reads the device fingerprint information provided by the browser or operating system through a front-end script. For example, on the web, it generates a device identifier using Canvas fingerprint technology; on mobile devices, it obtains the device ID, and then encrypts the device identifier before transmitting it to the backend. Request header data includes the browser name, browser version, operating system name, operating system version, and information such as the accepted language and screen resolution from the user agent string.

[0098] Specifically, this environmental data is input into a pre-defined scenario fingerprint generation model for processing. This model consists of multiple converters, each responsible for converting a type of raw data into a standardized label. The time period type converter receives the request timestamp and, based on the user's pre-configured work calendar (defined by the user or tenant administrator in the system), determines the user's normal working hours. The network location converter receives the source IP address and inputs it into an IP address database for parsing. This database contains mappings between public IP ranges, internal IP ranges, and VPN address pools. It determines whether the IP belongs to the enterprise's internal address range; if so, a network location label of "internal" is generated; otherwise, it checks if it belongs to the VPN address pool. If so, a label of "VPN" is generated; otherwise, a label of "public" is generated. The geographic region converter also receives the source IP address and, through the IP geographic location database, resolves the corresponding country, province, and city information to generate a geographic region label. The device trustworthiness converter receives a device identifier and compares it with a pre-registered list of trusted devices. This list is maintained by the user or tenant administrator in the system. When a user logs in for the first time, they can register the current device as a trusted device, and the system records the device identifier and the registration time. The converter determines whether the device identifier exists in the list of trusted devices. If it exists and the registration time is within the validity period, a high trustworthiness label is generated for the device. If it exists but the registration time has expired, a medium trustworthiness label is generated. If it does not exist, a low trustworthiness label is generated.

[0099] Preferably, the user agent string in the received request header data is used to extract the browser name, browser version, operating system name, and operating system version. This information is then concatenated in a preset order and hashed to generate a fixed-length device fingerprint tag. The hash of the concatenated tag is then calculated to obtain the device fingerprint tag. The scene fingerprint generation model combines the time period type tag, network location tag, geographic region tag, device trust level tag, and device fingerprint tag output by the five converters into a structured data object, resulting in a scene fingerprint vector.

[0100] It should be noted that environmental data collection can obtain contextual information about user access, providing a data foundation for subsequent dynamic adjustment of permissions; the time period type converter, combined with the user's personalized work calendar, makes scenario judgments more aligned with actual business needs; the network location converter, through IP address database resolution, can accurately distinguish between intranet, VPN, and public network access, providing a basis for permission control in different network environments; the device trustworthiness converter, through the maintenance of a trusted device list, can distinguish between frequently used and unfamiliar devices; and the device fingerprint converter, through hash calculation to generate stable identifiers, can improve the efficiency of subsequent permission matching and risk calculation.

[0101] Specifically, the user's job position is traversed in the job competency graph and matched with the scenario fingerprint vector to obtain the first set of permissions. By traversing the job competency graph, all permissions on the job chain can be inherited, and conflicting permissions of mutually exclusive jobs can be eliminated, thereby automating permission allocation and ensuring compliance. This reduces the cost of repeated applications and communication caused by invisible permissions, and improves the user experience.

[0102] Furthermore, based on multi-tenant organizational structure data, job relationships are analyzed and a job competency map is constructed, including:

[0103] S301. Based on the multi-tenant organizational structure data, analyze the job relationships, and construct the first job competency graph with each job as a node and the job relationships between jobs as edges.

[0104] S302. Configure the corresponding job attributes for each job node in the first job competency graph, and configure the corresponding relationship type for each edge to obtain the job competency graph.

[0105] In this embodiment, the raw organizational structure data of each tenant is obtained from the multi-tenant platform. This data is synchronized from the human resources management system through a standardized interface. The raw data is parsed, and each specific job position is abstracted as a node in a graph structure. For example, sales specialists, development engineers, and finance managers are all treated as independent nodes. The business relationships between jobs are analyzed, and directed edges are established between nodes.

[0106] Specifically, reporting edges are established from lower-level job nodes to their direct superior job nodes based on reporting relationships; bidirectional mutually exclusive edges are established between job nodes that cannot be held by the same person, based on separation of duties constraints; bidirectional collaborative edges are established between job nodes participating in the same project, based on project collaboration relationships; and inheritance edges are established from higher-level job nodes to lower-level job nodes that inherit permissions, based on permission inheritance relationships. The constructed nodes and edges are stored in a graph database to obtain the first job competency graph. When the organizational structure changes, the job nodes affected by the change are located, and only that node and its adjacent edges are incrementally updated, keeping the topology of the rest of the graph unchanged. By transforming job entities and job relationships into a graph structure, graph modeling of the organizational structure is achieved. Inheritance edges allow permissions to be automatically passed along organizational levels, mutually exclusive edges ensure compliance with separation of duties requirements, and the incremental update mechanism ensures efficient maintenance of the graph during frequent organizational structure changes.

[0107] Specifically, all nodes in the first job competency graph are traversed, and job attribute labels are added to each job node. Information such as the department and job level of the job are extracted from the raw data and stored directly as node attributes. For job responsibility classification attributes, a responsibility classification model is used for identification. This model is a support vector machine-based classifier. The input is the job name and job description text, and the output is responsibility classification labels such as sales, technology, finance, and administration. The training dataset comes from historical job data and is manually labeled. For job permission baseline attributes, a permission baseline analysis model is used to generate the data. This model counts the frequency of various permissions for the job in historical authorization records and, combined with the commonalities of permissions for jobs with the same responsibility category, outputs a suggested permission baseline permission list.

[0108] It should be noted that historical job data refers to the historical records of all job entities accumulated during system operation, including attribute information such as job name, job description, department, and job level, used to train the responsibility classification model. The permission baseline analysis model is a statistical rule-based model that analyzes the historical permission allocation of jobs within the same responsibility category, calculates the frequency of occurrence of various permissions, and combines this with common permission recommendation rules to output a suggested permission baseline permission list. Historical authorization records refer to all past permission granting records stored in the system, including user identifier, job identifier, permission code, authorization time, and authorization source. The suggested permission baseline permission list is the set of recommended permissions output by the permission baseline analysis model, representing the scope of permissions that the job should possess in normal business operations. It is used as the baseline permission list for job nodes after review and confirmation by the security administrator.

[0109] Specifically, all edges in the graph are traversed simultaneously, and a relationship type label is assigned to each edge, including four types: inheritance, mutual exclusion, dependency, and collaboration. A weight attribute is then added to each edge based on the importance of the relationship, with inheritance and mutual exclusion edges having the highest weight, and collaboration edges having a lower weight. After completing the node attribute and edge type configuration, the first job competency graph is obtained. Through multi-dimensional job attribute configuration, the semantic information of job nodes is enriched, enabling accurate identification of the core responsibilities of various jobs. The permission baseline analysis model automatically generates suggested permission baselines for jobs, and the relationship type labels and weight attributes allow subsequent permission calculations to employ corresponding processing based on different relationship types.

[0110] like Figure 2 As shown, the user's job position is traversed in the job competency graph and matched with the scene fingerprint vector to obtain the first permission set, which includes:

[0111] S401. Based on the current user's job identifier, take the job node corresponding to the job identifier as the starting node, traverse along the connection relationship in the job competency graph, integrate the permission items of the nodes on the traversal path, and obtain the user's initial permission set.

[0112] S402. Analyze the scenario fingerprint range configured for each permission item in the initial permission set;

[0113] S403. Compare the scene fingerprint vector with the scene fingerprint range. If the scene fingerprint vector is within the scene fingerprint range, divide the corresponding permission item into an available permission subset. If the scene fingerprint vector is outside the scene fingerprint range, divide the corresponding permission item into a shadow permission subset.

[0114] S404. Integrate the available permission subset and the shadow permission subset to obtain the first permission set.

[0115] In this embodiment, the job identifier of the currently logged-in user is obtained. Using the node corresponding to this identifier as the starting node, a directed graph traversal is performed in the job competency graph. Traversing upwards along inheritance edges, the permission items of the starting node and all its ancestor nodes are collected. Traversing outwards along dependency edges, the permission items of the dependent nodes are collected. Traversing outwards along collaboration edges, the permission items of nodes with collaborative relationships are collected. During the traversal, the set of visited nodes is maintained to prevent duplication. For users holding multiple jobs, each job is traversed separately, and the permission sets of each job are combined and deduplicated to obtain the user's initial permission set.

[0116] For example, starting from the sales specialist node, permissions for sales supervisor and sales director can be obtained along the inheritance edge, and access to the customer management system can be obtained along the dependency edge. The merged initial permission set includes permissions such as viewing customer information, creating sales orders, and exporting sales data. By traversing the graph, the inheritance, dependency, and collaboration relationships between positions are automatically converted into permission aggregations, avoiding the tedious manual configuration of each item and ensuring that permission allocation remains synchronized with the organizational structure.

[0117] The scenario fingerprint range corresponding to each permission item in the initial permission set is read from the permission configuration library. The scenario fingerprint range is a set of access constraints pre-set for each permission item, with a structure corresponding to the scenario fingerprint vector. It includes dimensions such as time period type constraints, network location constraints, and device trust level constraints. Each dimension can be a specific value, a set of values, or a wildcard. For example, the scenario fingerprint range for data export permission can be configured as follows: network location: intranet or VPN; device trust level: high trust or medium trust; time period type: working hours. The scenario fingerprint range is configured by the security administrator through a visual rule editor, and the configuration results are cached in memory for fast retrieval. By configuring the scenario fingerprint range independently for each permission item, fine-grained environmental control of permissions is achieved, ensuring that highly sensitive permissions are only available in highly trusted environments, while less sensitive permissions can be used in relatively relaxed environments, achieving a balance between security and convenience.

[0118] The scenario fingerprint vector is matched dimension-by-dimensionally with the scenario fingerprint range. The time period type label, network location label, geographic region label, device trust level label, and device fingerprint label in the scenario fingerprint vector are checked sequentially to see if they meet the constraints of each dimension within the scenario fingerprint range. Only when all dimensions of the label meet their corresponding constraints is the scenario fingerprint vector determined to fall within the scenario fingerprint range, and the corresponding permission item is assigned to the available permission subset. If any dimension fails to meet the constraints, the vector is determined to be outside the range, and the corresponding permission item is assigned to the shadow permission subset. For example, when a user logs in through a low-trust device on the public network, the network location and device level of the data export permission do not meet the constraints, and the user is assigned to the shadow permission subset. Through precise matching of scenario fingerprints and scenario fingerprint ranges, context-aware activation of permissions is achieved, tightly coupling the availability of permissions with the user's current environment and effectively preventing risks associated with sensitive operations in low-security environments.

[0119] Specifically, the available permission subset and the shadow permission subset are merged to obtain the first permission set. Each permission item in the first permission set carries a status identifier; permission items in the available permission subset are in the available state, and permission items in the shadow permission subset are in the shadow state. The first permission set is returned to the front end, which performs differentiated rendering based on the status identifier: function buttons corresponding to available permissions are displayed normally and clickable; function buttons corresponding to shadow permissions remain visible but are grayed out, and a prompt appears when the user clicks them, guiding them to apply. Simultaneously, the first permission set is stored in the server-side cache of the user session for subsequent authentication and verification. By integrating available permissions and shadow permissions into a unified first permission set, a complete permission view is provided to the user, allowing them to intuitively understand their own permissions and which permissions are restricted in the current environment. The pre-filled application function for shadow permissions simplifies the user's application process.

[0120] Furthermore, in response to a shadow permission request in the first permission set, the request reason is parsed to generate an application form, the application risk is analyzed and a risk value is calculated, and the approval path is dynamically selected for authorization, generating a first drift token, including:

[0121] S501. In response to the request for shadow permissions in the first permission set, parse the request, determine the operation type, resource type and resource instance of the request, and generate a request form;

[0122] S502. Analyze the application risk of the application form and calculate the risk value, and dynamically select the approval path for authorization to generate the first drift token.

[0123] In this embodiment, in response to the request for shadow permissions in the first permission set, the request reason is parsed to determine the operation type, resource type, and resource instance of the request, and an application form is generated. The request reason is automatically parsed through natural language processing technology, and the unstructured text is converted into a structured application form, which can reduce the workload of manual configuration by users. The consistency verification mechanism avoids erroneous applications caused by user misunderstanding.

[0124] Specifically, the system analyzes the application risk of each application form, calculates the risk value, dynamically selects the approval path for authorization, and generates the first drift token. Through multi-dimensional risk quantification, it achieves dynamic adaptation of the approval path, quickly responding to low-risk applications with circuit breaker authorization and rigorously reviewing high-risk applications. Simultaneously, it intelligently determines the approver through a departmental path intersection algorithm, improving approval efficiency while ensuring security.

[0125] Furthermore, in response to a shadow permission request in the first permission set, the request reason is parsed to determine the requested operation type, resource type, and resource instance, and a request form is generated, including:

[0126] S601. In response to a request for shadow permissions in the first permission set, extract the request reason text and the target shadow permission identifier from the request;

[0127] S602. Perform semantic parsing on the application reason text to identify action verbs, resource nouns and business object nouns, and determine the operation type, resource type and resource instance of the application.

[0128] S603. Combine the operation type, resource type and resource instance, and match them with the target shadow permission identifier to generate an application form.

[0129] In this embodiment, after a user clicks on the application entry corresponding to a shadow permission, the system frontend binds a unique permission identifier to each shadow permission item when rendering the shadow permission. When the user fills in the application reason and clicks submit, the user-inputted application reason text and the current shadow permission identifier are sent as request parameters to the backend service. Upon receiving the request, the backend service extracts the application reason text field and the target shadow permission identifier field from the request parameters. The application reason text is a natural language description manually entered by the user, and the target shadow permission identifier is a unique code for each permission item within the system. The extracted application reason text and target shadow permission identifier are used as input data for subsequent semantic parsing steps. Simultaneously, contextual information such as the application initiation time, user identifier, and session identifier are recorded for subsequent risk assessment and audit tracing. This collaborative mechanism of frontend binding and backend extraction ensures the accurate transmission of key information in the application request, providing accurate data support for subsequent analysis.

[0130] The model receives the application reason text as input and uses a pre-trained semantic parsing model to perform sequence labeling. This model employs a bidirectional long short-term memory network combined with a conditional random field architecture. The input is a segmented sequence of the application reason text, and the output is an entity category label for each word, including action verbs, resource nouns, and business object nouns. The training dataset is derived from historical permission application records, manually labeled. The labeling specification is as follows: "export" and "view" are labeled as action verbs; "sales reports" and "server logs" are labeled as resource nouns; and "project X" and "customer A" are labeled as business object nouns. During training, the model uses the cross-entropy loss function and stochastic gradient descent optimization algorithm, with a learning rate of 0.001, a batch size of 32, and 20 training epochs. The model output labels "view" as an action verb, "server logs" as a resource noun, and "project X" as a business object noun. Based on the action verb, the model matches the operation type as "view"; based on the resource noun, it matches the resource type as "server logs"; and based on the business object noun, it matches the resource instance as a unique identifier for "project X". By leveraging the sequence labeling capabilities of deep learning models, unstructured natural language text can be converted into structured operation types, resource types, and resource instance information, thereby lowering the application threshold for users.

[0131] Specifically, the determined operation type, resource type, and resource instance are concatenated according to preset combination rules to generate a permission code. This permission code is then compared character by character with the extracted target shadow permission identifier to verify consistency in the operation type, resource type, and resource instance portions. If all three levels match successfully, an application form is generated, containing fields such as permission code, user identifier, application time, application reason text, target shadow permission identifier, and application form status, and stored in the application form database. If any level fails to match, a corresponding correction prompt is generated based on the location of the failure. This dual verification of semantic parsing results and the user's selected permissions effectively prevents erroneous applications due to user misunderstandings and avoids situations where the approval process is rejected due to inaccurate application information.

[0132] Furthermore, the application risk is analyzed and a risk value is calculated. An approval path is dynamically selected for authorization, and a first drift token is generated, including:

[0133] S701. Obtain the permission code and user identifier from the application form, determine the first risk score based on the permission code, and adjust the first risk score by combining the user's historical application records to obtain the risk value.

[0134] S702. Determine the approval type based on the risk value, analyze the user's department node and the department node of the permission resource according to the approval type, determine the approval path and authorize, and generate the first drift token.

[0135] In this embodiment, the permission code and user identifier are extracted from the application form. The permission configuration library is queried according to the permission code to obtain the data sensitivity level and operation hazard level corresponding to the permission. The data sensitivity level is divided into three levels: high, medium and low, based on the confidentiality of the data involved in the permission. The operation hazard level is divided into three levels: high, medium and low, based on the impact of the permission on the system after execution. The two levels are mapped to numerical values ​​and then added together to obtain the first risk score.

[0136] Specifically, the system obtains the user's total number of applications, the number of rejected applications, and the number of instances of permission abuse within the past ninety days. The ratio of rejected applications to total applications is calculated as the application reputation coefficient. The number of permission abuse records determines the behavioral risk coefficient. Multiplying these two coefficients yields the user risk correction coefficient. The system obtains the scenario fingerprint vector of the current session, extracts the network location tag and device trust level tag, and determines the first and second adjustment factors based on a preset scenario risk mapping table. Multiplying these two factors yields the scenario risk adjustment factor. The first risk score is multiplied by the user risk correction coefficient and then by the scenario risk adjustment factor to obtain the risk value.

[0137] For example, if the first risk score for a certain permission is 6 points, the user's application credibility coefficient is 0.8, and the behavioral risk coefficient is 1, then the user risk adjustment coefficient is 0.8, the scenario risk adjustment factor is 1.6, and the final risk value is 7.68. By comprehensively quantifying the three dimensions of permission attributes, user historical behavior, and current environmental risk, the risk value can truly reflect the actual risk level of each application, providing accurate data support for the dynamic selection of subsequent approval paths.

[0138] Specifically, the application risk value is compared with multiple preset threshold ranges to determine the approval type. The system presets four types: circuit breaker authorization, fast approval, standard approval, and joint review, and their corresponding risk value threshold ranges. For example, circuit breaker authorization is a risk value of less than or equal to 4, fast approval is greater than 4 and less than or equal to 7, standard approval is greater than 7 and less than or equal to 11, and joint review is greater than 11.

[0139] For circuit breaker authorization types, the system directly generates a temporary authorization record, skipping the manual approval step; for other types, the system enters the regular approval process. The system obtains the node path of the user's department in the organizational structure tree, and the node path of the department to which the authorized resource belongs in the organizational structure tree. It calculates the intersection of the two paths, selects the deepest-level department node from the intersection, and designates the department head as the first approver. Based on the approval type, it determines whether a security officer or department head needs to be added as a second or third approver. The system generates an approval task and pushes it to the approvers. After receiving approval instructions from all approvers, it generates an authorization credential. Based on the authorization credential, it generates a session identifier and an initial version number. The session identifier, initial version number, authorization validity period, and user identifier are combined and encrypted to generate the first drift token. The session identifier is then associated with the permission list and stored in the server cache. Through risk-value-driven approval type selection, the system dynamically adapts the permission approval process to the risk level, enabling rapid response to low-risk applications requiring circuit breaker authorization and strict review of high-risk applications. Simultaneously, the department path intersection algorithm intelligently determines the approver, avoiding the difficulty of determining the approver in cross-department approvals.

[0140] Furthermore, based on the second drift token, the user operation process is simulated and analyzed to determine permission usage and calculate usage entropy. Permissions with usage entropy below a preset threshold are selected and a permission deviation heatmap is generated. Based on the permission deviation heatmap, the corresponding authorizations are revoked, including:

[0141] S801. Based on the second drift token, simulate and analyze the user's operation process and the use of permissions, analyze the number of times permissions are used and the usage time, and calculate the usage entropy;

[0142] S802. Filter out permissions whose usage entropy is lower than the preset usage threshold and generate a permission deviation heatmap;

[0143] S803. Based on the deviation of permissions from the heatmap, revoke the corresponding permissions and cancel the authorization.

[0144] In this embodiment, a second drift token generated during a user session is used as the tracking identifier. Each user operation record is collected from the audit log, including the operation timestamp, permission code, and the scenario fingerprint vector at the time of the operation. Using a 90-day statistical period, each permission held by each user is analyzed independently, calculating the cumulative number of uses of that permission within the period and the time difference between the last use and the current time in days. A scenario weight value is also attached to each operation record, determined based on the network location label and device trust level label in the scenario fingerprint vector at the time of the operation. For example, an operation on a high-trust device on the internal network is weighted at 1.0, while an operation on a low-trust device on the public network is weighted at 0.5. The cumulative number of uses, the time difference in days, and the cumulative weight sum are combined. A higher usage entropy value is achieved with more usages, a smaller time difference, and a higher total weight, and vice versa. The usage entropy value for each user and permission combination is output. By quantifying permission activity in multiple dimensions, the usage scenario weight corrects for the differences in the evidentiary value of usage records under different security environments. The usage entropy value can truly reflect the actual necessity and value of the permission.

[0145] Specifically, permissions with usage entropy below a preset usage threshold are filtered out and a permission deviation heatmap is generated; by comparing job baselines, two types of permissions can be distinguished: idle and over-allocated idle permissions; and by visualizing the heatmap, security administrators can intuitively locate high-risk departments and permission types with unreasonable permission configurations.

[0146] Furthermore, a differentiated recycling strategy is implemented based on the deviation of permission configurations. For departments with deviations below the first threshold, an automatic recycling process is executed for idle permissions, directly removing them from the user's valid permission list. The first threshold can be set to 10%, and the second threshold can be set to 30%. For departments with deviations between the first and second thresholds, a recycling confirmation task is generated and pushed to the department head for confirmation before recycling is executed. For departments with deviations above the second threshold, over-allocated idle permissions are forcibly recycled, and the department's job competency graph node is marked as a node to be optimized, triggering a partial re-verification of the job baseline permission list. The first and second thresholds can be set according to the system's control precision requirements.

[0147] Specifically, the reclaimed permission codes, department identifiers, and reclamation methods are stored in the reclamation audit log. Feedback data is input into the optimization queue of the job competency graph for periodic adjustments to the theoretical permission set configuration of job nodes. Through deviation-driven differentiated reclamation, refined governance is achieved, including automatic reclamation for low-deviation departments to reduce manual intervention, confirmation by supervisors for medium-deviation departments to ensure business continuity, and mandatory reclamation for high-deviation departments to optimize baseline configuration from the source.

[0148] Furthermore, permissions with usage entropy below a preset usage threshold are filtered out and a permission deviation heatmap is generated, including:

[0149] S901. Filter out permissions whose usage entropy is lower than the preset usage threshold, and compare them with the baseline permission list of the user's current position. If they are in the baseline permission list, mark them as idle permissions for the position; otherwise, mark them as over-configured idle permissions.

[0150] S902. Aggregate idle permissions and over-allocated idle permissions for user departments, calculate the ratio of the number of over-allocated idle permissions to the number of idle permissions for positions as the permission configuration deviation, and generate a permission deviation heatmap with department identifier and permission type as dimensions, and with the degree of concentration of idle permissions and permission configuration deviation as values.

[0151] In this embodiment, the usage entropy value of each user and permission combination is received as input. This entropy value is compared with a preset usage threshold, which can be set according to the system's control precision requirements (e.g., 0.1). Permissions with usage entropy below the threshold are filtered out and marked as dormant permissions. The current job identifier corresponding to each dormant permission is obtained, and the baseline permission list for that job is queried from the job capability graph. The baseline permission list is a pre-configured theoretical permission set for each job node, reflecting the range of permissions that the job should have for normal business operations. The dormant permission is compared with the baseline permission list of the user's current job. If the permission is in the baseline permission list, it is marked as an idle permission for the job, indicating that although the permission belongs to the job's scope, the user has not used it. If the permission is not in the baseline permission list, it is marked as an over-configured idle permission, indicating that the permission is a legacy over-configuration. By accurately classifying dormant permissions through job baseline comparison, differentiated recovery can be achieved.

[0152] Specifically, the system receives records of idle and over-allocated idle permissions for completed positions. It then iterates through all department nodes in the organizational structure tree, counts the total number of idle and over-allocated idle permissions for all users under each department, calculates the ratio of over-allocated idle permissions to idle permissions for positions, and obtains the permission configuration deviation for that department. The higher the deviation, the more serious the over-allocation problem.

[0153] Idle permissions within departments are categorized and statistically analyzed based on permission type. The idle permission concentration is calculated as the number of idle permissions of a certain type divided by the total number of authorized permissions of that type in the department. A two-dimensional table is constructed with department identifiers as rows and permission types as columns. The idle concentration value for each combination of department and permission type is mapped to a color gradient, and the permission configuration deviation subscripts for that department are overlaid in the cells to generate a permission deviation heatmap. By aggregating at the departmental level, the issue of idle permissions is elevated from the user level to the organizational level. The deviation calculation quantifies the severity of departmental over-provisioning, and the heatmap visualization allows security administrators to intuitively locate departments and permission types with concentrated problems, improving the efficiency of permission control.

[0154] like Figure 3 As shown, the hierarchical role-based access control system is used to implement a hierarchical role-based access control method, including:

[0155] The permission analysis module constructs a job competency graph based on multi-tenant organizational structure data, collects the user's current environment data to generate a scene fingerprint vector, and matches the user's job traversal results in the job competency graph with the scene fingerprint vector to obtain the first permission set.

[0156] The permission response module responds to shadow permission requests in the first permission set, parses the request reason to generate an application form, analyzes the application risk of the application form and calculates the risk value, dynamically selects the approval path for authorization, and generates the first drift token.

[0157] The permission optimization module performs authentication based on the first drift token during the user session, analyzes the user's real-time operation behavior, downgrades the permissions of the first drift token that triggers preset risk behavior, and obtains the second drift token.

[0158] The dynamic authorization module simulates and analyzes user operation process permission usage based on the second drift token and calculates usage entropy. It filters out permissions with usage entropy lower than the preset usage threshold and generates a permission deviation heatmap. Based on the permission deviation heatmap, it cancels the corresponding authorization to dynamically control role permissions.

[0159] Example 2

[0160] Taking a multi-tenant SaaS office platform used by a certain enterprise as an example, the platform serves multiple subsidiaries, each of which is an independent tenant. Suppose that employee B of tenant A is a sales specialist, and his daily work requires permission to view customer information and export sales data.

[0161] Step 1: Building the Basic Model and Pre-generating Permissions. Employee B logs into the intranet system at 9:00 AM on a weekday using a company-issued trusted laptop. The system collects environmental data and generates a scenario fingerprint vector: working hours, intranet, and highly trusted device. Starting with Employee B's sales specialist position, the system traverses the job competency graph, obtaining the permission items for sales supervisor and sales director along inheritance edges, forming a theoretical permission set. The system matches each permission item in this theoretical permission set with the scenario fingerprint vector: the environmental access condition for customer information viewing permission is working hours or intranet; a successful match adds it to the available permission subset. The environmental access condition for sales data export permission is working hours, intranet, and a highly trusted device; a successful match also adds it to the available permission subset. After logging in, Employee B can directly use these two permissions.

[0162] Step 2: Shadow permission triggering and dynamic authorization.

[0163] One evening, employee B was on a business trip and logged into the system using his personal mobile phone via public Wi-Fi at 8 PM. The system collected the following scenario fingerprint vectors: non-working hours, public network, and low-trust device. At this time, the access conditions for customer information viewing permissions were relatively lenient, and it was still classified as a subset of available permissions; however, the sales data export permission was classified as a shadow permission subset because it did not meet the restrictions of working hours and the intranet. Employee B saw that the sales data export button on the interface was grayed out. After clicking it, a prompt appeared: "The current environment does not support export operations. Do you want to apply for temporary authorization?" Employee B clicked the application and filled in the reason for the application: "Due to urgent customer needs, I need to export this week's sales data." The system performed semantic analysis on the application reason, identified the action verb "export" and the resource noun "sales data," matched the permission code, and found that it matched the target shadow permission identifier selected by the user, generating an application form.

[0164] The system calculates the risk value: the data sensitivity level of the sales data export permission is medium, the operational hazard level is medium, and the basic risk score is 5 points; employee B's historical behavior is good, and the user risk correction coefficient is 1; the current scenario fingerprint is a public network and a low-trust device, and the scenario risk adjustment factor is 1.5 × 1.5 = 2.25, resulting in a final risk value of 11.25. This risk value falls within the standard approval threshold range, and the system determines the approval path: the nearest common ancestor node in the organizational structure tree between employee B's sales department and the sales center to which the sales data resources belong is the sales director, therefore the approver is the sales director. The system pushes the approval task to the sales director's to-do list, and the sales director views the application reason through an in-app notification and clicks "approval." The system generates an authorization credential, valid for 2 hours, and generates the first drift token, returning it to employee B.

[0165] Step 3: Runtime Hot Degradation. After employee B was granted temporary export permissions, they successfully exported sales data within 2 hours. However, the system continuously monitored their actions and detected that employee B attempted to export data 3 times within 5 consecutive minutes, triggering the risk policy "exporting more than 2 times within one minute." The system immediately updated the permission list for that session in the server cache, downgrading the export permission to read-only and incrementing the version number. When employee B clicked export again, they received a permission insufficient prompt, but the session remained valid, and they could still view the data.

[0166] Step Four: Permission Revocation and Optimization. Three months later, the system performs a permission usage entropy analysis. Employee B's sales data export permission was only used once within 90 days, resulting in a low cumulative usage count. The last use was 89 days ago, and the total cumulative weight is also low. The calculated usage entropy is 0.05, below the threshold of 0.1. The system marks this permission as dormant and freezes it, and the export button on Employee B's interface becomes grayed out and indicates a dormant state. If Employee B has a subsequent export need, they can reactivate the permission with one click; if it is not reactivated within 30 days, the system will automatically revoke the permission and report the revoke record to the job competency graph, prompting the security administrator to assess whether to reduce the recommended weight of the sales data export permission from the baseline of the sales specialist job.

[0167] The above description is merely a preferred embodiment of this application. The scope of protection of this application is not limited to the above embodiments. All technical solutions falling within the scope of this application's concept are within the scope of protection of this application. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of this application should also be considered within the scope of protection of this application.

Claims

1. A hierarchical role-based permission dynamic authorization and control method, characterized in that, include: A job competency graph is constructed based on multi-tenant organizational structure data. User current environment data is collected to generate scenario fingerprint vectors. The traversal results of user jobs in the job competency graph are matched with scenario fingerprint vectors to obtain the first permission set. In response to a shadow permission request in the first permission set, the request reason is parsed to generate an application form, the application risk of the application form is analyzed and the risk value is calculated, and the approval path is dynamically selected for authorization, generating the first drift token; During a user session, authentication is performed based on the first drift token. The user's real-time operational behavior is analyzed, and the permissions of the first drift token that triggers a preset risk behavior are downgraded to obtain the second drift token. Based on the second drift token, the user operation process is simulated and analyzed to determine the use of permissions and calculate the usage entropy. Permissions with usage entropy lower than the preset usage threshold are selected and a permission deviation heatmap is generated. Based on the permission deviation heatmap, the corresponding authorization is cancelled to dynamically control the authorization of role permissions.

2. The hierarchical role-based permission dynamic authorization and control method according to claim 1, characterized in that, The process involves constructing a job competency graph based on multi-tenant organizational structure data, collecting users' current environment data to generate scene fingerprint vectors, and matching the traversal results of users' jobs in the job competency graph with the scene fingerprint vectors to obtain a first permission set, including: Based on multi-tenant organizational structure data, analyze job relationships and construct job competency maps; Collect the user's current environment data and input it into a preset scene fingerprint generation model to generate a scene fingerprint vector; The first permission set is obtained by matching the traversal results of the user's job position in the job competency graph with the scene fingerprint vector.

3. The hierarchical role-based permission dynamic authorization and control method according to claim 2, characterized in that, The process of analyzing job relationships and constructing a job competency map based on multi-tenant organizational structure data includes: Based on multi-tenant organizational structure data, analyze job relationships, and construct the first job competency graph with each job as a node and the job relationships between jobs as edges. Configure corresponding job attributes for each job node in the first job competency graph, and configure corresponding relationship types for each edge to obtain the job competency graph.

4. The hierarchical role-based permission dynamic authorization and control method according to claim 3, characterized in that, The step of matching the user's job traversal results in the job competency graph with the scene fingerprint vector to obtain the first permission set includes: Based on the current user's job identifier, starting from the job node corresponding to the job identifier, traverse along the connection relationship in the job competency graph, integrate the permission items of the nodes on the traversal path, and obtain the user's initial permission set. Analyze the scenario fingerprint range configured for each permission item in the initial permission set; The scene fingerprint vector is compared with the scene fingerprint range. If the scene fingerprint vector is within the scene fingerprint range, the corresponding permission item is divided into an available permission subset. If the scene fingerprint vector is outside the scene fingerprint range, the corresponding permission item is divided into a shadow permission subset. The available permission subset and the shadow permission subset are integrated to obtain the first permission set.

5. The hierarchical role-based permission dynamic authorization and control method according to claim 1, characterized in that, The response to the shadow permission application in the first permission set includes parsing the application reason to generate an application form, analyzing the application risk of the application form and calculating the risk value, dynamically selecting the approval path for authorization, and generating a first drift token, including: In response to a shadow permission request in the first permission set, the request is parsed to determine the operation type, resource type, and resource instance of the request, and a request form is generated. Analyze the application risk of the application form and calculate the risk value, dynamically select the approval path for authorization, and generate the first drift token.

6. The hierarchical role-based permission dynamic authorization and control method according to claim 5, characterized in that, The response to the shadow permission request in the first permission set involves parsing the request, determining the operation type, resource type, and resource instance of the request, and generating a request form, including: In response to a request for shadow permissions in the first permission set, extract the request reason text and the target shadow permission identifier from the request; Semantic analysis is performed on the application reason text to identify action verbs, resource nouns, and business object nouns, and to determine the operation type, resource type, and resource instance of the application. The operation type, resource type, and resource instance are combined and matched with the target shadow permission identifier to generate an application form.

7. The hierarchical role-based permission dynamic authorization and control method according to claim 6, characterized in that, The process of analyzing the application risk of the application form, calculating the risk value, dynamically selecting the approval path for authorization, and generating the first drift token includes: Obtain the permission code and user identifier from the application form, determine the first risk score based on the permission code, and adjust the first risk score by combining the user's historical application records to obtain the risk value; Based on the risk value, the approval type is determined. According to the approval type, the node of the user's department and the node of the department to which the permission resources belong are analyzed to determine the approval path and authorize it, and generate the first drift token.

8. The hierarchical role-based permission dynamic authorization and control method according to claim 1, characterized in that, The process of simulating and analyzing user operation process based on the second drift token, calculating usage entropy, filtering out permissions with usage entropy below a preset usage threshold, generating a permission deviation heatmap, and canceling corresponding authorizations based on the permission deviation heatmap includes: Based on the second drift token simulation analysis, the user operation process permission usage is analyzed, the number of permission usages and usage time are analyzed, and the usage entropy is calculated; Filter out permissions whose usage entropy is lower than a preset usage threshold and generate a permission deviation heatmap; If permissions deviate from the heatmap, the corresponding permissions will be revoked and authorization will be cancelled.

9. The hierarchical role-based permission dynamic authorization and control method according to claim 8, characterized in that, The step of filtering out permissions whose usage entropy is lower than a preset usage threshold and generating a permission deviation heatmap includes: Filter out permissions whose usage entropy is lower than the preset usage threshold, and compare them with the baseline permission list of the user's current position. If they are in the baseline permission list, mark them as idle permissions for the position; otherwise, mark them as over-configured idle permissions. The idle permissions and over-allocated idle permissions of user departments are aggregated, and the ratio of the number of over-allocated idle permissions to the number of idle permissions of positions is calculated as the permission configuration deviation. Using department identifier and permission type as dimensions, and the degree of concentration of idle permissions and permission configuration deviation as values, a permission deviation heatmap is generated.

10. A hierarchical role-based access control system, characterized in that: The method for implementing the hierarchical role-based permission dynamic authorization and control method as described in any one of claims 1 to 9 includes: The permission analysis module constructs a job competency graph based on multi-tenant organizational structure data, collects the user's current environment data to generate a scene fingerprint vector, and matches the user's job traversal results in the job competency graph with the scene fingerprint vector to obtain the first permission set. The permission response module responds to shadow permission requests in the first permission set, parses the request reason to generate an application form, analyzes the application risk of the application form and calculates the risk value, dynamically selects the approval path for authorization, and generates the first drift token. The permission optimization module performs authentication based on the first drift token during the user session, analyzes the user's real-time operation behavior, downgrades the permissions of the first drift token that triggers preset risk behavior, and obtains the second drift token. The dynamic authorization module simulates and analyzes user operation process permission usage based on the second drift token and calculates usage entropy. It filters out permissions with usage entropy lower than the preset usage threshold and generates a permission deviation heatmap. Based on the permission deviation heatmap, it cancels the corresponding authorization to dynamically control role permissions.

Images