Single sign-on system and method integrating dynamic permission control and full-link security audit

Abstract

This application relates to a single sign-on system and method integrating dynamic access control and end-to-end security auditing. The system includes a unified identity authentication module, a permission storage module, a dynamic permission engine module, a business system proxy module, and an end-to-end security auditing module. The unified identity authentication module authenticates login requests and issues access tokens. The dynamic permission engine module performs fine-grained judgments on permission verification requests based on three types of attributes: subject attributes, resource attributes, and environment attributes, and updates permission policy rules according to policy change notifications. The business system proxy module intercepts access requests and initiates permission verification on the business system side. The end-to-end security auditing module generates an end-to-end tracing identifier for each request, and collects structured data on authentication, authorization, and operation events based on a unified log structure, writing them to the log storage medium via an asynchronous message queue. This application has the advantages of fine-grained pre-event permission control, real-time policy implementation during events, and end-to-end auditing.

Description

Technical Field

[0001] This application relates to the field of information security, and in particular to a single sign-on system and method that integrates dynamic access control and end-to-end security auditing. Background Technology

[0002] As enterprise IT infrastructure development deepens, individual employees often need to access dozens or even hundreds of business systems in their daily work. To reduce the burden of managing multiple accounts and improve the user experience, single sign-on (SSO) technology is widely used in enterprise-level identity authentication systems. While existing mainstream SSO solutions are relatively mature in terms of unified login entry points, SSO's role extends beyond simply simplifying login; it serves as the central hub for enterprise access control. Access to all business systems ultimately relies on the authentication results and permission determination of this hub. This requires SSO systems to provide comprehensive support in three key areas: pre-emptive permission granularity, in-process policy control, and post-event behavior tracing, forming a reliable security loop.

[0003] However, existing solutions have significant gaps in this closed loop. At the pre-emptive level, mainstream solutions generally rely on role-based access control models with menus or pages as units. This model lacks the ability to distinguish between fine-grained operations at the interface, field, and button levels, leaving a considerable number of sensitive accesses in the blind spot of the permission model—it cannot be precisely allowed or denied, but can only be granted or denied in a general way. Therefore, pre-emptive defense has an inherent weakness.

[0004] The pre-emptive blind spot should ideally be compensated for by in-process policy adjustments, meaning that when it's discovered that a user's access scope needs immediate tightening, the administrator can adjust the policy and make it effective immediately. However, the current solution loads and caches permission information once a user logs in. After the policy adjustment, online users still operate under the old policy and can only obtain new permissions by logging in again. This delay window makes it difficult for in-process adjustments to take effect immediately in online sessions, thus extending the pre-emptive blind spot further in the time dimension and directly threatening currently ongoing access.

[0005] When both pre-emptive defense and in-process control cannot fully control risks, the system should at least possess complete post-event evidence collection and tracing capabilities to promptly locate and review any unauthorized or abnormal access. However, in existing solutions, login authentication logs, permission authentication logs, and business operation logs are typically recorded independently by different modules. This lacks both a consistent thread running through the same complete request and a unified log structure. Post-event auditing makes it difficult to reconstruct scattered events into a continuous behavioral trajectory of the same user, resulting in low tracing efficiency and difficulty in root cause identification.

[0006] In summary, the existing single sign-on solution's three stages—pre-event defense, in-event control, and post-event traceability—are independent and lack coordination. The insufficient granularity forces enterprises to rely on in-event adjustments and post-event audits as a backup. However, in-event adjustments and post-event audits are unable to effectively fill the gaps due to their respective technical limitations, ultimately causing a significant break in the security loop of the entire enterprise access control system. Summary of the Invention

[0007] To enable enterprise access control to form a complete security loop encompassing pre-emptive defense, in-process control, and post-event traceability, this application provides a single sign-on system and method that integrates dynamic access control and end-to-end security auditing.

[0008] Firstly, this application provides a single sign-on system that integrates dynamic access control and end-to-end security auditing, employing the following technical solution:

[0009] A single sign-on system integrating dynamic access control and end-to-end security auditing, comprising:

[0010] The unified identity authentication module is configured to receive login requests from business systems, perform authentication operations on login requests, generate a global session identifier and issue an access token after the authentication operation is successful, and push authentication event information to the end-to-end security audit module.

[0011] The permission storage module, connected to the unified identity authentication module and the dynamic permission engine module, is configured to store basic user information, permission policy rules and user attribute data, and push policy change notifications to the dynamic permission engine module through the publish-subscribe channel when permission policy rules change.

[0012] The dynamic permission engine module, connected to the permission storage module and the business system agent module, is configured to receive permission verification requests from the business system agent module. The permission verification request contains at least three types of attribute information: subject attributes, resource attributes, and environment attributes. It performs permission determination based on the subject attributes, resource attributes, environment attributes, and permission policy rules obtained from the permission storage module. Based on the permission determination result, it returns an allow instruction or deny instruction to the business system agent module and pushes permission authentication event information to the end-to-end security audit module.

[0013] The business system proxy module is configured to intercept access requests from the business system on the business system side, extract access tokens from the access requests and forward them to the unified identity authentication module for token validity verification, and after the token validity verification is passed, initiate a permission verification request to the dynamic permission engine module and push business operation event information to the end-to-end security audit module.

[0014] The end-to-end security audit module receives event information from the unified identity authentication module, the dynamic permission engine module, and the business system proxy module. It is configured to generate an end-to-end tracing identifier for each access request, perform structured collection of authentication event information, permission authentication event information, and business operation event information based on a unified log structure to obtain structured logs, and write the structured logs to the log storage medium through an asynchronous message queue.

[0015] By adopting the above technical solutions, the five functional modules form a coordinated link in the pre-event, during-event, and post-event stages: the unified identity authentication module completes identity verification and issues access tokens; the business system proxy module receives each access request on the business system side and forwards the permission verification request to the dynamic permission engine module; the dynamic permission engine module performs fine-grained judgment on each request based on three types of attributes, enabling pre-event defense to move from coarse-grained role categories to precise control at the attribute level; the permission storage module uses a publish-subscribe channel to transmit policy change notifications to the dynamic permission engine module in real time, so that during-event control is no longer limited by the delay window of session-level caching; the end-to-end security audit module uses end-to-end tracing identifiers as clues to connect the three types of event information into a complete request link, so that post-event tracing has an evidence chain that runs through the entire process, thereby repairing the mutual disconnect between the pre-event, during-event, and post-event stages.

[0016] Optionally, the permission storage module includes a relational database and a cache. The relational database is configured to persistently store basic user information, permission policy rules, and policy version history. The cache is configured to store the compiled policy decision tree and hot user permission data. After receiving a change in the permission policy rule, the permission storage module pushes the policy change notification to the dynamic permission engine module through the publish-subscribe channel, and the cache performs incremental updates based on the policy change notification.

[0017] By adopting the above technical solutions, the relational database undertakes the reliable retention of policy rules and version history, and the high-speed cache uses the compiled policy decision tree to handle the high-frequency reading pressure of each permission determination, so that the permission determination response time and the policy persistence stability are guaranteed at the same time.

[0018] Optionally, the dynamic permission engine module includes: a policy decision point, configured to receive permission verification requests from the business system agent module, and perform permission determination based on the subject attributes, resource attributes, and environment attributes in the permission verification request, as well as the permission policy rules provided by the policy information point; a policy information point, configured to obtain the latest permission policy rules and user attribute data from the permission storage module and user attribute source in real time, and provide the permission policy rules and user attribute data to the policy decision point; a policy execution point, configured to return an allow or deny instruction to the business system agent module based on the determination result of the policy decision point, and push the determination result and the matching policy rule identifier to the end-to-end security audit module; and a policy management point, configured to receive policy configuration operations, generate corresponding permission policy rules, and complete the publication of permission policy rules through the permission storage module.

[0019] By adopting the above technical solution, the dynamic permission engine module is divided into four categories of responsibilities: decision-making, information, execution, and management, which are then divided into independent functional points. This creates a closed loop with clear responsibilities for permission determination, including request processing, attribute acquisition, result execution, and policy release.

[0020] Optionally, the subject attributes include at least one or more of the following: user identity, department, and job level; the resource attributes include at least one or more of the following: interface path, data range, and operation type; and the environment attributes include at least one or more of the following: access time, client network address, and device fingerprint.

[0021] By adopting the above technical solutions, each of the three types of attributes provides a variety of typical categories for strategy combinations, enabling strategy administrators to flexibly construct refined strategy expressions that cover multiple dimensions of people, events, time, and space.

[0022] Optionally, the authentication operations supported by the unified identity authentication module include at least one or more of the following: username and password authentication, multi-factor authentication, and directory service authentication. After the authentication operation is successful, the unified identity authentication module generates a global session identifier and issues an access token, which carries the global session identifier and the user identity identifier.

[0023] By adopting the above technical solutions, the unified identity authentication module is compatible with multiple mainstream authentication mechanisms and can be flexibly combined with the enterprise's existing directory services and strong authentication facilities, reducing the cost of system access and transformation.

[0024] Optionally, the unified log structure adopted by the end-to-end security audit module includes the following fields: timestamp, end-to-end tracing identifier, event type, subject identifier, resource identifier, operation result, environment attribute, and decision basis; the end-to-end security audit module is also configured to provide an end-to-end log concatenation query interface based on the end-to-end tracing identifier and a multi-dimensional log retrieval interface based on user, time, or resource.

[0025] By adopting the above technical solutions, the unified log structure eliminates format differences between event types with structured fields, and the two types of query interfaces support end-to-end tracing and multi-dimensional log retrieval respectively, enabling efficient means for event reconstruction and accurate location during the audit phase.

[0026] Optionally, the dynamic permission engine module is also configured to generate a corresponding policy version number for the permission policy rules when generating them. The cache is configured to maintain two policy decision trees simultaneously: the current version and the version to be activated. After receiving a policy change notification, the dynamic permission engine module switches the policy decision tree of the version to be activated to the current version and retains the current version before the switch until all permission judgments based on the current version before the switch are completed. The judgment result returned by the dynamic permission engine module to the business system agent module carries the policy version number used in this permission judgment, and the policy version number is synchronously pushed to the end-to-end security audit module as an audit field.

[0027] By adopting the above technical solution, the double buffering mechanism ensures that online requests are not interrupted during policy switching. The version number is sent along with the judgment result and written into the audit field, so that the switching process is imperceptible to the business and the audit phase can accurately restore the policy version on which each request is based.

[0028] Optionally, when issuing an access token, the unified identity authentication module embeds the end-to-end tracing identifier seed, the monotonic counter bit, and the policy version number used in the most recent permission determination into the payload of the access token; when the business system proxy module intercepts an access request from the business system, it extracts the end-to-end tracing identifier seed and the monotonic counter bit from the payload of the access token carried in the access request, and derives the end-to-end tracing identifier corresponding to this access request based on the current values ​​of the end-to-end tracing identifier seed and the monotonic counter bit.

[0029] By adopting the above technical solution, the end-to-end tracking identifier is transmitted across business systems by relying on the existing transparent channel of the access token, without the need for the business system to add new request header fields; the derivation method of seed plus monotonic counter enables multiple requests of the same session to obtain mutually distinguishable and associative identifiers, which facilitates the merging of logs by session.

[0030] Optionally, the end-to-end security audit module is also configured to build a user behavior baseline for each user based on historical structured logs. The user behavior baseline includes at least the distribution of typical access time periods, the distribution of typical client network address ranges, and the distribution of typical resource access frequencies. When performing permission determination, the dynamic permission engine module compares the environment attributes and resource attributes in the current permission verification request with the user behavior baseline to obtain the behavior deviation. The dynamic permission engine module uses the behavior deviation as a fourth type of attribute, along with the subject attribute, resource attribute, and environment attribute, to participate in the evaluation of the permission policy rules. When the behavior deviation exceeds a predetermined threshold, the dynamic permission engine module will adjust the determination result from allow to require secondary authentication.

[0031] By adopting the above technical solution, the behavior deviation degree is directly entered into the policy evaluation expression as the fourth type of attribute, instead of being superimposed on the permission engine as an external alarm. This allows the identification and handling of abnormal behavior to be completed uniformly within the same policy framework, avoiding the separation of state machines for judgment and interception.

[0032] Optionally, when generating permission policy rules, the dynamic permission engine module assigns critical or non-critical level tags to each permission policy rule; the permission storage module immediately pushes the corresponding policy change notification through the publish-subscribe channel for permission policy rules with critical level tags, and merges and pushes the corresponding policy change notification in batches for permission policy rules with non-critical level tags within a preset time window; when the end-to-end security audit module detects that the behavioral deviation of the target user reaches the escalation threshold, it temporarily switches the push method of the permission policy rules with non-critical level tags for the target user to immediate push; and for users whose user behavior baseline sample size has not reached the baseline threshold, the dynamic permission engine module relaxes the predetermined threshold of behavioral deviation, and writes the evaluation result of behavioral deviation only as an audit field to the log without adjusting the judgment result.

[0033] By adopting the above technical solutions, the classification and release of critical and non-critical levels balances the real-time nature of the strategy with the stability of the broadcast; the escalation mechanism based on behavioral deviation retains the ability to respond instantly to users with sudden risks; and the cold start immunity avoids misjudgment when the baseline sample is insufficient, so that the three mechanisms together support the boundary stability of dynamic regulation.

[0034] Optionally, the cache can divide the compiled policy decision tree into three levels: hot cache, warm cache, and cold cache according to user access frequency and resource sensitivity. Policy decision trees with high access frequency and high resource sensitivity are stored in the hot cache, policy decision trees with medium frequency are stored in the warm cache, and policy decision trees with low access frequency are stored in the cold cache.

[0035] By adopting the above technical solution, the cache stores information differently according to access frequency, which enables hot-access strategies to obtain a shorter decision-making and response path, while cold-access strategies do not occupy critical cache space.

[0036] Optionally, after intercepting an access request, the business system proxy module uses the full-link tracing identifier as the aggregation key to aggregate the authentication event information, authorization event information, and business operation event information corresponding to this access request into a single aggregated event within a preset short window, and then pushes it to the message queue in batches.

[0037] By adopting the above technical solution, the three types of events are aggregated with the end-to-end tracing identifier as the key and then enqueued in batches, reducing the frequency of message queue calls and minimizing the time consumption impact of log collection on the main business process.

[0038] Optionally, after successful authentication, the unified identity authentication module predicts the set of possible access interface paths based on the identity of the logged-in user and their historical access records, and triggers the dynamic permission engine module to preload the permission policy rules related to the set of interface paths from the permission storage module into the cache.

[0039] By adopting the above technical solution, the idle window between login and the first business request is used for policy preloading, so that the permission determination when the first business request arrives does not need to trigger the overhead of cache miss.

[0040] Optionally, the business system agent module is deployed in the business system in the form of a software development kit. The software development kit of the business system agent module provides implementations in at least two programming languages, and each implementation in a programming language has the same token extraction and verification, permission verification call, and event reporting functions.

[0041] By adopting the above technical solution, the business system proxy module covers the heterogeneous technology stacks of business systems within the enterprise with a multi-language software development kit, so that the unified access capability does not depend on the specific language used by the business system.

[0042] Optionally, the permission storage module counts the change frequency of each permission policy rule within a preset observation period, and determines the lifespan of each permission policy rule in the cache based on the change frequency, so that permission policy rules with higher change frequency have a shorter lifespan in the cache, and permission policy rules with lower change frequency have a longer lifespan in the cache.

[0043] By adopting the above technical solutions, frequently changing strategies ensure near synchronization between the cache and the latest strategy with a shorter lifespan, while stable strategies reduce cache rebuilding overhead with a longer lifespan.

[0044] Secondly, the single sign-on control method provided in this application adopts the following technical solution:

[0045] A single sign-on control method includes the following steps:

[0046] S1. Receive login requests from business systems, perform authentication operations on login requests, generate a global session identifier and issue an access token after successful authentication, and record authentication event information;

[0047] S2. Intercept access requests from the business system, extract access tokens from the access requests and perform validity checks on the access tokens. After the validity checks pass, obtain the subject attributes, resource attributes and environment attributes from the access requests.

[0048] S3. Perform permission determination on the access request based on the subject attribute, resource attribute, environment attribute and the latest permission policy rules, obtain the determination result and record the authentication event information;

[0049] S4. Based on the judgment result, perform a pass or deny operation on the access request, and record the operation event information corresponding to the access request after performing the pass operation;

[0050] S5. Assign end-to-end tracing identifiers to authentication event information, authorization event information, and operation event information, and write the authentication event information, authorization event information, and operation event information with end-to-end tracing identifiers to the log storage medium through an asynchronous message queue according to the unified log structure.

[0051] By adopting the above technical solution, this method uses a series of steps, including login authentication, token verification, attribute acquisition, permission determination, grant or deny, and event logging, as its framework. In each access request, it sequentially completes four types of actions: identity verification, context collection, judgment execution, and evidence collection and traceability. Among them, identity verification and context collection correspond to pre-emptive defense, permission determination and grant or deny correspond to in-process control, and event logging and full-link tracing correspond to post-event tracing. Therefore, this method becomes the execution carrier that carries the pre-event, in-event, and post-event collaborative capabilities provided by the first aspect system.

[0052] In summary, this application includes at least one of the following beneficial technical effects:

[0053] 1. This application uses five functional modules to work together before, during, and after an event, enabling fine-grained permission determination with multi-dimensional attributes, real-time policy adjustments that do not require re-login, and end-to-end auditing capabilities, thereby repairing the mutual breaks in the enterprise access control security loop.

[0054] 2. This application uses mechanisms such as double-buffered version switching, token payload homogeneity derivation, behavior baseline attribute integration, and policy hierarchical broadcasting to make policy hot updates imperceptible to online requests, enable full-link tracing identification without business system modification, incorporate abnormal user behavior into native permission judgment identification, and avoid misjudgment in boundary scenarios.

[0055] 3. This application combines the policy version number into the audit field, the behavior deviation degree as a fourth type of attribute to participate in policy evaluation, and the policy hierarchical broadcasting with the cold start immunity mechanism, so that the traceability of permission determination, behavior perception capability and boundary stability complement each other, reducing the security gap when policy changes and abnormal behaviors occur at the same time. Attached Figure Description

[0056] Figure 1 This is a schematic diagram of the overall module structure of a single sign-on system integrating dynamic access control and end-to-end security auditing in one embodiment of the present invention.

[0057] Figure 2 This is a schematic diagram of the internal composition of the dynamic permission engine module in one embodiment of the present invention.

[0058] Figure 3 This is a flowchart of a single sign-on control method in one embodiment of the present invention. Detailed Implementation

[0059] The present application will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of the application and are not intended to limit the scope of the application.

[0060] This application discloses a single sign-on system integrating dynamic access control and end-to-end security auditing. The single sign-on system provided in this application embodiment refers to... Figure 1 This system can be applied in a unified access control environment for multiple business systems within an enterprise. In this application environment, an enterprise has deployed multiple business systems, such as an office automation system, an enterprise resource planning system, a financial management system, a customer relationship management system, and a research and development collaboration system. Employees need to frequently switch between these multiple business systems in their daily work. Access to each business system ultimately relies on the single sign-on system provided in this application embodiment to complete identity authentication, permission determination, and audit trail recording.

[0061] To ensure consistency in subsequent descriptions, a baseline scenario will be used throughout the following embodiments. The baseline scenario is as follows: Zhang San, a sales manager at a company, employee ID E1002, typically works from 9:00 AM to 6:00 PM on weekdays, his typical client network address range is 10.20.30.0 / 24, and his typical office device is device fingerprint D-001. After logging in, Zhang San accesses the sales report interface of the Enterprise Resource Planning (ERP) system. The resource path of this interface is in the form of / erp / sales-report. Numerical examples in subsequent embodiments will all be based on this baseline scenario to ensure consistency of values ​​and objects across different steps and modules.

[0062] To facilitate understanding of the technical solution of this application, several technical terms involved in the solution will be explained first.

[0063] A global session identifier is a globally unique identifier generated by the unified identity authentication module after a user successfully logs in, and it remains valid throughout the user's session across all business systems. The same user shares the same global session identifier when accessing any business system within the same login session.

[0064] An access token is an access credential issued and distributed to the business system by the unified identity authentication module. The business system carries this token with each access request. The access token can be implemented in the form of a structured payload, such as JSON Web Token. The basic payload includes at least a global session identifier and a user identity identifier. When using the derivation mechanism of this application, the payload may also carry a full-link tracing identifier seed, a monotonic counter bit, and the policy version number used in the most recent permission determination.

[0065] Subject attributes refer to a set of attributes that describe the characteristics of the subject initiating the access request. Typical fields include user identity, department, and job level. In Zhang San's baseline scenario, the subject attributes are {user identity = E1002, department = sales department, job level = sales manager}.

[0066] Resource attributes refer to a set of attributes that describe the characteristics of the accessed resource. Typical fields include interface path, data range, and operation type. In the scenario where Zhang San accesses the sales report interface, the resource attributes are {interface path= / erp / sales-report, data range=sales department, operation type=query}.

[0067] Environment attributes refer to a set of attributes that describe the contextual characteristics of the environment in which the request occurs. Typical fields include access time, client network address, and device fingerprint. In Zhang San's baseline scenario, the environment attributes are {access time = 14:30, client network address = 10.20.30.5, device fingerprint = D-001}.

[0068] A full-link tracing identifier is a unique identifier assigned to a single access request, spanning the entire chain of event information involving login authentication, authorization, and business operations. Auditors can use this identifier to aggregate all logs generated by a single request and reconstruct the complete behavioral trajectory. In this application, the full-link tracing identifier can be derived from the seed plus a monotonic counter bit in the access token payload.

[0069] The monotonic counter bit is an incrementing integer bit embedded in the access token payload, used to ensure that multiple requests within the same session obtain different but related end-to-end tracing identifiers. When the access token is issued, the initial value of the monotonic counter bit is 0; each time an end-to-end tracing identifier is derived, the business system proxy module first increments the value of the monotonic counter bit by 1, and then substitutes it into the derivation formula.

[0070] The user behavior baseline refers to the typical behavior distribution constructed by the end-to-end security audit module for each user based on historical structured logs. It includes at least the distribution of typical access times, typical client network address ranges, and typical resource access frequencies. The baseline is updated using a combination of sliding window and incremental learning to prevent a single abnormal behavior from corrupting the baseline.

[0071] Behavior deviation is a quantitative value representing the degree of deviation between the attributes of the current request and the baseline of user behavior. It is used as a fourth type of attribute in the evaluation of permissions.

[0072] The strategy decision point, strategy information point, strategy execution point, and strategy management point are four components of the dynamic permission engine module, broken down by their respective responsibilities. Specifically, the strategy decision point receives permission verification requests and executes permission determinations; the strategy information point obtains the latest permission policy rules and user attribute data in real time; the strategy execution point returns the determination results to the business system agent module and pushes the determination results and matching policy rule identifiers to the end-to-end security audit module; and the strategy management point receives policy configuration operations and publishes permission policy rules.

[0073] The policy version number is an incrementing number generated by the policy management point for each permission policy rule. It is used for double-buffered version switching and audit traceability. When a permission policy rule is modified, the newly generated rule gets a new version number, rather than overwriting the original version number.

[0074] Double-buffered version switching refers to maintaining two policy decision trees simultaneously in the cache: the current version and the version to be activated. Version switching is completed through atomic pointer replacement, avoiding the interruption of online requests during the switching process.

[0075] Critical and non-critical tags are priority markers assigned to permission policy rules by policy management points. Critical tags are used for policies that affect security policies or sensitive resources, triggering immediate broadcasts; non-critical tags are used for policies that affect displayed items or prompts, and are merged and broadcast in batches within a preset time window.

[0076] The judgment threshold, also referred to as the predetermined threshold in this manual, is a threshold used to determine whether a behavioral deviation triggers an adjustment to the judgment result. When the behavioral deviation of a user's current request exceeds the judgment threshold, given that the user's baseline sample size has reached the baseline threshold, the dynamic permission engine module will adjust the judgment result from "allow" to "requires secondary authentication." The judgment threshold can be set to 5.0. The escalation threshold can be the same value as the judgment threshold, or it can be set independently to a higher value to reflect stricter requirements for escalation of the policy push method.

[0077] The escalation threshold refers to the threshold at which the push method for the permission policy rules corresponding to the user with non-critical level tags is temporarily switched from batch push to immediate push when the deviation of the target user's behavior reaches the threshold.

[0078] The baseline threshold refers to the threshold for determining whether the baseline sample size of user behavior has reached the level of trust. If the sample size does not reach the baseline threshold, the cold start immune strategy is entered.

[0079] Reference Figure 2 This method includes steps S1-S5.

[0080] S1. Receive login requests from business systems, perform authentication operations on login requests, generate a global session identifier and issue an access token after successful authentication, and record authentication event information.

[0081] S1 is the entry point for the entire method, and its output is consumed in the subsequent S2 interception phase for token verification. Specifically, after receiving a login request, the authentication operation performed can be a combination of one or more of the following: username / password authentication, multi-factor authentication, and directory service authentication. For example, the authentication operation could be username / password authentication, where the user enters their username and password, and the system compares the result with a pre-stored password hash; it could also be multi-factor authentication combining username / password authentication with a dynamic SMS verification code; or it could be directory service authentication integrated with the enterprise's existing directory service, querying the directory service via LDAP or Active Directory protocols to verify the user's identity. In Zhang San's baseline scenario, Zhang San enters his employee ID E1002 and password at the login portal. After the system verifies the password hash and sends a dynamic SMS verification code to Zhang San's registered mobile phone number, the authentication operation succeeds after Zhang San enters the correct verification code.

[0082] After successful authentication, a global session identifier is generated. The global session identifier can be generated using one of the following methods: The first method is to directly generate a fixed-length random string using a cryptographically secure random number generator. For example, a 128-bit random string can be generated and Base64 encoded to obtain a global session identifier in the form of GS-20260429-001. The second method is based on derivation, concatenating the user's identity identifier, login timestamp, and random salt value, and then calculating the global session identifier using a hash function. This method inherently includes user identity and time information within the global session identifier for the same user, facilitating rapid matching during the audit phase. Both methods achieve the goal of issuing a globally unique session identifier and are implementation methods of S1.

[0083] Next, an access token is issued. The access token can take the form of a structured payload, carrying a global session identifier and a user identity identifier. When using the derivation mechanism of this application, the payload can also carry a full-link tracing identifier seed, a monotonic counter bit, and the policy version number used in the most recent permission determination. In Zhang San's baseline scenario, an example of the payload of the access token obtained after Zhang San logs in is {session identifier = GS-20260429-001, user identity = E1002, seed = S-AB12CD34, monotonic counter bit = 0, most recent policy version number = v3}.

[0084] After S1 completes, authentication event information is recorded. This information includes at least the logged-in user's identity, login time, login method, login result, and client network address. This event information, along with other event information, is subsequently assigned a full-link tracing identifier and written to the log storage medium in S5.

[0085] In some embodiments, after S1 is completed, the unified identity authentication module further predicts the set of possible access interface paths based on the identity identifier and historical access records of the currently logged-in user, and triggers the dynamic permission engine module to preload the permission policy rules related to the set of interface paths from the permission storage module into the hot cache of the cache, so that the permission determination when the first business request arrives does not need to trigger the cache miss overhead. This optional implementation utilizes the idle window between the completion of login authentication and the arrival of the first business request, moving the policy loading operation that was originally executed at runtime to be completed in the idle window, thus achieving the purpose of completing session preparation.

[0086] S2. Intercept access requests from the business system, extract access tokens from the access requests and perform validity checks on the access tokens. After the validity checks pass, obtain the subject attributes, resource attributes and environment attributes from the access requests.

[0087] S2 plays the role of context acquisition in the overall method. The access token output by S1 is consumed in S2, and the three types of attributes output by S2 are the input for permission determination by S3. Specifically, S2 is completed by the business system proxy module deployed on the business system side. The business system proxy module works in the form of a request interceptor, completing token verification and attribute extraction before the request reaches the target interface of the business system.

[0088] The access token validity verification includes signature verification, expiration time verification, and revocation list verification. Signature verification confirms the token has not been tampered with; expiration time verification confirms the token is still valid; and revocation list verification confirms the token has not been added to the active revocation list. The verification can be implemented using one of the following methods: The first method is local public key verification. The business system agent module obtains the public key of the unified identity authentication module during initialization. Subsequent verifications only require local signature verification based on the public key, without initiating remote calls. This is suitable for business systems that are latency-sensitive and have a high frequency of signature verification. The second method is calling the remote verification interface of the unified identity authentication module. The business system agent module submits the token via a remote procedure call each time it verifies, and the unified identity authentication module returns the verification result. This is suitable for high-security scenarios that require real-time synchronization of the revocation list. Both methods achieve the purpose of token validity verification and are implementation methods of S2.

[0089] After the validity check passes, the system retrieves the subject attributes, resource attributes, and environment attributes from the access request. The subject attributes originate from the token payload and user attribute sources. The token payload provides the user's identity, while the user attribute sources provide extended attributes such as the user's department and job level. The resource attributes originate from the request URL path resolution and resource metadata maintained by the business system. The environment attributes originate from the request context, including the server timestamp at the time the request arrived, the request's source network address, and the device fingerprint carried in the request header. In Zhang San's baseline scenario, the business system proxy module extracts the subject attribute {E1002, Sales Department, Sales Manager}, the resource attribute { / erp / sales-report, Sales Department, Query}, and the environment attribute {14:30, 10.20.30.5, D-001} from Zhang San's access request.

[0090] S3. Perform permission determination on the access request based on the subject attribute, resource attribute, environment attribute and the latest permission policy rules, obtain the determination result and record the authentication event information.

[0091] S3 is the core decision-making step in access control, and the decision result determines whether to allow or deny access in the subsequent S4. Specifically, S3 is completed by the dynamic permission engine module, which operates according to an attribute-based access control model, evaluating values ​​based on three types of attributes and permission policy rules.

[0092] Access control rules are expressed as attribute expressions. In Zhang San's baseline scenario, the access control rule applicable to the sales report interface can be expressed as: `user.role = 'Sales Manager' AND resource.pathstartsWith ' / erp / sales-report' AND env.access_time within '09:00-18:00' AND env.client_ip within '10.20.30.0 / 24' THEN ALLOW with data_scope =user.department`. This rule means that when the user's job title is "Sales Manager," the resource path is prefixed with "sales report," the access period is during working hours, and the client's network address is within a typical intranet segment, access is allowed, and the data scope is limited to the user's department.

[0093] Permission policy rules can be stored in the cache in two forms. The first form is pre-compiled into a decision tree structure. Each time a decision is made, the system traverses branches from the root node according to attribute conditions to the leaf node to obtain the result. This form is characterized by fast decision-making speed and is suitable for scenarios with a large number of policies and fixed attribute dimensions. The second form is stored as rule text. Each time a decision is made, the rule text is evaluated by an expression interpreter. This form is characterized by the fact that rule modifications do not require recompilation to take effect, making it suitable for scenarios with frequent policy changes. Both storage forms can achieve the purpose of carrying and evaluating permission policy rules and are implementation methods of S3.

[0094] In Zhang San's baseline scenario, the dynamic permission engine module evaluates the three attributes {E1002, Sales Department, Sales Manager}, { / erp / sales-report, Sales Department, Query}, and {14:30, 10.20.30.5, D-001} against the aforementioned permission policy rules. If the job level condition, path condition, time period condition, and network address condition are met, the overall judgment result is allowed, and the data range is the Sales Department.

[0095] The judgment result and the corresponding policy rule identifier are pushed to the end-to-end security audit module as core fields of the authentication event information. The authentication event information includes at least the subject identity identifier, resource identifier, judgment result, matched policy rule identifier, and policy version number used at the time of judgment.

[0096] In some embodiments, after intercepting an access request, the business system proxy module uses the end-to-end tracing identifier as the aggregation key to aggregate the authentication event information, authorization event information, and operation event information corresponding to this request into a single aggregated event within a preset short-term window, and then pushes it to the message queue in batches. For example, the preset short-term window can be set to 50 milliseconds. Within this window, the three types of events are merged and queued using the end-to-end tracing identifier as the key, which significantly reduces the frequency of message queue calls compared to the method of queuing one event at a time, reducing the time consumption impact of log collection on the main business process. This aggregation method also achieves the goal of completely recording the three types of events and is another implementation method of event collection.

[0097] S4. Based on the judgment result, perform a grant or deny operation on the access request, and record the operation event information corresponding to the access request after performing the grant operation.

[0098] S4 is the execution point for permission determination and also the point of generation for business operation event information. Specifically, when the determination result is "allow," the business system proxy module forwards the access request to the target interface of the business system. After the business system completes the business logic processing, it returns a response. The business system proxy module records the operation event information after the request forwarding is completed. The operation event information includes at least the operation type, operation object, operation result, and operation completion time.

[0099] When the determination result is rejection, the business system proxy module returns an HTTP 403 status code to the client. The response body contains the reason for rejection and the end-to-end tracing identifier of this request, enabling the client to trace the specific reason to the auditor or operations personnel after receiving the rejection response.

[0100] When the determination result indicates that secondary authentication is required, as a fallback for rejection scenarios, the business system proxy module returns an HTTP 401 status code along with guidance information for secondary authentication. The client completes the secondary authentication according to the guidance and then re-initiates the request. This fallback approach, along with the direct rejection approach, constitutes two implementation methods of S4, both capable of maintaining normal system operation in different security scenarios.

[0101] In Zhang San's baseline scenario, the S3 decision result is allowed. The business system agent module forwards the request to the / erp / sales-report interface. The enterprise resource planning system returns the sales report data from the sales department. The business system agent module records the operation event information {operation type = query, operation object = / erp / sales-report, operation result = success, operation time = 14:30:15.500}.

[0102] S5. Assign end-to-end tracing identifiers to authentication event information, authorization event information, and operation event information, and write the authentication event information, authorization event information, and operation event information with end-to-end tracing identifiers to the log storage medium through an asynchronous message queue according to the unified log structure.

[0103] S5 is the evidence collection and traceability stage for post-event auditing. By assigning the same end-to-end tracing identifier to three types of events, events generated in different modules can be reconstructed into a complete request chain using this identifier as the aggregation key during the audit phase. Specifically, the end-to-end tracing identifier can be assigned in one of the following ways: The first method is that the business system proxy module generates the identifier for this request at the request entry point and then transmits the identifier to downstream modules. The second method is based on the derivation mechanism of this application. The business system proxy module extracts the end-to-end tracing identifier seed and monotonic counter bit from the payload of the access token carried in the access request, and derives the end-to-end tracing identifier corresponding to this access request based on the current value of the seed and monotonic counter bit.

[0104] The specific calculation of the derivation method can be expressed as follows:

[0105]

[0106] In the formula, For the first time in this session The end-to-end tracing identifier corresponding to this request. For the preset hash function, This indicates a concatenation operation. Seed for the end-to-end tracing identifier in the access token payload. This is the current value of the monotonic counter bit. The value of the monotonic counter bit increments by 1 after each derivation.

[0107] In Zhang San's baseline scenario, the payload of the access token obtained after Zhang San logs in contains... =S-AB12CD34, the initial monotonic counter bit is 0. When Zhang San accesses the sales report interface for the first time after logging in, the business system agent module first increments the monotonic counter bit from 0 to 1, and then... Substituting 1 into the derived formula yields... =TID-20260429-1430-001. During the 5th request, the business system proxy module first incremented the monotonic counter from 4 to 5, then... Substituting 5 into the derived formula yields =TID-20260429-1430-005. Multiple requests within the same session yield different but correlated end-to-end tracing identifiers.

[0108] The unified log structure includes the following fields: timestamp, end-to-end tracing identifier, event type, subject identifier, resource identifier, operation result, environment attributes, and decision basis. All three types of event information are assembled into structured logs according to this structure and then written to the log storage medium via an asynchronous message queue. The asynchronous message queue can be implemented using message middleware such as Kafka or RabbitMQ, and the log storage medium can be implemented using a distributed search engine such as Elasticsearch to support efficient retrieval during the subsequent auditing phase.

[0109] Based on the above-described single sign-on control method, this application also provides a corresponding single sign-on system. This system includes five functional modules: a unified identity authentication module, a permission storage module, a dynamic permission engine module, a business system proxy module, and a full-link security audit module. These five modules form a coordinated link in the three stages of pre-event defense, in-event control, and post-event traceability.

[0110] The system's overall architecture is deployed in a modular monolithic form. Modular monolith means that the five functional modules are logically independent, each fulfilling a single responsibility; physically, they run in a shared process, communicating with each other through internal application programming interfaces (APIs) rather than through remote procedure calls (RPCs). Compared to deploying each module as a microservice, this deployment significantly reduces inter-module communication overhead, facilitating frequent small-scale data interactions between modules. Compared to traditional monolithic application deployments, module boundaries are clear, and any module can be split into an independent service if needed without affecting other modules. These two considerations together support the implementation of modular monolith as the deployment model.

[0111] The collaborative links of the five functional modules are as follows: The unified identity authentication module, acting as the system's front-end portal, receives login requests from business systems and issues access tokens, while simultaneously pushing authentication event information to the end-to-end security audit module. The business system proxy module, deployed on the business system side, intercepts access requests upon receipt, forwards the access token to the unified identity authentication module for token validity verification, and then initiates a permission verification request to the dynamic permission engine module. The dynamic permission engine module performs permission determination based on three types of attributes and permission policy rules. The policy rules and user attribute data required for determination are provided in real-time by the permission storage module. The determination result is returned to the business system proxy module for granting or denying access, and also pushed to the end-to-end security audit module in the form of authentication event information. After granting the request, the business system proxy module records operation event information and pushes it to the end-to-end security audit module. The end-to-end security audit module assigns an end-to-end tracking identifier to each access request, receives the three types of event information, assembles them into structured logs according to a unified log structure, and writes them to the log storage medium via an asynchronous message queue.

[0112] The responsibilities of the unified identity authentication module include receiving login requests, performing authentication operations, generating global session identifiers, issuing access tokens, and pushing authentication event information to the end-to-end security audit module.

[0113] The unified identity authentication module supports at least one or more of the following authentication operations: username / password authentication, multi-factor authentication, and directory service authentication. For example, username / password authentication is suitable for scenarios with a complete internal account system, where the user enters their username and password, and the system compares the results with a pre-stored password hash. Multi-factor authentication is suitable for strong authentication scenarios involving sensitive operations or high-privilege accounts, adding SMS dynamic verification codes, application-generated one-time passwords, or hardware tokens to username / password authentication. Directory service authentication is suitable for scenarios where a directory service has been deployed and the existing account system needs to be reused, interfacing with the directory service via LDAP or Active Directory protocols. These authentication methods can be flexibly combined; for example, ordinary business systems use username / password authentication, while multi-factor authentication can be added for access to financial reporting systems.

[0114] The access token payload is constructed using a two-layer structure. The basic payload layer contains at least a global session identifier and a user identity identifier; this layer represents the minimum set of information required by any business system using access tokens. The advanced payload layer, on top of the basic payload, additionally carries a full-link tracing identifier seed, a monotonic counter bit, and the policy version number used in the most recent permission determination. This layer makes the access token a dual carrier of session context and authentication context. In Zhang San's baseline scenario, an example of the access token payload issued by the unified identity authentication module after Zhang San's successful login is {session identifier = GS-20260429-001, user identity = E1002, seed = S-AB12CD34, monotonic counter bit = 0, most recent policy version number = v3}.

[0115] In some embodiments, after successful authentication, the unified identity authentication module predicts the set of interface paths that the logged-in user may access in the current session based on the user's identity and historical access records. It then triggers the dynamic permission engine module to preload the permission policy rules related to this set of interface paths from the permission storage module into the hot cache. For example, based on Zhang San's historical access logs over the past 30 days, it is predicted that Zhang San will access the three interface paths / erp / sales-report, / erp / customer-list, and / oa / leave-application with a high probability in the current session. The unified identity authentication module sends a preloading instruction to the dynamic permission engine module, which preloads the permission policy rules related to these three interfaces into the hot cache, so that the permission determination upon the arrival of the first business request does not trigger the overhead of cache misses and origin requests.

[0116] The permission storage module employs a two-tier storage structure combining a relational database and a cache. The relational database handles the persistence layer, storing basic user information, permission policy rules, and policy version history; the cache handles the performance layer, storing the compiled policy decision tree and permission data for frequently accessed users. Incremental updates for policy changes are achieved between the two layers through a publish-subscribe channel.

[0117] The incremental update process for policy changes is as follows: When the policy management point receives a policy configuration operation and generates a new permission policy rule, the new rule is first written to the policy table in the relational database. The relational database then generates a new policy version number for this rule and writes it to the policy version history table. Next, the permission storage module pushes a policy change notification to the cache of the dynamic permission engine module via a publish-subscribe channel. The notification carries the policy rule's identifier and the new policy version number. Upon receiving the notification, the dynamic permission engine module retrieves the latest version of the policy rule from the relational database, compiles it in the cache, and completes the version switch.

[0118] To ensure that the policy switching process is seamless for online requests, this application employs a double-buffered version switching mechanism. Specifically, the cache maintains two policy decision trees for each permission policy rule: the current version and the version to be activated. Upon receiving a policy change notification, the new version's policy decision tree is first compiled in the slot for the version to be activated. After compilation, the version to be activated is switched to the current version via atomic pointer substitution, and the original current version enters a state awaiting reclamation. The release of the original current version adopts a delayed release method, that is, the memory space occupied by the original current version is only reclaimed after all permission judgments based on the original current version have been completed.

[0119] For example, suppose the system is currently using version v3 of policy P-001. At some point, the administrator changes the policy to version v4 through the policy management point. The specific process of version switching is as follows: At time t0, the policy management point receives the change operation and generates v4, which is persisted to the relational database; at time t1, the permission storage module broadcasts the change notification through the publish-subscribe channel; at time t2, the cache of the dynamic permission engine module receives the notification and compiles the v4 decision tree in the version slot to be activated; at time t3, atomic pointer replacement is performed, v4 becomes the current version, and v3 enters the state to be reclaimed; at time t4, all permission judgments based on v3 are completed, and the memory space occupied by v3 is reclaimed. The total time of the entire switching process is usually less than 100 milliseconds. During this period, online request R-100 has already entered the judgment process at the moment of v3→v4 switching. This request continues to use v3 to complete the judgment, and carries the version number of v3 in the judgment result; after the switch, request R-200 uses v4 to complete the judgment, and carries the version number of v4 in the judgment result. If traceability is required during the audit phase, the version number field carried in the judgment result can be used to accurately restore the policy version on which each request is based.

[0120] The permission storage module also categorizes and publishes permission policy rules based on critical and non-critical levels. Critical levels apply to policy rules that affect security policies or access control of sensitive resources, such as policies involving financial data access, user privilege escalation, and device binding changes. Non-critical levels apply to policy rules that affect displayed items or prompts, such as policies involving menu item filtering and prompt text display control. Change notifications for permission policy rules with critical levels are pushed immediately through the publish-subscribe channel, while change notifications for permission policy rules with non-critical levels are merged and pushed in batches within a preset time window. The preset time window can be set to 5 seconds. Within this window, if multiple non-critical policies for the same type of resource change, all change notifications are merged into a single notification and broadcast at once, reducing the broadcast frequency of the publish-subscribe channel.

[0121] In some embodiments, the cache divides the compiled policy decision tree into three levels—hot cache, warm cache, and cold cache—based on user access frequency and resource sensitivity. Policy decision trees with high access frequency and high resource sensitivity are stored in the hot cache, those with medium access frequency are stored in the warm cache, and those with low access frequency are stored in the cold cache. This allows hot policies to obtain a shorter decision-response path, while infrequently accessed policies do not occupy critical cache space. This three-level caching method also achieves the goal of high-speed reading of the policy decision tree and represents another implementation of the internal organization of the cache.

[0122] In other embodiments, the permission storage module counts the change frequency of each permission policy rule within a preset observation period and determines the lifespan of each permission policy rule in the cache based on the change frequency. For example, using a 24-hour observation period, rules with a change frequency of 5 or more are classified as high-frequency change rules and have a lifespan of 5 minutes in the cache; rules with a change frequency of less than 5 are classified as stable rules and have a lifespan of 6 hours in the cache. This adaptive lifespan method ensures that frequently changing policies maintain near synchronization between the cache and the latest policy with a shorter lifespan, while stable policies reduce cache rebuilding overhead with a longer lifespan.

[0123] Reference Figure 3 The dynamic permission engine module is divided into four components according to their responsibilities: policy decision point, policy information point, policy execution point, and policy management point. The four components work together to complete the entire process from receiving the permission verification request to returning the judgment result.

[0124] The policy decision point receives permission verification requests from the business system agent module. Based on the subject attributes, resource attributes, and environment attributes in the request, as well as the permission policy rules provided by the policy information point, it performs permission determination. The policy information point obtains the latest permission policy rules and user attribute data from the permission storage module and user attribute source in real time, ensuring that each determination is based on the latest data and avoiding judgment bias caused by outdated cache. The policy execution point returns an allow or deny instruction to the business system agent module based on the determination result of the policy decision point, and pushes the determination result and the matching policy rule identifier to the end-to-end security audit module. The policy management point receives policy configuration operations, generates corresponding permission policy rules, and completes the publication through the permission storage module. The collaboration of these four components forms a closed loop with clear responsibilities for permission determination request processing, attribute acquisition, result execution, and policy publication.

[0125] Permission verification requests must include at least three types of attributes: subject attributes, resource attributes, and environment attributes. Subject attributes must include at least one or more of the following: user identity, department, and job level; resource attributes must include at least one or more of the following: interface path, data scope, and operation type; and environment attributes must include at least one or more of the following: access time, client network address, and device fingerprint. The combination of these three types of attributes allows policy administrators to flexibly construct refined policy expressions that cover multiple dimensions of people, events, time, and space.

[0126] To support the detection of scenarios such as account theft and abnormal access by internal personnel, this application introduces a fourth type of attribute, namely behavioral attributes, in addition to the three types of attributes. Behavioral deviation is obtained with a behavioral baseline as a reference, and this deviation is used as the evaluation expression for the permission policy rules. The behavioral baseline is constructed by the end-to-end security audit module based on historical structured logs, and includes at least the distribution of typical access periods, the distribution of typical client network address ranges, and the distribution of typical resource access frequencies. The updating of the behavioral baseline adopts a combination of sliding window and incremental learning. Specifically, the most recent 30 days are used as the sliding window, and the request data of the day is weighted and integrated into the baseline statistics each day. Old data is weighted according to time decay, so that the baseline can reflect both the user's long-term typical behavior and follow the user's recent behavioral changes. Furthermore, the impact of a single abnormal request on the baseline is diluted by the time decay weight, preventing the baseline from being contaminated by a single abnormal behavior.

[0127] The behavioral deviation is calculated as follows:

[0128]

[0129] In the formula, For behavioral deviation, The number of attribute dimensions participating in the comparison. For the first in this request The actual values ​​that a dimension attribute can take. For the user behavior baseline, the first The mean of the dimensional attribute, The standard deviation of this dimension. For the first The weights of the dimensional attributes are such that the sum of the weights of each dimension is 1.

[0130] In Zhang San's baseline scenario, assuming the dynamic permission engine module uses three dimensions for calculation: access time period, client network address range matching degree, and request frequency of the current access interface, with the following weights for each dimension: =0.4、 =0.4、 =0.2. Wherein, The access period for this request is expressed in hours; This indicates the matching degree of the client's network address segment; a value of 1 is taken for typical segments, and a value of 0 is taken for atypical segments. This represents the cumulative number of requests made by the user to the interface accessed in this request within the most recent hour, expressed in terms of hourly intervals. and This represents the baseline mean and standard deviation for this user's access to the interface. In a scenario where Zhang San accesses the sales report interface during typical workday hours, =14.0、 =1.0、 =2.0. In Zhang San's behavioral baseline for the sales report interface, the mean value for each dimension is 2.0. =14.0、 =1.0、 =5.0, standard deviation is =2.0、 =0.2、 =1.0. Substitute into the calculation:

[0131]

[0132] Obtained behavioral deviation =0.6, which is much smaller than the judgment threshold, indicating that this request is within the typical behavior range of Zhang San to the sales report interface.

[0133] Behavioral deviation, as a fourth type of attribute, participates in the evaluation of permission policy rules, expanding the attribute set of the policy expression from {subject, resource, environment} to {subject, resource, environment, behavior}. For example, a unified expression can be written: when user.role = 'Sales Manager' AND resource.path startsWith ' / erp / sales-report' AND env.access_time within '09:00-18:00' AND behavior.deviation < 5.0 THEN ALLOW; when user.role = 'Sales Manager' AND resource.path startsWith ' / erp / sales-report' AND behavior.deviation >= 5.0 THEN STEP_UP_AUTH. When the behavioral deviation exceeds the judgment threshold, the dynamic permission engine module adjusts the judgment result from allow to require secondary authentication. After triggering secondary authentication, the user must re-provide multi-factor authentication credentials to continue access.

[0134] To address users whose sample size does not reach the baseline threshold, such as new employees or employees returning from long-term leave, this application employs a cold start immunity mechanism. The specific handling method of the cold start immunity mechanism is as follows: for users whose baseline behavioral sample size does not reach the baseline threshold, the dynamic permission engine module relaxes the threshold for judging behavioral deviation, and the calculated behavioral deviation result is only written to the log as an audit field without adjusting the judgment result. The baseline threshold can be set to 200 structured log entries; users with a sample size below this threshold enter the cold start period. For example, on the third day of employment, new employee Li Si's baseline behavioral sample size is only 30 entries, below the baseline threshold. Even if a high behavioral deviation is calculated for this request, this deviation is only written to the log as an audit field and does not trigger an adjustment to the judgment result. When Li Si's baseline behavioral sample size reaches the baseline threshold, the user leaves the cold start period, and the behavioral deviation adjustment mechanism for the judgment result is applied normally.

[0135] The business system proxy module is deployed in various business systems as a software development kit, acting as a request interceptor or filter after the business system receives access requests. The core functional chain of the business system proxy module includes intercepting access requests, extracting access tokens, deriving the end-to-end tracing identifier of this request, initiating permission verification by calling the dynamic permission engine module, receiving allow or deny instructions, and reporting event information to the end-to-end security audit module.

[0136] When the business system proxy module intercepts an access request, it first extracts the end-to-end tracing identifier seed and the current value of the monotonic counter bit from the payload of the access token carried in the access request. Then, the business system proxy module increments the value of the monotonic counter bit by 1, and uses the incremented value as... Substituting into the derived formula given in the aforementioned method implementation section... The end-to-end tracing identifier corresponding to this access request is derived. This method of first incrementing and then deriving ensures that multiple requests in the same session obtain different but related end-to-end tracing identifiers.

[0137] The key feature of this derivation method is that the end-to-end tracing identifier relies on the existing transparent channel of the access token to complete the cross-business system transmission, without requiring the business system to add new HTTP request header fields or modify existing request formats. The seed plus monotonic counter derivation method ensures that multiple requests within the same session receive mutually distinguishable yet associative identifiers, facilitating log merging by session during the auditing phase. In Zhang San's baseline scenario, from login to the 5th business request, the business system proxy module sequentially uses... Substituting 1, 2, 3, 4, and 5 into the derivation formula, five end-to-end tracing identifiers, TID-20260429-1430-001, TID-20260429-1430-002, TID-20260429-1430-003, TID-20260429-1430-004, and TID-20260429-1430-005, are derived in sequence. These five identifiers share the same seed S-AB12CD34 and can be quickly aggregated into a continuous sequence of behaviors within the same session during the auditing phase.

[0138] After the derivation is completed, the business system proxy module initiates a permission verification request to the dynamic permission engine module. The request carries the subject attribute, resource attribute, environment attribute, and the end-to-end tracing identifier of this request. After the dynamic permission engine module completes the permission determination, it returns an allow or deny instruction, and the business system proxy module executes the allow or deny accordingly. After the request is completed, the business system proxy module pushes the business operation event information corresponding to this request to the end-to-end security audit module.

[0139] In some embodiments, the business system agent module is provided as a software development kit (SDK) in at least four programming languages: Java, Python, Go, and Node.js. Each SSD version in each programming language has the same token extraction and verification, permission verification invocation, and event reporting functions. This multi-language SSD covers business systems with heterogeneous technology stacks within the enterprise, ensuring unified access capabilities regardless of the specific language used by the business system.

[0140] The end-to-end security audit module receives event information from the unified identity authentication module, the dynamic permission engine module, and the business system agent module. It performs structured collection on authentication event information, permission authentication event information, and business operation event information according to the unified log structure to obtain structured logs. The structured logs are then written to the log storage medium through an asynchronous message queue.

[0141] The unified log structure includes a set of fields such as timestamp, end-to-end tracing identifier, event type, subject identifier, resource identifier, operation result, environment attributes, and decision basis. In Zhang San's baseline scenario, the following is an example of the field filling for the three structured log entries generated by Zhang San's access to the sales report interface.

[0142] Example of field filling for authentication event log: Timestamp = 2026-04-29 14:30:00.000, End-to-End Tracking Identifier = Not yet assigned and will be uniformly assigned in the S5 phase, Event Type = Login Authentication, Subject Identifier = E1002, Resource Identifier = Login Entry, Operation Result = Authentication Passed, Environment Attributes = {Client Network Address = 10.20.30.5, Device Fingerprint = D-001}, Decision Basis = Username, Password and Multi-Factor Authentication.

[0143] Example of field filling for the authorization event log: Timestamp = 2026-04-29 14:30:15.123, End-to-End Tracking Identifier = TID-20260429-1430-005, Event Type = Authorization, Subject Identifier = E1002, Resource Identifier = / erp / sales-report, Operation Result = Allowed, Environment Attributes = {Access Time = 14:30, Client Network Address = 10.20.30.5, Device Fingerprint = D-001}, Decision Basis = Policy P-001 v4 plus Behavior Deviation 0.6.

[0144] Example of field filling for business operation event log: Timestamp = 2026-04-29 14:30:15.500, End-to-End Tracking Identifier = TID-20260429-1430-005, Event Type = Business Operation, Subject Identifier = E1002, Resource Identifier = / erp / sales-report, Operation Result = Query Successful, Environment Attributes = {Client Network Address = 10.20.30.5, Device Fingerprint = D-001}, Decision Basis = The data scope of this operation is limited to the sales department.

[0145] Asynchronous message queues can be implemented using message middleware such as Kafka or RabbitMQ. Structured logs are first buffered locally in the end-to-end security audit module, and then submitted to the message queue in batches. The message queue smooths out log write peaks across various business systems, preventing log write pressure from being directly transmitted to the log storage medium in high-concurrency scenarios. The log storage medium can be implemented using a distributed search engine such as Elasticsearch, supporting multi-dimensional indexing based on fields such as end-to-end tracing identifiers, subject identifiers, and resource identifiers.

[0146] The end-to-end security audit module provides two types of query interfaces. The first type is a chain-link log query interface based on end-to-end tracing identifiers. Inputting an end-to-end tracing identifier returns a complete set of authentication event logs, authorization event logs, and business operation event logs under that identifier, sorted by timestamp to form a continuous request behavior trajectory. The second type is a multi-dimensional log retrieval interface based on users, time, or resources. Inputting a subject identifier, time range, or resource identifier returns a list of logs that meet the criteria. This can be used as input for further analysis. For example, after retrieving all logs for a user by subject identifier, all end-to-end tracing identifiers can be extracted, and then the complete request trajectories under each identifier can be aggregated through the first type of interface. These two types of interfaces respectively support different auditing needs: end-to-end chain tracing and multi-dimensional log retrieval.

[0147] The end-to-end security audit module also builds user behavior baselines for each user based on historical structured logs. The baseline construction process is as described above, using a combination of sliding window and incremental learning for continuous updates. After the baseline is built, the baseline data is provided to the policy information points of the dynamic permission engine module as a reference for calculating behavioral deviation when determining permissions.

[0148] To further illustrate the application of the single sign-on system provided in this application embodiment in a real enterprise environment, three specific application scenarios are given below.

[0149] Scenario 1: Fine-grained data access control

[0150] A company's financial management system has a monthly financial statement query interface. Access to this interface needs to be differentiated based on user job level. The system administrator configures the following two permission policy rules through the policy management point.

[0151] Rule 1: When user.role = 'Finance Specialist' AND resource.path = ' / finance / monthly-report' THEN ALLOW with data_scope = user.department. This rule restricts the Finance Specialist to only being able to query the monthly financial reports of their department.

[0152] Rule #2: When user.role IN ('Financial Manager', 'Chief Financial Officer', 'CFO') AND resource.path = ' / finance / monthly-report' THEN ALLOW with data_scope = 'company', this rule restricts access to the company's monthly financial reports to those at the Financial Manager level and above.

[0153] Here's an example illustrating the system's response process in this scenario. Wang Wu, a finance specialist with employee ID E1050, works in the sales department. When Wang Wu accesses the ` / finance / monthly-report` interface, the business system's proxy module intercepts the request and initiates a permission check with the dynamic permission engine module. The request carries the following attributes: subject (`E1050`, sales department, finance specialist`), resource (` / finance / monthly-report`, `?`, query`), and environment (`current time`, Wang Wu's network address, Wang Wu's device fingerprint`). The dynamic permission engine module evaluates the first rule above. Since the job level and resource path conditions are met, the decision is made to allow the request and limit the data range to the sales department. Based on this, the business system's proxy module allows the request, and the financial management system only returns the monthly financial report data for the sales department.

[0154] The Chief Financial Officer, Zhao Liu, has employee ID E2010. When Zhao Liu accesses the / finance / monthly-report interface, the dynamic permission engine module evaluates the second rule mentioned above. Both the job level and resource path conditions are met, resulting in a permission decision that allows access and limits the data scope to the entire company. The financial management system then returns monthly financial report data from all departments across the company.

[0155] The above scenario illustrates that the attribute expressions of the permission policy rules can be used to achieve differentiated data range restrictions for different job levels on the same interface. The restriction of the data range is directly achieved through the attribute expressions of the permission policy rules without relying on additional coding on the business system side.

[0156] Scenario 2: Real-time control of sensitive operations

[0157] A company's user center has deployed an interface for modifying mobile phone numbers. This interface involves critical changes to account-bound information and is considered a sensitive operation. The system administrator has configured the following permission policy rules through the policy management point.

[0158] Rule: When `resource.operation = 'modify_phone' AND env.access_timewithin '09:00-18:00' AND env.day_of_week IN (Mon-Fri) AND env.client_ipwithin '10.20.0.0 / 16' THEN ALLOW; ELSE DENY`, this rule requires that phone number modification operations are only allowed during weekday working hours and only for requests originating from the company's intranet.

[0159] Here's an example illustrating the system's response process in this scenario. Zhang San accesses the mobile phone number modification interface via his office computer at 14:30 on a weekday. The business system's proxy module intercepts the request and initiates a permission check. The environment attributes are {Access Time = 14:30, Weekday = Wednesday, Client Network Address = 10.20.30.5, Device Fingerprint = D-001}. The dynamic permission engine module evaluates the above rules. The time period condition is met (14:30 falls within the 9:00-18:00 range); the weekday condition is met (Wednesday falls within the Mon-Fri range); and the network address condition is met (10.20.30.5 falls within the 10.20.0.0 / 16 range). The overall decision is to allow access.

[0160] Zhang San accessed the mobile number modification interface via his home network at 22:00 on Sunday. The environment attributes were {Access Time = 22:00, Day of the Week = Sunday, Client Network Address = 180.5.6.7, Device Fingerprint = D-002}. The dynamic permission engine module evaluated the above rules. The time period condition was not met (22:00 is not within the 9:00-18:00 range); the day of the week condition was not met (Sunday is not within the Mon-Fri range); and the network address condition was not met (180.5.6.7 is not within the 10.20.0.0 / 16 range). The overall result was a rejection. The business system proxy module returned a 403 status code to the client, with the response body including the reason for rejection ("Sensitive operation can only be executed from the corporate intranet during working hours on weekdays") and the full-link tracing identifier of this request.

[0161] The above scenario illustrates that, based on a combination of environmental factors such as access time, weekday, and client network address, the execution scope of sensitive operations is precisely limited.

[0162] Scenario 3: Security Incident Tracing

[0163] One day, the enterprise security operations center received an alert about abnormal export of customer data. The alert event pointed to user ID E1002, i.e., Zhang San. The auditor needs to reconstruct when, where, and what happened to the alert in order to determine whether it constitutes an actual security event.

[0164] Auditors completed the source tracing through the query interface provided by the end-to-end security audit module. The first step involved using the user identifier E1002 from the alarm event as the key, and retrieving all logs for E1002 within the alarm time window using the user-based multi-dimensional log retrieval interface. The search results contained dozens of logs, covering authentication events, authorization events, and business operation events. The second step involved extracting all end-to-end tracing identifiers from the search results and removing duplicates, resulting in several identifiers involved in this source tracing, such as TID-20260429-1430-005, TID-20260429-1430-006, and TID-20260429-1430-007. The third step involved aggregating all three types of logs under each end-to-end tracing identifier using the end-to-end log concatenation query interface based on that identifier. For example, the aggregation result for TID-20260429-1430-005 includes Zhang San's authentication event log, permission authentication event log, and business operation event log. After being sorted by timestamp, a complete request behavior trajectory is formed: 14:30:00.000 Zhang San logs in, 14:30:15.123 Zhang San is allowed to access the sales report interface, 14:30:15.500 Zhang San completes the sales report query.

[0165] By aggregating and analyzing all relevant end-to-end tracking identifiers, auditors can reconstruct Zhang San's complete behavioral trajectory within the alarm time window, determine whether the alarm constitutes an actual security event, and make a decision on handling the situation based on a complete chain of evidence.

[0166] The above scenario illustrates that, using end-to-end tracking identifiers as clues, events generated across three modules can be reconstructed into a continuous sequence of behaviors of the same user, providing a chain of evidence throughout the entire process for post-event tracing.

[0167] 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 used as 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 device can be divided into different functional units or modules to complete all or part of the functions described above.

[0168] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A single sign-on system integrating dynamic access control and end-to-end security auditing, characterized in that, It includes: The unified identity authentication module is configured to receive login requests from business systems, perform authentication operations on the login requests, generate a global session identifier and issue an access token after the authentication operation is successful, and push authentication event information to the end-to-end security audit module. The permission storage module, connected to the unified identity authentication module and the dynamic permission engine module, is configured to store user basic information, permission policy rules and user attribute data, and to push policy change notifications to the dynamic permission engine module through a publish-subscribe channel when the permission policy rules are changed. The dynamic permission engine module, connected to the permission storage module and the business system agent module, is configured to receive permission verification requests from the business system agent module. The permission verification request includes at least three types of attribute information: subject attributes, resource attributes, and environment attributes. The module performs permission determination based on the subject attributes, resource attributes, environment attributes, and permission policy rules obtained from the permission storage module. Based on the determination result, the module returns an allow instruction or a deny instruction to the business system agent module and pushes permission authentication event information to the end-to-end security audit module. The business system proxy module is configured to intercept access requests from the business system on the business system side, extract the access token from the access request and forward it to the unified identity authentication module for token validity verification, and after the token validity verification is passed, initiate the permission verification request to the dynamic permission engine module and push business operation event information to the end-to-end security audit module. The end-to-end security audit module receives event information from the unified identity authentication module, the dynamic permission engine module, and the business system proxy module, respectively. It is configured to generate an end-to-end tracing identifier for each access request, perform structured collection on the authentication event information, the permission authentication event information, and the business operation event information based on the unified log structure to obtain structured logs, and write the structured logs to the log storage medium through an asynchronous message queue.

2. The single sign-on system integrating dynamic access control and end-to-end security auditing as described in claim 1, characterized in that, The permission storage module includes a relational database and a cache. The relational database is configured to persistently store the user's basic information, the permission policy rules, and the policy version history. The cache is configured to store the compiled policy decision tree and hot user permission data. After receiving a change in the permission policy rules, the permission storage module pushes the policy change notification to the dynamic permission engine module through the publish-subscribe channel, and the cache performs incremental updates based on the policy change notification.

3. The single sign-on system integrating dynamic access control and end-to-end security auditing as described in claim 1, characterized in that, The dynamic permission engine module includes: The policy decision point is configured to receive the permission verification request from the business system agent module, and perform the permission determination based on the subject attribute, resource attribute, and environment attribute in the permission verification request and the permission policy rules provided by the policy information point; The policy information point is configured to obtain the latest permission policy rules and user attribute data from the permission storage module and user attribute source in real time, and provide the permission policy rules and user attribute data to the policy decision point; The policy execution point is configured to return the allow instruction or the deny instruction to the business system agent module based on the determination result of the policy decision point, and to push the determination result and the matching policy rule identifier to the end-to-end security audit module. The policy management point is configured to receive policy configuration operations, generate the corresponding permission policy rules, and publish the permission policy rules through the permission storage module.

4. The single sign-on system integrating dynamic access control and end-to-end security auditing as described in claim 3, characterized in that, The subject attributes include at least one or more of user identity, department, and job level; the resource attributes include at least one or more of interface path, data range, and operation type; and the environment attributes include at least one or more of access time, client network address, and device fingerprint.

5. The single sign-on system integrating dynamic access control and end-to-end security auditing as described in claim 1, characterized in that, The authentication operations supported by the unified identity authentication module include at least one or more of username and password authentication, multi-factor authentication, and directory service authentication. After the authentication operation is successful, the unified identity authentication module generates the global session identifier and issues the access token, which carries the global session identifier and the user identity identifier. The unified log structure adopted by the end-to-end security audit module includes the following fields: timestamp, end-to-end tracing identifier, event type, subject identifier, resource identifier, operation result, environment attribute, and decision basis; the end-to-end security audit module is also configured to provide an end-to-end log concatenation query interface based on the end-to-end tracing identifier and a multi-dimensional log retrieval interface based on user, time, or resource.

6. The single sign-on system integrating dynamic access control and end-to-end security auditing according to claim 2, characterized in that, The dynamic permission engine module is also configured to generate a corresponding policy version number for the permission policy rule when generating the permission policy rule. The cache is configured to maintain two policy decision trees at the same time: the current version and the version to be activated. After receiving the policy change notification, the dynamic permission engine module switches the policy decision tree of the version to be activated to the current version, and retains the current version before the switch until all the permission determinations based on the current version before the switch are completed and then releases it. The dynamic permission engine module returns the determination result to the business system agent module, which carries the policy version number used in this permission determination. The policy version number is also pushed to the end-to-end security audit module as an audit field.

7. The single sign-on system integrating dynamic access control and end-to-end security auditing according to claim 6, characterized in that, When issuing the access token, the unified identity authentication module embeds the end-to-end tracing identifier seed, the monotonic counter bit, and the policy version number used in the most recent permission determination into the payload of the access token; when the business system proxy module intercepts the access request of the business system, it extracts the end-to-end tracing identifier seed and the monotonic counter bit from the payload of the access token carried by the access request, and derives the end-to-end tracing identifier corresponding to the current access request based on the current values ​​of the end-to-end tracing identifier seed and the monotonic counter bit.

8. The single sign-on system integrating dynamic access control and end-to-end security auditing according to claim 5, characterized in that, The end-to-end security audit module is also configured to build a user behavior baseline for each user based on the historical structured logs. The user behavior baseline includes at least the distribution of typical access time periods, the distribution of typical client network address ranges, and the distribution of typical resource access frequencies. When performing the permission determination, the dynamic permission engine module compares the environment attribute and resource attribute in the current permission verification request with the user behavior baseline to obtain the behavior deviation degree. The dynamic permission engine module uses the behavior deviation degree as a fourth type of attribute, along with the subject attribute, resource attribute, and environment attribute, to participate in the evaluation of the permission policy rule. When the behavior deviation degree exceeds a predetermined threshold, the dynamic permission engine module adjusts the determination result from allow to require secondary authentication.

9. The single sign-on system integrating dynamic access control and end-to-end security auditing according to claim 8, characterized in that, When generating the permission policy rules, the dynamic permission engine module assigns a key-level tag or a non-key-level tag to each permission policy rule; the permission storage module immediately pushes the corresponding policy change notification through the publish-subscribe channel for the permission policy rules with the key-level tag, and merges the permission policy rules with the non-key-level tag within a preset time window and pushes the corresponding policy change notification in batches. When the end-to-end security audit module detects that the deviation of the behavior of the target user has reached the escalation threshold, it temporarily switches the push method of the permission policy rule with the non-critical level mark for the target user to immediate push. For users whose baseline sample size of user behavior has not reached the baseline threshold, the dynamic permission engine module relaxes the predetermined threshold of the behavior deviation and writes the result of the behavior deviation as an audit field into the log without adjusting the judgment result.

10. A single sign-on control method, characterized in that, Includes the following steps: S1. Receive a login request from the business system, perform an authentication operation on the login request, generate a global session identifier and issue an access token after the authentication operation is successful, and record authentication event information; S2. Intercept the access request of the business system, extract the access token from the access request and perform a validity check on the access token, and after the validity check passes, obtain the subject attribute, resource attribute and environment attribute from the access request; S3. Perform permission determination on the access request based on the subject attribute, the resource attribute, the environment attribute and the latest permission policy rules, obtain the determination result and record the authentication event information; S4. Perform an allow operation or a deny operation on the access request according to the determination result, and record the operation event information corresponding to the access request after performing the allow operation; S5. Assign end-to-end tracing identifiers to the authentication event information, the authorization event information, and the operation event information, and write the authentication event information, the authorization event information, and the operation event information with the end-to-end tracing identifiers to the log storage medium via an asynchronous message queue according to the unified log structure.

Images