Enterprise internal cross-system authentication processing method, system, equipment and medium

Abstract

The invention discloses an enterprise internal cross-system authentication processing method and system, equipment and a medium, and the method specifically comprises the steps: generating a differential asymmetric encryption key for a system pair with a bidirectional authentication edge in an enterprise through a key distribution center based on the node security level of a system authentication relation graph; when a cross-system access request is detected, generating a temporary token carrying a fine-grained permission tag and failure time according to the differentiated asymmetric encryption key; based on the temporary token, extracting a historical behavior sequence of the associated edge through an anomaly detection model, and when an abnormal mode is detected, triggering permission recovery and freezing the temporary token; and for the temporary token which is not frozen, creating a default role with a time limit for the unregistered user through the target system. According to the invention, safe and flexible enterprise internal cross-system authentication processing with self-adaptive capability is realized, and the safety and system performance of cross-system authentication are effectively guaranteed.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a method, system, device, and medium for cross-system authentication within an enterprise. Background Technology

[0002] In the process of enterprise system development and application, enterprises typically deploy multiple application systems to meet different business needs. These systems are functionally independent, but they are often closely related in business processes. As a result, in actual business operations, users often need to switch from one system to another, which creates the need for cross-system authentication.

[0003] Currently, Single Sign-On (SSO) is a commonly used cross-system authentication method in enterprise application systems. SSO login uses a unified authentication platform, allowing users to access multiple related systems with a single login, simplifying the login process and improving user experience to some extent. However, this authentication method has many limitations in practical applications.

[0004] On the one hand, not all enterprise application systems have the conditions to build a unified authentication platform. Some enterprises, due to complex system architectures and numerous legacy systems, find it difficult to integrate various systems under a unified authentication platform, making it impossible to fully adopt SSO login to achieve cross-system authentication.

[0005] On the other hand, even if some enterprises have implemented SSO login, they still face challenges in access control. Enterprise application systems typically have complex permission verification mechanisms, and different systems have different access permission settings for resources such as menus and data. During cross-system authentication, ensuring that a user, after being authenticated in one system, can accurately and securely use their corresponding menu / data permissions in another system is a key issue that needs to be addressed. Existing SSO login methods are insufficient in the fine-grained and dynamic management of permission transfer and verification, making it difficult to meet the complex and ever-changing business needs and security requirements of enterprises.

[0006] Furthermore, as businesses continue to grow and systems are constantly updated, the security and flexibility of cross-system authentication processes become increasingly important. Traditional cross-system authentication methods are gradually proving inadequate in addressing new security threats, adapting to dynamic system changes, and optimizing user experience. Summary of the Invention

[0007] The purpose of this invention is to provide a method, system, device, and medium for cross-system authentication within an enterprise, which realizes secure, flexible, and adaptive cross-system authentication processing within an enterprise, effectively ensuring the security of cross-system authentication and system performance, thereby solving at least one of the aforementioned problems in the prior art.

[0008] In a first aspect, the present invention provides a method for processing cross-system authentication within an enterprise, the method specifically comprising: A system authentication relationship graph is constructed using a graph database. The nodes of the system authentication relationship graph are used to represent system entities and security attributes, and the edges of the system authentication relationship graph are used to represent authentication relationships between systems and dynamically update access weights. Based on the node security level of the system authentication relationship graph, differentiated asymmetric encryption keys are generated for system pairs with two-way authentication edges within the enterprise through the key distribution center; When a cross-system access request is detected, a temporary token carrying fine-grained permission tags and expiration times is generated based on the differentiated asymmetric encryption key. The request characteristics are then injected into the system authentication relationship graph to update the corresponding edge weights in real time. Based on temporary tokens, the historical behavior sequence of associated edges is extracted through an anomaly detection model. When an abnormal pattern is detected, permission is revoked and the temporary token is frozen. For temporary tokens that are not frozen, a time-limited default role is created for unregistered users through the target system, and the new user node is inserted into the system authentication relationship graph and an associated edge with the source system is generated. Based on the edge weight change trend of the system authentication relationship graph, the authentication traffic prediction model outputs the predicted load value. When the predicted load value exceeds the threshold, the authentication container instance of the Kubernetes cluster is automatically scaled up or down.

[0009] Secondly, the present invention provides a cross-system authentication processing system within an enterprise, the system specifically comprising: The graph construction module is used to construct a system authentication relationship graph through a graph database. The nodes of the system authentication relationship graph are used to represent system entities and security attributes, and the edges of the system authentication relationship graph are used to represent authentication relationships between systems and dynamically update access weights. The key generation module is used to generate differentiated asymmetric encryption keys for system pairs with two-way authentication edges within an enterprise, based on the node security level of the system authentication relationship graph and through the key distribution center. The token generation module is used to generate a temporary token carrying fine-grained permission tags and expiration time based on the differentiated asymmetric encryption key when a cross-system access request is detected. The request characteristics are injected into the system authentication relationship graph in real time to update the corresponding edge weights. The anomaly detection module is used to extract the historical behavior sequence of associated edges based on temporary tokens through an anomaly detection model. When an abnormal pattern is detected, it triggers permission revocation and freezes the temporary token. The user registration module is used to create time-limited default roles for unregistered users through the target system for temporary tokens that have not been frozen, and to insert the new user node into the system authentication relationship graph and generate an association edge with the source system. The container scaling module is used to automatically scale the certified container instances of the Kubernetes cluster based on the edge weight change trend of the system authentication relationship graph and the output of the predicted load value through the authentication traffic prediction model. When the predicted load value exceeds the threshold, the module automatically scales the certified container instances of the Kubernetes cluster.

[0010] Thirdly, the present invention provides a computer device, comprising: a memory and a processor, and a computer program stored in the memory, wherein when the computer program is executed on the processor, it implements a processing method for cross-system authentication within an enterprise as described in any of the above methods.

[0011] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements a cross-system authentication processing method for an enterprise as described in any of the above methods.

[0012] Compared with the prior art, the present invention has at least one of the following technical effects: 1. This invention enables secure, flexible, and adaptive cross-system authentication processing within enterprises, effectively ensuring the security and system performance of cross-system authentication.

[0013] 2. This invention creates nodes, generates two-way authentication certificates, creates authentication edges, obtains the security parameter set of cross-system authentication events and calculates new weights, and updates keys when necessary, thus ensuring the accuracy and security of the system authentication relationship graph and providing a reliable foundation for subsequent cross-system authentication.

[0014] 3. This invention generates differentiated asymmetric encryption keys based on node security levels, selects appropriate key lengths and update cycles according to system security levels, improves key security and management efficiency, and effectively prevents the risk of key leakage.

[0015] 4. This invention generates temporary tokens carrying fine-grained permission tags and expiration times based on differentiated asymmetric encryption keys, and updates edge weights in real time, thereby realizing fine-grained permission control and dynamic security assessment of cross-system access requests, and improving the security and flexibility of cross-system authentication.

[0016] 5. This invention extracts the historical behavior sequence of associated edges through an anomaly detection model, detects abnormal patterns and triggers permission revocation and temporary token freezing, effectively preventing abnormal behavior and security threats in the cross-system authentication process and ensuring system security.

[0017] 6. For temporary tokens that are not frozen, this invention creates a default role with a time limit for unregistered users in the target system, inserts the new user node into the system authentication relationship graph and generates associated edges, thereby realizing convenient access and permission management for unregistered users in the cross-system authentication process, improving user experience and system availability.

[0018] 7. Based on the edge weight change trend of the system authentication relationship graph, this invention outputs the predicted load value through the authentication traffic prediction model and automatically scales up and down the authentication container instances of the Kubernetes cluster, realizing the elastic scaling of the authentication service, effectively coping with system load changes, and ensuring system performance and stability. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating a cross-system authentication processing method within an enterprise, according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of an enterprise internal cross-system authentication processing system provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0021] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0022] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0023] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0024] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0025] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0026] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0027] In this application embodiment, the entity executing the process includes a terminal device. This terminal device includes, but is not limited to, devices capable of executing the methods disclosed in this application, such as servers, computers, smartphones, and tablets. Figure 1 A flowchart illustrating an embodiment of the enterprise internal cross-system authentication processing method disclosed in this invention is shown below: S101, construct a system authentication relationship graph through a graph database. The nodes of the system authentication relationship graph are used to represent system entities and security attributes, and the edges of the system authentication relationship graph are used to represent authentication relationships between systems and dynamically update access weights.

[0028] In this embodiment, a graph database with good performance, scalability and ease of use is selected, such as Neo4j. Neo4j has powerful graph data processing capabilities and can efficiently store and query the relationships between nodes and edges, meeting the system's requirements for constructing an authentication relationship graph.

[0029] Create a node for each application system. Each node contains basic information such as system name, system identifier, system type (e.g., financial system, human resources system), and system version. This information helps in accurately identifying and managing each system. Add security-related attributes to the nodes, such as security level (divided according to the system's importance and sensitivity, e.g., high, medium, low), authentication method (e.g., username / password authentication, certificate authentication), and security policy (e.g., access control policy, data encryption policy). The security level is used for subsequent key generation and access control, while the authentication method and security policy help with security verification during cross-system authentication. Import the collected system information as node data into the graph database. During the import process, set the corresponding attribute values ​​for each node according to the predefined node attribute format.

[0030] Based on the authentication relationships between systems, corresponding edges are created. Authentication relationship attributes and initial access weight values ​​are set for each edge. For example, if there is a two-way authentication relationship between system A and system B, and the authentication type is token-based authentication with a high authentication frequency, then a two-way edge connecting system A and system B is created in the graph database, and corresponding attribute values ​​are set. Edges are used to represent the authentication relationships between systems. Edge attributes include authentication direction (one-way or two-way authentication), authentication type (such as token-based authentication, certificate-based authentication, etc.), and authentication frequency (recording the frequency of authentication between systems). These attributes help describe the specific methods and characteristics of authentication between systems.

[0031] Access weight is a dynamically updated attribute used to reflect the activity and importance of authentication between systems. Initially, an initial access weight value is set for each edge based on the degree of business correlation between the systems and historical authentication data. For example, if two systems are closely related in business and frequently engage in data interaction and authentication operations, the initial access weight value will be higher; conversely, if the two systems have less business correlation, the initial access weight value will be lower.

[0032] This embodiment clearly demonstrates the authentication relationships and security attributes between various application systems within an enterprise. Dynamically updated access weights reflect the activity and importance of authentication between systems in real time, providing strong support for subsequent key generation, permission management, and resource allocation. Furthermore, this graph exhibits good scalability and maintainability, adapting to the continuous development of enterprise business and ongoing system updates.

[0033] S102, based on the node security level of the system authentication relationship graph, generates differentiated asymmetric encryption keys for system pairs with two-way authentication edges within the enterprise through the key distribution center.

[0034] In this embodiment, key dimensions for assessing the security level of a system are identified, such as data sensitivity, business criticality, and compliance requirements. Based on these dimensions, the system's security level is divided into multiple levels, such as high, medium, and low. Detailed assessment indicators and standards are developed for each level to ensure accurate security level evaluation of each system.

[0035] The query function of the graph database is used to traverse the constructed system authentication relationship graph. Starting from any node in the graph, nodes with a two-way authentication relationship are searched along the edge direction. A two-way authentication relationship means that two systems authenticate each other; this relationship is special in cross-system authentication and requires more stringent key management. The identified system pairs with two-way authentication edges are recorded, including the system pair's name, identifier, and node information in the graph. This information will serve as the basis for subsequently generating differentiated asymmetric encryption keys.

[0036] The key distribution center selects asymmetric encryption algorithms suitable for the enterprise's needs, such as RSA and ECC (Elliptic Curve Cryptography). When choosing an algorithm, factors such as security, performance, and key length must be considered comprehensively. For example, RSA offers high security but has a long key length and relatively high computational complexity; ECC, on the other hand, can use a shorter key length at the same security level, resulting in higher computational efficiency and making it suitable for resource-constrained environments.

[0037] Establish a strict key management strategy, encompassing key generation, storage, distribution, updating, and destruction. For example, key generation should be conducted in a secure environment, using devices such as Hardware Security Modules (HSMs) to protect the key generation process; key storage should employ encrypted storage methods to prevent key leakage; key distribution should be conducted through secure channels, and the key distribution history should be recorded; keys should be updated regularly to reduce the risk of key leakage, and keys should be securely destroyed when no longer needed.

[0038] The security level of nodes in the system authentication relationship graph is mapped to key generation parameters. For example, for high-security system pairs, a longer key length and more complex key generation algorithm parameters are used to enhance key security; for medium-security system pairs, the key length and algorithm parameters can be appropriately reduced; for low-security system pairs, a relatively simple key generation method is selected while meeting basic security requirements.

[0039] The key distribution center generates an asymmetric encryption key pair, including a public key and a private key, for each system pair with a two-way authentication edge based on the mapped parameters. The public key can be publicly distributed and used to encrypt data or verify signatures; the private key must be kept strictly confidential and is only stored and used by the system possessing it for decrypting data or generating signatures. The generated key is associated with the corresponding system pair, and the association information is stored in the key distribution center's database. The association information should include the system pair's identifier, the public key, the storage location of the private key, and the key's expiration date.

[0040] The key distribution center distributes public keys to other systems associated with it through secure communication channels. The distribution process may employ encrypted transmission protocols, such as SSL / TLS, to ensure that the public keys are not stolen or tampered with during transmission. Simultaneously, a digital signature is attached to each public key, which the recipient can verify to confirm the authenticity and integrity of the public key. After receiving the public key, each system deploys it into its own authentication module. During deployment, the system should securely store and manage the public key according to the key management policy requirements. At the same time, the system securely stores its private key locally and takes necessary measures to prevent private key leakage, such as restricting access to the private key storage file and using hardware encryption devices to protect the private key.

[0041] In this embodiment, based on the node security level of the system authentication relationship graph, differentiated asymmetric encryption keys are generated for system pairs with bidirectional authentication edges within the enterprise, effectively improving the security of inter-system authentication communication. Different security level system pairs use keys of different strengths, satisfying the stringent security requirements of high-security systems while avoiding the performance overhead caused by using excessively strong keys in low-security systems. Simultaneously, a strict key management strategy and update mechanism ensure the security and validity of the keys, providing reliable security for cross-system authentication within the enterprise.

[0042] S103, when a cross-system access request is detected, a temporary token carrying fine-grained permission tags and expiration time is generated based on the differentiated asymmetric encryption key, and the request characteristics are simultaneously injected into the system authentication relationship graph to update the corresponding edge weights in real time.

[0043] In this embodiment, a request capture module is deployed at the boundary of the enterprise network or at the entry point of each application system. This module can be a network proxy server, an application gateway, or an interceptor integrated into the system code. When a user initiates a request to access another system from one system, the request capture module can detect the request in real time and obtain basic information about the request, such as the source system identifier, target system identifier, user identifier, and request time. A preliminary legality check is performed on the captured cross-system access request. The check includes whether the request format conforms to the specifications, whether the source and target systems are in the list of systems allowed for cross-system authentication, and whether the user identifier is valid. If the request is invalid, it is directly rejected, and the corresponding error information is recorded.

[0044] After generating differentiated asymmetric encryption keys, the key distribution center distributes the public keys to relevant systems, while the private keys are securely stored at the key distribution center or in a specific secure storage area of ​​each system. When a cross-system access request is detected, the target system first determines the storage location of the corresponding key pair based on the source system identifier and its own system identifier.

[0045] The target system retrieves the public key from a differentiated asymmetric encryption key pair with a two-way authentication edge between itself and the source system from a secure storage area. (If the source system generates the token and sends it to the target system, the source system obtains its own private key for encryption, and the target system obtains the corresponding public key for decryption and verification. This embodiment uses the scenario where the target system generates the token as an example, so the target system obtains its own private key for subsequent encryption-related operations, and simultaneously obtains the source system's public key for scenarios such as authorization verification.) During the key acquisition process, the system performs strict identity verification and authorization checks to ensure that only legitimate systems can obtain the corresponding key.

[0046] The target system sends a query request to the access control system to retrieve the user's authenticated access information in the source system. The access control system stores user access configurations across various systems, including access permissions to menus, data, and functional modules. Based on the user identifier and the source system identifier, the access control system returns a detailed list of permissions the user possesses in the source system. According to the enterprise's access control strategy, the collected access information is mapped to fine-grained access tags. For example, a user's access permission to a specific menu item is mapped to a specific menu access tag, and a user's query, modification, and deletion permissions for a certain type of data are mapped to corresponding data operation access tags. Access tags should have clear meanings and unique identifiers to ensure accurate transmission in temporary tokens.

[0047] Sensitive information in the temporary token, such as user identifiers and fine-grained permission tags, is encrypted using the target system's private key obtained from the key distribution center. The encryption process employs an asymmetric encryption algorithm to ensure that even if the token is intercepted during transmission, its sensitive information cannot be illegally tampered with or obtained. Simultaneously, the target system's public key and the encrypted token content are combined to form a complete temporary token.

[0048] When the request capture module detects a cross-system access request, it extracts request characteristics in real time. For example, it calculates the request timestamp by recording the request's initiation and end times; it obtains the request frequency by counting the number of requests between the same source and target systems within a certain time window; it determines the request's data volume by analyzing the size of the data carried in the request; and it determines the requested resource type by parsing the target URL or interface name.

[0049] Based on the source system identifier and target system identifier, locate the corresponding edge in the system authentication relationship graph. Input the extracted request features into the preset edge weight update rules to calculate the new access weight value. Based on the calculated new access weight value, update the weight attribute of the corresponding edge in the system authentication relationship graph in real time. The update process should ensure data consistency and integrity, and a transaction processing mechanism can be used to ensure that no data errors or loss occur during the update process.

[0050] In this embodiment, upon detecting a cross-system access request, a temporary token carrying fine-grained permission tags and expiration times can be generated based on a differentiated asymmetric encryption key, ensuring the secure transmission and precise control of permission information. Simultaneously, request characteristics are injected into the system authentication relationship graph, and the corresponding edge weights are updated in real time. This allows the system to better reflect the dynamic changes in authentication relationships between systems, providing accurate data support for subsequent authentication traffic prediction and resource allocation, thereby improving the security, flexibility, and efficiency of cross-system authentication within the enterprise.

[0051] S104, based on temporary tokens, extracts the historical behavior sequence of associated edges through an anomaly detection model. When an abnormal pattern is detected, it triggers permission revocation and freezes the temporary token.

[0052] In this embodiment, the temporary token is first preliminarily verified, including whether the token's format conforms to the specifications and whether the token is within its validity period. If the token's format is incorrect or it has expired, the access request is directly rejected, and the corresponding error information is recorded. For temporary tokens that pass the preliminary verification, the target system parses key information from the token, such as the user identifier, source system identifier, target system identifier, and fine-grained permission tags.

[0053] In enterprise systems, a dedicated data storage area is typically set up to record access behavior information between systems. This information includes access time, user ID, source system ID, target system ID, accessed resource type, and access result. Based on the parsed source and target system IDs, the corresponding edges are queried in the system authentication relationship graph constructed using a graph database. Based on the identifier of the associated edge, the data storage location for storing the historical behavior sequence of that edge is determined. Each element in the historical behavior sequence represents an access behavior, containing the aforementioned information such as access time, user ID, source system ID, target system ID, accessed resource type, and access result.

[0054] An anomaly detection model is pre-deployed within the enterprise system. This model can be trained using machine learning algorithms such as rule-based detection, cluster analysis, and anomaly scoring models. When anomaly detection is required, the anomaly detection model is loaded and initialized. The initialization process includes setting the model's parameters and loading the pre-trained model weights.

[0055] Features for anomaly detection are extracted from historical behavior sequences. Common features include access frequency (number of accesses per unit time), access time distribution (e.g., peak and off-peak periods), distribution of accessed resource types, and success rate of access results. For example, statistics can be compiled on the number of accesses to a related edge at different time periods within a set time range, and the diversity of accessed resource types can be analyzed.

[0056] The extracted features are input into the anomaly detection model, which analyzes and judges historical behavior sequences according to preset rules or algorithms. If the model detects a pattern in the historical behavior sequence that is significantly different from the normal behavior pattern, it is judged as an anomaly pattern. For example, if the access frequency of related edges suddenly increases significantly within a certain period of time, and the type of resources accessed is different from the past, or the success rate of access results decreases abnormally, these may all be judged as an anomaly pattern.

[0057] When the anomaly detection model detects an abnormal pattern, the system immediately triggers the privilege revoke mechanism. Simultaneously with privilege revoke, the system freezes the temporary token.

[0058] In this embodiment, based on temporary tokens, an anomaly detection model is used to extract historical behavior sequences of associated edges. When an abnormal pattern is detected, permission revocation and temporary token freezing are triggered promptly, effectively improving the security of cross-system authentication within the enterprise. This solution can promptly detect and respond to potential security threats, prevent the abuse of temporary tokens, and ensure the normal operation of enterprise systems and data security.

[0059] S105, for temporary tokens that are not frozen, create a time-limited default role for unregistered users through the target system, and insert the new user node into the system authentication relationship graph and generate an association edge with the source system.

[0060] In this embodiment, for temporary tokens that are not frozen, key information such as the user identifier and source system identifier are extracted. The user identifier uniquely identifies the user initiating the access request, while the source system identifier indicates which system the user initiated the cross-system access from. Based on the parsed user identifier, the target system queries its own user management database to check if the user is already registered in the target system. The user management database stores relevant information for all registered users of the target system, such as username, password, role, and permissions. If the query result indicates that the user does not exist in the user management database, the user is determined to be an unregistered user.

[0061] In an enterprise system, a set of default roles is predefined. These default roles have specific sets of permissions to meet the basic business needs of new users when they first access the target system. To ensure system security and efficient resource utilization, a validity period is set for each default role. The length of the validity period can be adjusted according to the enterprise's business needs and security policies. Based on the predefined default roles and the set validity period, the target system creates a time-limited default role instance for unregistered users. This role instance is associated with a user identifier, and relevant information, including role name, effective date, and expiration date, is recorded in the user management database. In this way, the user obtains the corresponding permissions granted by the default role within the validity period.

[0062] Create a new node in the system authentication relationship graph to represent the unregistered user. The new user node needs to contain some basic security attributes, such as user identifier, user origin (i.e., source system identifier), and creation time. This information is helpful for subsequent analysis and management of user behavior.

[0063] Set corresponding attribute values ​​for new user nodes. For example, store the user identifier as a key attribute of the node; the user source attribute records which source system the user initiated the cross-system access from, which is of great significance for analyzing user access paths and inter-system relationships; the creation time attribute records the creation time of the new user node in the graph, which can be used for subsequent auditing and statistics.

[0064] Based on the context information of the cross-system access request, the association between the new user node and the source system is determined. This association reflects that the user initiated the access from the source system to the target system, and is an important part of the system authentication relationship graph, helping to describe the interaction between various systems within the enterprise and the flow of users. In the system authentication relationship graph, a directed edge is created from the newly created user node to the corresponding node in the source system, representing the association between the user and the source system. This edge is used to record the user's access path information from the source system to the target system.

[0065] Initialize some attribute values ​​for the newly generated associated edges. For example, you can set the edge type to "user cross-system access association" to distinguish different types of edges; you can also record the creation time of the associated edge for later analysis of the time distribution of user access behavior. At the same time, since this is the first time the associated edge is created, the access weight can be initialized to a default value, and this weight can be dynamically updated according to the actual access situation.

[0066] After creating time-limited default roles for users and inserting new user nodes into the system authentication relationship graph, user access behavior is monitored in real time. Monitoring includes the types of resources accessed, access frequency, and operational behaviors. Monitoring can promptly detect abnormal user behavior, such as frequent access to sensitive resources or unauthorized operations, allowing for appropriate action to be taken.

[0067] Within the validity period of the default role, the user's role permissions are dynamically adjusted based on the user's actual business needs and access behavior. For example, if a user demonstrates legitimate and frequent access needs to certain specific resources during the access process, it is possible to consider expanding the user's corresponding permissions and upgrading their default role to one with more privileges.

[0068] When the default role expires, the target system automatically revokes the user's access permissions. The user's role information is updated in the user management database, setting the role to invalid or restoring it to its initial no-access state. Simultaneously, in the system authentication relationship graph, the enterprise can decide whether to retain the new user node and associated edges, or to mark and process them accordingly, based on its needs.

[0069] In this embodiment, for unregistered users corresponding to unfrozen temporary tokens, the target system can create a time-limited default role for them, allowing the user to access the necessary resources of the target system within the valid time limit, thus meeting basic business needs. Simultaneously, inserting new user nodes into the system authentication relationship graph and generating association edges with the source system helps to comprehensively record the interactions and user flow between various systems within the enterprise, providing strong support for subsequent security analysis, auditing, and system optimization. Furthermore, by monitoring user behavior and dynamically adjusting role permissions, the system's security and flexibility can be further improved, adapting to the complex and ever-changing business environment of the enterprise.

[0070] S106, based on the edge weight change trend of the system authentication relationship graph, outputs the predicted load value through the authentication traffic prediction model. When the predicted load value exceeds the threshold, the authentication container instance of the Kubernetes cluster is automatically scaled up or down.

[0071] In this embodiment, within the enterprise system, the system authentication relationship graph records the authentication relationships between various systems and related access weight information. To collect edge weight change trend data, it is necessary to identify the edges that need to be monitored in the graph. These edges are typically those connecting critical business systems, those with high authentication traffic, or those exhibiting significant traffic fluctuations. A set of edges requiring focused monitoring can be predefined by analyzing historical data and business requirements.

[0072] Based on the characteristics of the enterprise's business and the required response time for authentication services, a reasonable data collection frequency should be set. For example, during peak business periods when traffic changes rapidly, the data collection frequency can be set to once per minute; during periods of relatively stable business, the collection frequency can be appropriately reduced, such as once every five minutes. By periodically collecting the weight data of these edges, the sequence of edge weight changes over time can be obtained.

[0073] The collected edge weight data is stored in a dedicated data storage system, such as a time-series database. Time-series databases can efficiently store and query timestamped data, facilitating subsequent analysis of edge weight change trends. When storing data, it is necessary to record the timestamp, edge identifiers (source system identifier and target system identifier), and edge weight value for each data entry.

[0074] Choose a suitable authentication traffic prediction model, such as a time series analysis-based model (e.g., moving average, exponential smoothing) or a machine learning-based model (e.g., recurrent neural networks and their variant LSTM). Initialize and configure the selected model based on the company's actual data and business needs. The initialization process includes setting model parameters and loading pre-trained model weights (if using a machine learning model). If a machine learning model is chosen, a certain amount of historical edge weight data needs to be collected in advance as training data to train the model, enabling it to learn the potential relationship between edge weight changes and authentication traffic.

[0075] Features for prediction are extracted from the collected edge weight change trend data. In addition to the edge weight values ​​themselves, time-related features can be considered, such as time periods within a day (peak hours, off-peak hours) and days of the week (weekdays, weekends). These time features help the model better capture the periodic changes in authentication traffic. The extracted features are then organized into a format that the model can process and input into the authentication traffic prediction model.

[0076] The authentication traffic prediction model calculates and analyzes input characteristics to output a predicted load value. The predicted load value can be represented as the expected processing volume of the authentication service within a future time period (e.g., the next 15 minutes, 30 minutes, etc.), typically measured by the number of authentication requests per unit of time. By learning from historical data and analyzing current edge weight trends, the model predicts future authentication traffic, providing a basis for enterprise decision-making.

[0077] Collect actual load data for the enterprise's authentication service over a past period, including metrics such as the number of authentication requests, system response time, and resource utilization in different time periods. Analyze this historical data to understand the operational status and performance of the authentication service under different load conditions. For example, the analysis may reveal that when the load reaches a certain value, the system response time begins to increase significantly, or the resource utilization approaches saturation.

[0078] Based on the company's business needs and performance requirements for the authentication service, determine the acceptable maximum response time and minimum performance metrics for the authentication service. For example, if the company requires the average response time for authentication requests to not exceed 2 seconds, then when setting the threshold, it is necessary to ensure that the authentication service can still meet this performance requirement when the predicted load value reaches that threshold.

[0079] Taking into account historical data analysis and business needs, a reasonable threshold for predicted load should be set. When the predicted load exceeds this threshold, it means that the authentication service may face significant pressure, requiring scaling up or down to ensure normal service operation. The threshold setting needs to be forward-looking and fault-tolerant to avoid being overly sensitive and causing frequent scaling up or down operations, while also ensuring a timely response when the load actually increases.

[0080] The predicted load value output by the authentication traffic prediction model is compared with a pre-set threshold. If the predicted load value is less than or equal to the threshold, it means that the current processing capacity of the authentication service can meet future load demands, and no scaling up or down operation is required. The monitoring and prediction of edge weight changes will continue.

[0081] If the predicted load exceeds a threshold, a scaling decision is triggered. This decision involves determining the number of authentication container instances that need to be added. The required number of instances can be estimated based on the difference between the predicted load and the threshold, as well as the processing capacity of each authentication container instance. For example, if the predicted load is 50% higher than the threshold, and each authentication container instance can handle 100 authentication requests per minute, then it can be estimated that a certain number of instances need to be added to meet the additional load demand.

[0082] Once the scaling requirement is determined, the corresponding number of authentication container instances are automatically created via the Kubernetes cluster's API or management tools. These newly created instances are then added to the authentication service's load balancer pool to begin processing authentication requests, thereby improving the authentication service's processing capacity.

[0083] To ensure efficient resource utilization and avoid unnecessary waste, scaling down should also be considered. Predicted load values ​​can be recalculated and compared to thresholds periodically (e.g., at regular intervals). If multiple consecutive predicted load values ​​fall below the threshold, and the deviation reaches a certain level (e.g., below 30%), a scaling down decision is triggered. During the scaling down decision, the number of instances to be reduced is determined based on the current number of running certified container instances and resource utilization. The corresponding number of certified container instances are then automatically terminated via the Kubernetes cluster API or management tools, releasing resources.

[0084] In this embodiment, based on the edge weight change trend of the system authentication relationship graph, an authentication traffic prediction model is used to predict the authentication load. When the predicted load value exceeds a threshold, the authentication container instances of the Kubernetes cluster are automatically scaled up or down, enabling elastic scaling of the authentication service. When authentication traffic increases, authentication container instances are added in a timely manner to ensure high availability and low latency response of the authentication service; when authentication traffic decreases, the number of instances is automatically reduced to avoid resource waste and reduce the enterprise's operating costs.

[0085] In some embodiments, step S101 above, specifically the construction of a system authentication relationship graph through a graph database, includes: In response to a new system registration request, a corresponding node is created in the graph database and the system entity identifier, security level attribute, and public key fingerprint are stored. For any two systems within an enterprise, a two-way authentication certificate between the systems is generated based on the public key fingerprint of the corresponding node, and an authentication edge connecting the two nodes is created. The initial weight of the authentication edge is set to a preset security baseline value. In response to the first cross-system authentication event between any two systems, the first security parameter set of the cross-system authentication event is obtained in real time. The first security parameter set includes the encryption strength level of the authentication protocol, the request initiation timestamp, and the risk score of the source system. The new authentication edge weight is calculated based on the first security parameter set. When the change in the authentication edge weight exceeds a preset change threshold, a key update instruction is sent to the key distribution center. The key update instruction includes the direction and magnitude of the weight change.

[0086] In this embodiment, when an enterprise's system administrator or relevant business department needs to deploy a new system, it will initiate a new system registration request to the system authentication management platform. This request can be submitted through a specific management interface or API, and includes basic information about the new system, such as the system name and purpose.

[0087] Upon receiving a new system registration request, the system authentication management platform creates a new node in the graph database to represent the new system. This node stores a system entity identifier, which is unique and non-repeatable within the system, used to accurately identify the system in the graph. Simultaneously, it stores the system's security level attribute, which can be categorized based on factors such as the system's business importance and data sensitivity, for example, into high, medium, and low levels. Furthermore, it stores the system's public key fingerprint, a unique identifier for the system's public key, used for subsequent inter-system authentication.

[0088] Within the enterprise's registered systems, select any two systems for analysis. These two systems can be a newly registered system and an existing system, or two existing systems. The selection of system pairs can be determined based on factors such as business needs and the interrelationships between systems.

[0089] Based on the public key fingerprints of the corresponding nodes in the two selected systems, a Certificate Authority (CA) generates a two-way authentication certificate between the systems. The CA uses the public key fingerprints to verify the system's identity and generates a certificate containing system identity information, public key, validity period, and other details. This two-way authentication certificate ensures that the two systems can mutually verify each other's identity during authentication, guaranteeing authentication security.

[0090] In the graph database, an authentication edge is created for the nodes corresponding to the two systems to represent the authentication relationship between them. The initial weight of this authentication edge is set to a preset security baseline value. This preset security baseline value is an initial value set based on the enterprise's security policy and historical experience to reflect the initial security state of the authentication relationship between the systems. For example, the preset security baseline value can be set to 50, indicating that in the initial state, the authentication relationship between the two systems is at a relatively moderate security level.

[0091] Within an enterprise, the system authentication management platform detects the first cross-system authentication event between two systems. Monitoring is achieved by setting monitoring points along the communication path between the systems to capture authentication request and response information in real time. Upon detecting the first cross-system authentication event, the platform acquires the first set of security parameters for that event in real time. This first set of security parameters includes the authentication protocol encryption strength level, the request initiation timestamp, and the source system risk score. The authentication protocol encryption strength level can be categorized based on factors such as the encryption algorithm and key length used in the authentication protocol, for example, into three levels: strong, medium, and weak. The request initiation timestamp records the specific time the authentication request was initiated, used to analyze the temporal distribution characteristics of authentication events. The source system risk score is a score derived from a comprehensive evaluation of factors such as the source system's historical security records, business type, and data sensitivity, reflecting the degree of security risk of the source system.

[0092] The authentication edge weight is calculated based on the acquired first set of security parameters. During the calculation, factors such as the encryption strength level of the authentication protocol, the request initiation timestamp, and the source system risk score are comprehensively considered. For example, a strong encryption strength level may positively impact the authentication edge weight, increasing its value; conversely, a high source system risk score may negatively impact it, decreasing its value. By comprehensively considering these factors, a new authentication edge weight value is derived.

[0093] The calculated new authentication edge weight value is compared with the previous weight value of the same authentication edge to calculate the weight change. This weight change is then compared with a preset change threshold, which is a value set based on the enterprise's security policy and sensitivity to changes in authentication relationships. For example, the preset change threshold can be set to 10, indicating that when the change in authentication edge weight exceeds 10, appropriate action is required.

[0094] When the change in the authentication edge weight exceeds a preset threshold, the system authentication management platform sends a key update instruction to the key distribution center. This instruction includes the direction and magnitude of the weight change; the direction indicates whether the weight increases or decreases, and the magnitude indicates the specific value of the change. Upon receiving the key update instruction, the key distribution center updates the authentication key between the two systems based on the information in the instruction to ensure authentication security. For example, if the weight decreases significantly, it indicates a potential reduction in the security of the authentication relationship, and the key distribution center will generate a new, stronger key to replace the original one.

[0095] After completing the above steps, the construction and dynamic updating of the system authentication relationship graph are verified. Different cross-system authentication scenarios can be simulated to check whether the nodes, authentication edges, and weight information in the graph accurately reflect the system's authentication relationships and security status. Simultaneously, the inter-system authentication status after key updates is monitored to ensure the authentication process proceeds normally and its security is guaranteed.

[0096] Based on the results of the effectiveness verification, the construction and dynamic updating process of the system authentication relationship graph are continuously optimized. For example, parameters such as the preset security baseline value and the preset change threshold are adjusted to better meet the actual security needs of enterprises. Simultaneously, the acquisition method of the first security parameter set and the weight calculation method are optimized to improve the accuracy and rationality of weight calculation. Furthermore, the key update strategy of the key distribution center can be optimized to ensure the timeliness and effectiveness of key updates.

[0097] In this embodiment, a system authentication relationship graph that accurately reflects the authentication relationships and security status of internal enterprise systems can be constructed. When a new system registers, a corresponding node can be created in the graph in a timely manner, and authentication relationships between systems can be established. By acquiring the security parameter set of cross-system authentication events in real time, the authentication edge weights are dynamically updated, and the authentication keys are updated promptly when the weights change significantly, ensuring the security of inter-system authentication. Furthermore, through continuous performance verification and optimization, the accuracy and practicality of the system authentication relationship graph can be continuously improved, providing strong protection for the security of cross-system authentication within the enterprise.

[0098] In some embodiments, step S102 above, which involves generating differentiated asymmetric encryption keys for system pairs with bidirectional authentication edges within an enterprise based on the node security level of the system authentication relationship graph through a key distribution center, specifically includes: The security level attributes of the source system and the target system are extracted from the nodes of the system authentication relationship graph through the key distribution center; When both the source system and the target system have the highest security level, the first key length and the first update cycle are used. When the security level attribute of either system is lower than the preset security level threshold, a second key length and a second update cycle are adopted. Wherein, the first key length is greater than the second key length, and the first update cycle is shorter than the second update cycle; Based on a first key length and a first update cycle or a second key length and a second update cycle, a dedicated asymmetric key pair is generated for the source system and the target system. The private key of the dedicated asymmetric key pair is split and stored in both systems, and the public key of the dedicated asymmetric key pair is registered with the key distribution center.

[0099] In this embodiment, the key distribution center, as a core component of the enterprise's internal key management, interacts with the system authentication relationship graph. The graph stores detailed information about each system node, including security level attributes. The key distribution center initiates requests to the graph through specific interfaces or query mechanisms to obtain the security level attributes of the source and target systems in system pairs with bidirectional authentication edges.

[0100] After receiving a request from the key distribution center, the system authentication relationship graph extracts the security level attributes of the source and target systems from the node data of the graph based on the system pair information specified in the request. These security level attributes are typically pre-defined by the enterprise based on factors such as the system's business characteristics, data importance, and security risks. For example, they are divided into three levels: high, medium, and low, with high being the highest level.

[0101] When the key distribution center obtains that both the source and target systems have the highest security level, it determines to use the first key length and the first update cycle. The first key length is a relatively long value set based on current security technologies and requirements, such as 4096 bits. A longer key length can provide higher encryption strength and resist more complex attack methods. The first update cycle is set to a relatively short cycle, such as once a week. A shorter update cycle allows for timely key replacement, reducing the risk of key cracking and ensuring that the security of inter-system authentication remains at a high level.

[0102] When the security level of either the source system or the target system is detected to be lower than a preset security level threshold (assuming the preset security level threshold is medium), a second key length and a second update cycle are determined. The second key length is relatively short, for example, 2048 bits. Although the key length is short, it can reduce the computational resource consumption for key generation and management while meeting the security requirements of lower security level systems. The second update cycle is set to a longer cycle, such as once a month. For lower security level systems, a longer update cycle can reduce the frequency of key updates and the workload of system maintenance while ensuring a certain level of security.

[0103] The key distribution center, based on a determined first key length and first update cycle or a second key length and second update cycle, invokes its internal key generation algorithm to generate a unique asymmetric key pair for the source and target systems. The asymmetric key pair consists of a public key and a private key; the public key is used to encrypt data, and the private key is used to decrypt data. During the generation process, the key distribution center ensures that the generated keys meet the corresponding length requirements and adhere to certain principles of randomness and security.

[0104] The private key of the generated proprietary asymmetric key pair needs to be segmented for storage to ensure its security. The key distribution center divides the private key into multiple parts, for example, three parts. Then, these segmented private key parts are sent separately to the source and target systems. Upon receiving the private key parts, the source and target systems store them in their respective secure storage areas, such as Hardware Security Modules (HSMs) or encrypted databases, according to predetermined rules. This segmented storage method prevents the complete leakage of the private key after an attack on a single system, thus improving its security.

[0105] The public key of the dedicated asymmetric key pair is registered with a key distribution center. The key distribution center creates a corresponding record for each public key, including information about the system to which the public key belongs and the validity period of the public key. After the public key is registered, other systems can obtain the target system's public key through the key distribution center when performing cross-system authentication. This public key is used to encrypt authentication information and ensure the confidentiality of the authentication information during transmission.

[0106] The key distribution center continuously monitors the key update cycles of each system. For system pairs using the first update cycle, the key distribution center checks whether the keys need to be updated at a specific time each week. For system pairs using the second update cycle, the check is performed at a specific time each month.

[0107] When the update cycle arrives, the key distribution center triggers the key update process. First, the key distribution center regenerates a new dedicated asymmetric key pair following the steps described above. Then, the new private key portion is split and sent to the source and target systems, which update their respective stored private key portions. Simultaneously, the new public key is registered with the key distribution center, replacing the original public key record.

[0108] After the key update is complete, the key distribution center will notify the source and target systems that the key update is finished. Upon receiving the notification, the source and target systems will perform corresponding verification operations to ensure that the new key can be used correctly. For example, by performing a simulated cross-system authentication operation, they can verify whether the new public and private keys can correctly decrypt and encrypt authentication information.

[0109] In this embodiment, differentiated asymmetric encryption keys can be generated for systems with bidirectional authentication edges within an enterprise, based on the security level of nodes in the system authentication relationship graph. Higher security level systems employ longer key lengths and shorter update cycles to ensure high security; lower security level systems employ relatively shorter key lengths and longer update cycles, reducing resource consumption while maintaining a certain level of security. The segmented storage of private keys and centralized registration and management of public keys further enhance key security.

[0110] In some embodiments, in step S103 above, when a cross-system access request is detected, generating a temporary token carrying fine-grained permission tags and expiration times based on a differentiated asymmetric encryption key, and synchronously injecting the request features into the system authentication relationship graph to update the corresponding edge weights in real time, specifically includes: When a cross-system access request is detected, the differential asymmetric encryption keys corresponding to the source system and the target system are obtained from the key distribution center. Based on differentiated asymmetric encryption keys, user permission claims in cross-system access requests are parsed, data field-level operation permissions are extracted as fine-grained permission tags, and dynamic expiration times are generated according to the target system's security policy. Fine-grained permission tags and dynamic expiration times are encapsulated into temporary tokens using an asymmetric encryption algorithm; While generating a temporary token, a second set of security parameters is extracted from cross-system access requests. The second set of security parameters includes the permission label sensitivity level, user behavior risk score, and historical authentication failure frequency. The authentication edge weight adjustment value is calculated based on the second security parameter set, and the authentication edge weight adjustment value is injected into the system authentication relationship graph in real time to update the weight attribute of the authentication edge between the source system and the target system.

[0111] In this embodiment, an internal cross-system access request monitoring module is deployed within the enterprise. This module monitors network data traffic in real time. When a cross-system access request is detected, the monitoring module triggers a subsequent key acquisition process. Cross-system access requests typically include source system identifiers, target system identifiers, user information, and the requested data or operation. The monitoring module sends the source and target system identifiers from the detected cross-system access request to the key distribution center. The key distribution center, as the core component of the enterprise's internal key management, stores the differentiated asymmetric encryption keys corresponding to each system pair. Based on the received source and target system identifiers, the key distribution center searches its key database and retrieves the corresponding differentiated asymmetric encryption keys, including the source system's public and private keys (used for decryption and signing operations) and the target system's public key (used for encryption operations), and then returns the retrieved keys to the monitoring module.

[0112] After obtaining the differentiated asymmetric encryption key, the monitoring module uses the source system's private key to decrypt the cross-system access request (if the request is encrypted) to obtain the user permission statement carried in the request. The user permission statement typically exists in the form of structured data, describing the user's access permissions to different data or operations in the target system.

[0113] The monitoring module parses user permission declarations and extracts data field-level operation permissions as fine-grained permission tags. For example, in a financial system, fine-grained permission tags could include permissions to view a specific financial report or permissions to modify a specific financial field. These fine-grained permission tags enable more precise control over user access to target system resources.

[0114] The monitoring module generates a dynamic expiration time based on the target system's security policy. The target system's security policy can comprehensively consider various factors, such as the importance of the data, the system's security level, and users' historical behavior. For example, for cross-system access requests involving sensitive financial data, the dynamic expiration time can be set to a shorter 1 hour to reduce the time window for unauthorized data access; while for access requests to some non-sensitive data, the dynamic expiration time can be set to a longer 24 hours.

[0115] The extracted fine-grained permission tags and generated dynamic expiration times are used as the data to be encapsulated. Simultaneously, an asymmetric encryption algorithm for encapsulation is prepared, which can be based on public-key cryptography (such as RSA) or elliptic curve cryptography (such as ECC).

[0116] Using the target system's public key, fine-grained permission tags and dynamic expiration times are encapsulated into temporary tokens using an asymmetric encryption algorithm. During encapsulation, the data is encrypted to ensure that only the target system can decrypt it using its private key and obtain the permission and expiration time information. After encapsulation, the temporary tokens are organized in a specific data format (such as JSON or XML) for easy subsequent transmission and parsing.

[0117] While generating a temporary token, a second set of security parameters is extracted from the cross-system access request. This second set of security parameters includes the permission label sensitivity level, user behavior risk score, and historical authentication failure frequency. The permission label sensitivity level can be categorized based on the importance of the data or operations involved in the fine-grained permission labels, for example, into high, medium, and low levels. The user behavior risk score is a comprehensive evaluation based on the user's historical behavior data (such as login time, location, and operation frequency), reflecting the risk level of the user's current behavior. The historical authentication failure frequency refers to the number of times the user has failed authentication within a certain period (such as the past week), reflecting the reliability of the user's authentication.

[0118] The authentication edge weight adjustment value is calculated based on the extracted second set of security parameters. During the calculation, factors such as the sensitivity level of the permission label, the user behavior risk score, and the frequency of historical authentication failures are comprehensively considered. For example, a high sensitivity level of the permission label may have a significant negative impact on the authentication edge weight, reducing the weight value; similarly, a high user behavior risk score or a high frequency of historical authentication failures will also negatively affect the weight value. By comprehensively considering these factors, an authentication edge weight adjustment value is derived. This adjustment value can be a positive or negative number, representing the amount by which the weight needs to be increased or decreased.

[0119] The calculated authentication edge weight adjustment values ​​are injected into the system authentication relationship graph in real time. The system authentication relationship graph stores the authentication edges between each system pair and their corresponding weight attributes. After receiving the weight adjustment value, the graph updates the weight attributes of the authentication edges between the source system and the target system according to the adjustment value.

[0120] In this embodiment, upon detecting a cross-system access request, a temporary token carrying fine-grained permission tags and expiration times can be generated based on a differentiated asymmetric encryption key, ensuring precise control of access permissions and data security. Simultaneously, by extracting a second set of security parameters and updating the corresponding edge weights in the system authentication relationship graph, real-time changes in the security of inter-system authentication relationships can be reflected, providing strong support for cross-system authentication security for enterprises.

[0121] In some embodiments, step S104 above, which involves extracting the historical behavior sequence of associated edges based on a temporary token using an anomaly detection model, and triggering permission revocation and freezing of the temporary token when an abnormal pattern is detected, specifically includes: Extract the first authentication edge associated with the temporary token from the system authentication relationship graph, and query the historical behavior sequence of the first authentication edge. The historical behavior sequence includes the access frequency, permission usage pattern distribution and historical risk score records within a set period in the past. The historical behavior sequence and the current request features are input into a pre-trained anomaly detection model. The current request features include the current request permission sensitivity, operation time deviation, and user behavior anomaly index. When the anomaly probability output by the anomaly detection model exceeds the preset anomaly probability threshold, a permission revocation command is triggered, freezing the access permissions of the current temporary token.

[0122] In this embodiment, after a cross-system access request is detected and a temporary token is generated, the first authentication edge associated with the temporary token is extracted from the system authentication relationship graph based on the source system identifier and target system identifier in the temporary token. The first authentication edge reflects the authentication interaction relationship between the source system and the target system prior to this access.

[0123] After extracting the first authentication edge, query its historical behavior sequence from its stored historical data. The historical behavior sequence records access information related to the authentication edge within a set period (e.g., the past 30 days), mainly including the following: (1) Access frequency: Statistically count the number of cross-system accesses through the authentication edge within the set period to reflect the frequency of access. For example, how many accesses per day on average, or whether there are peak access periods, etc. (2) Permission usage pattern distribution: Analyze the permissions used by users when accessing the target system through the authentication edge within the set period, including the number of times and frequency of different permissions. For example, the usage ratio of viewing permissions, modifying permissions, deleting permissions, etc. (3) Historical risk score records: Collect the score records obtained by risk assessment of access behavior for the authentication edge within the set period. The risk score can be calculated based on various factors, such as the user's historical behavior, accessed sensitive data, etc. The higher the score, the greater the risk.

[0124] During the cross-system access request processing, the characteristics of the current request are extracted in real time. The characteristics of the current request mainly include the following: (1) Sensitivity of the current request permissions: Based on the fine-grained permission tags carried in the temporary token, the sensitivity of the permissions involved in this request is evaluated. For example, the sensitivity of permissions involving modification of core financial data is high, while the sensitivity of permissions that only view public information is low. (2) Operation time deviation: The operation time of this request is compared with the normal working time range of the target system to calculate the degree of deviation of the operation time. If the request is made during non-working hours (such as early morning) and there is no reasonable business reason, the operation time deviation may be high. (3) User behavior anomaly index: Taking into account the user's historical behavior data, such as login location, device information, operation habits, etc., and comparing it with the behavior of this request, the user behavior anomaly index is calculated. For example, if the user usually logs in using a fixed device, but this request uses an unfamiliar device, the user behavior anomaly index may be high.

[0125] The historical behavior sequences obtained from the query and the extracted features of the current request are used as input data and fed into a pre-trained anomaly detection model. This pre-trained model is trained on a large amount of normal and abnormal cross-system access behavior data and is capable of learning the pattern features of normal and abnormal behavior. The model analyzes and processes the input data and outputs an anomaly probability value, which represents the probability that the current cross-system access request is an abnormal behavior.

[0126] A preset anomaly probability threshold is set, determined based on the enterprise's security needs and risk tolerance. When the anomaly probability output by the anomaly detection model exceeds the preset threshold, the cross-system access request is deemed to have an abnormal pattern. Once an abnormal pattern is determined, the system immediately triggers a permission revoke command. The permission revoke command is sent to the target system's access control module, which, upon receiving the command, freezes the access permissions of the current temporary token. Freezing the temporary token means that the user can no longer use the token to access the target system, thereby promptly preventing potential threats to enterprise data from abnormal behavior.

[0127] In this embodiment, based on temporary tokens, an anomaly detection model can be used to analyze the historical behavior sequences of associated edges. When an abnormal pattern is detected, permission revocation and freezing of the temporary token are triggered in a timely manner. This method can effectively prevent abnormal cross-system access behavior from damaging enterprise data and improve the security of enterprise systems.

[0128] In some embodiments, step S105 above, specifically the step of creating a time-limited default role for unregistered users through the target system for unfrozen temporary tokens, and simultaneously inserting the new user node into the system authentication relationship graph and generating an association edge with the source system, includes: For temporary tokens that are not frozen, after verifying the validity of the token through the target system, check whether the current user has registered; When it is detected that the current user is not registered, the temporary token is parsed to obtain the user's basic attribute set, which includes the user's unique identifier, the identifier of the source system to which the user belongs, and the permission expiration timestamp. Based on the user's basic attribute set, create a default role with a time limit, set the role permissions to the lowest set of permissions in the preset security policy, and bind the role's validity period to the permission expiration timestamp; While creating the default role, a user node is created in the system authentication relationship graph and its source system attributes are labeled. An authentication association edge is established between the user node and the source system node.

[0129] In this embodiment, for temporary tokens that are not frozen, the target system further checks whether the current user has already registered in the target system. The target system maintains a user registration information database, which stores detailed information about all registered users. The system compares the user's unique identifier (if any) carried in the temporary token with the user identifier in the user registration information database. If no matching user identifier is found in the database, the current user is determined to be an unregistered user.

[0130] When the target system detects that the current user is not registered, it parses the temporary token to obtain the user's basic attribute set. The temporary token is encapsulated with specific user attribute information during its generation. The target system uses parsing rules agreed upon with the source system to extract the user's basic attribute set from the temporary token.

[0131] The user's basic attribute set mainly includes the following information: (1) User unique identifier: used to uniquely identify the user, which can be a specific string or numeric code assigned by the source system to ensure that the user can be accurately identified in different systems. (2) Source system identifier: indicates which source system the user comes from, which helps to trace and analyze cross-system access behavior in the future. (3) Permission expiration timestamp: records the expiration time of the permission granted by the temporary token, which is used to control the timeliness of user access permissions.

[0132] Based on the parsed user base attribute set, the target system creates time-limited default roles for unregistered users. A default role is a predefined role template used to quickly assign a set of initial permissions to a user. The target system creates this default role in its role management module and assigns it a unique role identifier.

[0133] Set the permissions for this default role to the minimum set of permissions specified in the default security policy. The default security policy is formulated by the enterprise based on its own business needs and security requirements. The minimum permission set only includes the permissions necessary for users to perform basic operations, thus limiting the access scope of unregistered users and reducing security risks. For example, in a document management system, the minimum permission set might only allow users to view public documents, but not to perform operations such as modification or deletion.

[0134] The validity period of the default role is bound to the permission expiration timestamp. This means that the default role is only valid within the validity period of the temporary token. When the permission expiration time arrives, the role will automatically expire, and the user will lose the corresponding access rights. The target system will record the role's creation time, validity start time, and end time (i.e., permission expiration timestamp) in the role management module for subsequent permission management and control.

[0135] When creating a default role, the target system also creates a new user node in the system authentication relationship graph. The system authentication relationship graph is a graphical data structure used to describe the relationships between various entities (such as users, systems, roles, etc.) within the system. The newly created user node is labeled with a source system attribute, recording the identifier of the source system to which the user belongs, so that the user's origin can be clearly identified in the graph.

[0136] The target system establishes an authentication association edge between the user node and the source system node. This authentication association edge represents the authentication relationship between the user and the source system, allowing the tracking of the user's cross-system access path and authentication information. When establishing the association edge, the system records relevant information in the graph, such as the edge's creation time and association type (authentication association). In this way, the system's authentication relationship graph comprehensively records information related to unregistered users accessing the target system from the source system, providing strong support for subsequent security auditing and access control.

[0137] When a user accesses the target system using a time-limited default role, the target system monitors the user's access behavior in real time. Monitoring includes the user's operation type, accessed resources, and access time. Through monitoring, any abnormal access behavior can be detected promptly, such as frequent access to sensitive data or operations exceeding the user's authorized scope.

[0138] When the expiration time of permissions approaches, the target system will provide advance warnings or take appropriate measures. For example, the system can send a notification to the user, informing them that their permissions are about to expire; if the user needs to continue accessing the target system, they can be guided to register, and roles and permissions can be reassigned based on the user's registration information and business needs. Simultaneously, the system will periodically clean up and optimize roles and permissions, deleting expired roles and permissions to ensure system security and efficiency.

[0139] In this embodiment, for unregistered users holding unfrozen temporary tokens, the target system can create a time-limited default role and insert its relevant information into the system authentication relationship graph. This method ensures that unregistered users can perform basic access operations within the validity period, while limiting the user's access scope through the minimum permission set and time limit settings, thus reducing security risks. Simultaneously, the update of the system authentication relationship graph provides a complete information record for subsequent security management and auditing, helping enterprises better manage and control cross-system access behavior.

[0140] In some embodiments, step S106 above, which involves outputting a predicted load value based on the edge weight change trend of the system authentication relationship graph through an authentication traffic prediction model, and automatically scaling up or down the authentication container instances of the Kubernetes cluster when the predicted load value exceeds a threshold, specifically includes: The weight change sequence of all authentication edges in the authentication relationship graph of the system is collected in real time and aggregated according to a preset time window to form a weight trend dataset; Input the weighted trend dataset into the pre-trained certified traffic prediction model and output the predicted load value for future periods; Compare the relative relationship between the predicted load value and the preset capacity threshold. When the predicted load value exceeds the expansion threshold, an expansion command is generated. When the predicted load value is lower than the reduction threshold, a reduction command is generated. Based on scaling up or scaling down commands, the number of instances of the authentication service container can be dynamically adjusted through the Kubernetes control plane.

[0141] In this embodiment, a data acquisition module is deployed within the enterprise, which interacts with the system authentication relationship graph in real time. The data acquisition module continuously monitors the weight changes of all authentication edges in the system authentication relationship graph. Whenever the weight of an authentication edge is updated (e.g., due to a new cross-system access request causing an edge weight adjustment), the data acquisition module records the edge's identifier, weight value, and recording time, forming a weight change sequence. For example, for authentication edge AB (representing the authentication edge between system A and system B), if its weight is w1 at time t1 and updated to w2 at time t2, the data acquisition module will record data points such as (AB, w1, t1) and (AB, w2, t2).

[0142] The collected weight change sequences are aggregated according to preset time windows (e.g., every 5 minutes). Within each time window, the average, maximum, and minimum values ​​of the authentication edge weights are calculated, or the weight values ​​within the window are processed as a sequence. This aggregated data is then organized into a weight trend dataset. For example, for each time window, a data record containing statistical information on the weights of all authentication edges within that window is generated; data records from multiple time windows together constitute the weight trend dataset.

[0143] The constructed weight trend dataset is used as input data and fed into the pre-trained authentication traffic prediction model. The pre-trained model is trained based on historical authentication traffic data and corresponding weight trend data, and it learns the correlation between weight change trends and authentication traffic. When inputting data, preprocessing may be necessary, such as normalization, mapping the weight values ​​to a specific numerical range to allow the model to better handle the data.

[0144] The authentication traffic prediction model analyzes and processes the input weight trend dataset, outputting a predicted load value for future periods. The predicted load value reflects the potential load on the authentication service within a future timeframe (e.g., the next hour). The model predicts the future load level based on the correlation between historical weight change trends and authentication traffic, combined with current weight trend data. For example, if the current weight trend indicates increasingly frequent authentication interactions, the model might predict an increase in authentication traffic in the future, thus outputting a higher predicted load value.

[0145] Pre-set expansion and contraction thresholds. These thresholds are determined based on performance metrics of the authentication service (such as response time and throughput) and the enterprise's resource budget. For example, when the predicted load exceeds the expansion threshold, it means that the current authentication container instances in the Kubernetes cluster may not be able to meet future load demands, requiring expansion; when the predicted load is below the contraction threshold, it indicates that the current number of authentication container instances is too large, resulting in resource waste, and requiring contraction.

[0146] The predicted load value is compared with preset expansion and reduction thresholds. When the predicted load value exceeds the expansion threshold, an expansion command is generated; when the predicted load value is lower than the reduction threshold, a reduction command is generated.

[0147] The Kubernetes cluster management module is deployed within the enterprise. This module communicates with the authentication traffic prediction module and receives generated scaling-up or scaling-down commands. The Kubernetes cluster management module parses the received commands to determine the type of operation (scaling up or scaling down) and related parameters (such as the number of container instances to be added or removed).

[0148] Based on the parsed instructions, the Kubernetes cluster management module dynamically adjusts the number of authentication service container instances through the Kubernetes control plane. If it's a scaling-up instruction, the Kubernetes control plane creates new authentication service container instances in the cluster and adds them to the authentication service's load balancer to increase the authentication service's processing capacity. If it's a scaling-down instruction, the Kubernetes control plane removes the corresponding authentication service container instances from the load balancer and stops these instances from running to release resources. For example, when receiving a scaling-up instruction to add two authentication service container instances, the Kubernetes control plane starts two new container instances on appropriate nodes and updates the service configuration so that the new instances can receive and process authentication requests.

[0149] After completing the scaling up / down operation, the performance and resource utilization of the authentication service are evaluated. Evaluation metrics include authentication request response time, throughput, and cluster resource utilization. By comparing the evaluation metrics before and after scaling up / down, it can be determined whether the operation achieved the expected results. For example, if the authentication request response time is significantly shortened, throughput increases, and cluster resource utilization remains within a reasonable range after scaling up, the scaling up operation is considered effective.

[0150] Based on the performance evaluation results, the authentication traffic prediction model, expansion threshold, and contraction threshold are continuously optimized. If the model's prediction accuracy is found to be low, more historical data can be collected for retraining, or the model's parameters and structure can be adjusted. If the expansion or contraction threshold is found to be unreasonable, it can be adjusted according to actual business needs and resource availability. Through continuous optimization, the accuracy of authentication traffic prediction and the rationality of expansion and contraction decisions are improved, ensuring the stable operation of the authentication service and the efficient utilization of resources.

[0151] In this embodiment, based on the edge weight change trend of the system authentication relationship graph, an authentication traffic prediction model can accurately predict the authentication load value for future periods and automatically scale up or down the authentication container instances of the Kubernetes cluster. This method can effectively cope with dynamic changes in authentication traffic, promptly increasing the number of authentication service container instances under high load to ensure the stability and high performance of the authentication service; and reducing the number of container instances under low load to avoid resource waste and improve the resource utilization efficiency and cost-effectiveness of enterprises. Furthermore, through effect evaluation and continuous optimization, the adaptability and reliability of the system can be continuously improved.

[0152] Reference Figure 2 An embodiment of the present invention provides an enterprise internal cross-system authentication processing system 2, wherein system 2 specifically includes: Graph construction module 201 is used to construct a system authentication relationship graph through a graph database. The nodes of the system authentication relationship graph are used to represent system entities and security attributes, and the edges of the system authentication relationship graph are used to represent authentication relationships between systems and dynamically update access weights. The key generation module 202 is used to generate differentiated asymmetric encryption keys for system pairs with two-way authentication edges within the enterprise based on the node security level of the system authentication relationship graph through the key distribution center. The token generation module 203 is used to generate a temporary token carrying fine-grained permission tags and expiration time based on the differentiated asymmetric encryption key when a cross-system access request is detected, and simultaneously inject the request features into the system authentication relationship graph to update the corresponding edge weights in real time. The anomaly detection module 204 is used to extract the historical behavior sequence of associated edges based on the temporary token and the anomaly detection model. When an abnormal pattern is detected, it triggers permission revocation and freezes the temporary token. User registration module 205 is used to create a time-limited default role for unregistered users through the target system for temporary tokens that have not been frozen, and to insert the new user node into the system authentication relationship graph and generate an association edge with the source system. The container scaling module 206 is used to output predicted load values ​​through the authentication traffic prediction model based on the edge weight change trend of the system authentication relationship graph. When the predicted load value exceeds the threshold, the certified container instances of the Kubernetes cluster are automatically scaled up or down.

[0153] It is understandable that, such as Figure 1 The content of the enterprise internal cross-system authentication processing method embodiments shown are all applicable to the enterprise internal cross-system authentication processing system embodiments. The specific functions implemented by the enterprise internal cross-system authentication processing system embodiments are as follows: Figure 1 The processing method for cross-system authentication within an enterprise, as shown in the embodiment, is the same, and the beneficial effects achieved are the same as those described above. Figure 1 The beneficial effects achieved by the illustrated embodiment of the enterprise internal cross-system authentication processing method are also the same.

[0154] It should be noted that the information interaction and execution process between the above systems are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0155] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0156] Reference Figure 3 The present invention also provides a computer device 3, including: a memory 302 and a processor 301, and a computer program 303 stored on the memory 302. When the computer program 303 is executed on the processor 301, it implements the enterprise internal cross-system authentication processing method as described in any of the above methods.

[0157] The computer device 3 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 3 may include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art will understand that... Figure 3 The computer device 3 is merely an example and does not constitute a limitation on the computer device 3. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0158] The processor 301 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0159] In some embodiments, the memory 302 may be an internal storage unit of the computer device 3, such as a hard disk or memory of the computer device 3. In other embodiments, the memory 302 may be an external storage device of the computer device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 3. Furthermore, the memory 302 may include both internal and external storage units of the computer device 3. The memory 302 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0160] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the enterprise internal cross-system authentication processing method as described in any of the above methods.

[0161] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0162] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0163] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0164] In the embodiments disclosed in this application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0165] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

Claims

1. A method for processing cross-system authentication within an enterprise, characterized in that, The method specifically includes: A system authentication relationship graph is constructed using a graph database. The nodes of the system authentication relationship graph are used to represent system entities and security attributes, and the edges of the system authentication relationship graph are used to represent authentication relationships between systems and dynamically update access weights. Based on the node security level of the system authentication relationship graph, differentiated asymmetric encryption keys are generated for system pairs with two-way authentication edges within the enterprise through the key distribution center; When a cross-system access request is detected, a temporary token carrying fine-grained permission tags and expiration times is generated based on the differentiated asymmetric encryption key. The request characteristics are then injected into the system authentication relationship graph to update the corresponding edge weights in real time. Based on temporary tokens, the historical behavior sequence of associated edges is extracted through an anomaly detection model. When an abnormal pattern is detected, permission is revoked and the temporary token is frozen. For temporary tokens that are not frozen, a time-limited default role is created for unregistered users through the target system, and the new user node is inserted into the system authentication relationship graph and an association edge with the source system is generated. Based on the edge weight change trend of the system authentication relationship graph, the authentication traffic prediction model outputs the predicted load value. When the predicted load value exceeds the threshold, the authentication container instance of the Kubernetes cluster is automatically scaled up or down.

2. The method according to claim 1, characterized in that, The construction of the system authentication relationship graph through a graph database specifically includes: In response to a new system registration request, a corresponding node is created in the graph database and the system entity identifier, security level attribute, and public key fingerprint are stored. For any two systems within an enterprise, a two-way authentication certificate between the systems is generated based on the public key fingerprint of the corresponding node, and an authentication edge connecting the two nodes is created. The initial weight of the authentication edge is set to a preset security baseline value. In response to the first cross-system authentication event between any two systems, the first security parameter set of the cross-system authentication event is obtained in real time. The first security parameter set includes the encryption strength level of the authentication protocol, the request initiation timestamp, and the risk score of the source system. The new authentication edge weight is calculated based on the first security parameter set. When the change in the authentication edge weight exceeds a preset change threshold, a key update instruction is sent to the key distribution center. The key update instruction includes the direction and magnitude of the weight change.

3. The method according to claim 1, characterized in that, The node security level based on the system authentication relationship graph generates differentiated asymmetric encryption keys for system pairs with bidirectional authentication edges within the enterprise through a key distribution center, specifically including: The security level attributes of the source system and the target system are extracted from the nodes of the system authentication relationship graph through the key distribution center; When both the source system and the target system have the highest security level, the first key length and the first update cycle are used. When the security level attribute of either system is lower than the preset security level threshold, a second key length and a second update cycle are adopted. Wherein, the first key length is greater than the second key length, and the first update cycle is shorter than the second update cycle; Based on a first key length and a first update cycle or a second key length and a second update cycle, a dedicated asymmetric key pair is generated for the source system and the target system. The private key of the dedicated asymmetric key pair is split and stored in both systems, and the public key of the dedicated asymmetric key pair is registered with the key distribution center.

4. The method according to claim 1, characterized in that, When a cross-system access request is detected, a temporary token carrying fine-grained permission tags and expiration times is generated based on the differentiated asymmetric encryption key. Simultaneously, the request characteristics are injected into the system authentication relationship graph to update the corresponding edge weights in real time. Specifically, this includes: When a cross-system access request is detected, the differential asymmetric encryption keys corresponding to the source system and the target system are obtained from the key distribution center. Based on differentiated asymmetric encryption keys, user permission claims in cross-system access requests are parsed, data field-level operation permissions are extracted as fine-grained permission tags, and dynamic expiration times are generated according to the target system's security policy. Fine-grained permission tags and dynamic expiration times are encapsulated into temporary tokens using an asymmetric encryption algorithm; While generating a temporary token, a second set of security parameters is extracted from cross-system access requests. The second set of security parameters includes the permission label sensitivity level, user behavior risk score, and historical authentication failure frequency. The authentication edge weight adjustment value is calculated based on the second security parameter set, and the authentication edge weight adjustment value is injected into the system authentication relationship graph in real time to update the weight attribute of the authentication edge between the source system and the target system.

5. The method according to claim 1, characterized in that, The process, based on temporary tokens, extracts historical behavior sequences of associated edges using an anomaly detection model. When an abnormal pattern is detected, permission revocation and freezing of the temporary token are triggered. Specifically, this includes: Extract the first authentication edge associated with the temporary token from the system authentication relationship graph, and query the historical behavior sequence of the first authentication edge. The historical behavior sequence includes the access frequency, permission usage pattern distribution and historical risk score records within a set period in the past. The historical behavior sequence and the current request features are input into a pre-trained anomaly detection model. The current request features include the current request permission sensitivity, operation time deviation, and user behavior anomaly index. When the anomaly probability output by the anomaly detection model exceeds the preset anomaly probability threshold, a permission revocation command is triggered, freezing the access permissions of the current temporary token.

6. The method according to claim 1, characterized in that, For temporary tokens that are not frozen, the target system creates a time-limited default role for unregistered users, and simultaneously inserts the new user node into the system authentication relationship graph and generates an association edge with the source system. Specifically, this includes: For temporary tokens that are not frozen, after verifying the validity of the token through the target system, check whether the current user has registered; When it is detected that the current user is not registered, the temporary token is parsed to obtain the user's basic attribute set, which includes the user's unique identifier, the identifier of the source system to which the user belongs, and the permission expiration timestamp. Based on the user's basic attribute set, create a default role with a time limit, set the role permissions to the lowest set of permissions in the preset security policy, and bind the role's validity period to the permission expiration timestamp; While creating the default role, a user node is created in the system authentication relationship graph and its source system attributes are labeled. An authentication association edge is established between the user node and the source system node.

7. The method according to any one of claims 1 to 6, characterized in that, The edge weight change trend based on the system authentication relationship graph is used to output a predicted load value through the authentication traffic prediction model. When the predicted load value exceeds a threshold, the authentication container instances of the Kubernetes cluster are automatically scaled up or down. Specifically, this includes: The weight change sequence of all authentication edges in the authentication relationship graph of the system is collected in real time and aggregated according to a preset time window to form a weight trend dataset; Input the weighted trend dataset into the pre-trained certified traffic prediction model and output the predicted load value for future periods; Compare the relative relationship between the predicted load value and the preset capacity threshold. When the predicted load value exceeds the expansion threshold, an expansion command is generated. When the predicted load value is lower than the reduction threshold, a reduction command is generated. Based on scaling up or scaling down commands, the number of instances of the authentication service container can be dynamically adjusted through the Kubernetes control plane.

8. A cross-system authentication processing system within an enterprise, characterized in that, The system specifically includes: The graph construction module is used to construct a system authentication relationship graph through a graph database. The nodes of the system authentication relationship graph are used to represent system entities and security attributes, and the edges of the system authentication relationship graph are used to represent authentication relationships between systems and dynamically update access weights. The key generation module is used to generate differentiated asymmetric encryption keys for system pairs with two-way authentication edges within an enterprise, based on the node security level of the system authentication relationship graph and through the key distribution center. The token generation module is used to generate a temporary token carrying fine-grained permission tags and expiration time based on the differentiated asymmetric encryption key when a cross-system access request is detected. The request characteristics are injected into the system authentication relationship graph in real time to update the corresponding edge weights. The anomaly detection module is used to extract the historical behavior sequence of associated edges based on temporary tokens through an anomaly detection model. When an abnormal pattern is detected, it triggers permission revocation and freezes the temporary token. The user registration module is used to create time-limited default roles for unregistered users through the target system for temporary tokens that have not been frozen, and to insert the new user node into the system authentication relationship graph and generate an association edge with the source system. The container scaling module is used to automatically scale the certified container instances of the Kubernetes cluster based on the edge weight change trend of the system authentication relationship graph and the output of the predicted load value through the authentication traffic prediction model. When the predicted load value exceeds the threshold, the module automatically scales the certified container instances of the Kubernetes cluster.

9. A computer device, characterized in that, include: A memory and a processor, and a computer program stored in the memory, which, when executed on the processor, implements the processing method for cross-system authentication within an enterprise as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by a processor, implements the processing method for cross-system authentication within an enterprise as described in any one of claims 1 to 7.

Images