Authentication method, device and system applied to service system and storage medium

Abstract

The invention provides an authentication method, device and system applied to a service system and a storage medium, and the method comprises the steps: receiving an authentication strategy obtaining request sent by an authentication execution device of the service system, and enabling the authentication strategy obtaining request to carry a first strategy version identifier; and when the second authentication strategy data is obtained and the strategy version of the second authentication strategy data is different from the strategy version of the first authentication strategy data, sending the second authentication strategy data to the authentication execution equipment so as to trigger the authentication execution equipment to respond to the authentication request of the service processing equipment of the service system based on the second authentication strategy data. By adopting the method and the device, the authentication policy data synchronization is triggered when the version identifiers are inconsistent through a policy version identifier comparison mechanism between the devices on the two sides, so that safe, credible, high-efficiency and high-performance authentication can be realized.

Description

Technical Field

[0001] The present application relates to the field of Internet technology, and in particular to an authentication method, device, system and storage medium applied to a business system. Background Art

[0002] As a core component for system security, permission management systems typically employ an architecture that integrates identity and access management (IAM) systems with multiple business systems. Traditionally, IAM systems utilize a role-based access control (RBAC) model to establish a centralized permission management center responsible for user authentication, role assignment, and permission policy maintenance. Business systems (such as project management systems and procurement systems) then implement permission verification requests through interface calls.

[0003] The inventors of this application discovered through research and practice that while this architecture achieves logical centralization of permissions management, it suffers from significant technical deficiencies in practical applications. For example, the permissions verification process relies on the real-time response of a central node (such as an IAM system). In high-concurrency scenarios, the central node carries significant traffic pressure, resulting in significant system availability risks and easily leading to system performance bottlenecks. This leads to delayed responses in business systems and high operational and maintenance costs. Furthermore, the availability risks of other systems that rely on the central node are amplified, easily causing cascading failures between systems. If a software development kit (SDK) is integrated locally within a business system to implement local authentication, the data synchronization mechanism generally adopts a passive pull model. For example, the SDK makes unidirectional, periodic requests to the IAM system to synchronize permissions policies. When permissions policies are dynamically adjusted, the business system struggles to obtain the latest authorization information in a timely manner, potentially creating security risks of unauthorized access. The authentication results are also less reliable and less applicable. Summary of the Invention

[0004] The present application provides an authentication method, device, system and storage medium applied to a business system, which can realize data synchronization update after the authentication policy data changes, ensure the timeliness of the authentication policy data, and thus improve the credibility of the authentication results, with high applicability.

[0005] In the first aspect, the present application provides an authentication method applied to a business system, which is suitable for an authority management device. The method includes: receiving an authentication policy acquisition request sent by an authentication execution device of the business system based on a predetermined timing rule, wherein the above-mentioned authentication policy acquisition request carries a first policy version identifier, and the above-mentioned first policy version identifier is used to mark the policy version of the first authentication policy data stored by the above-mentioned authentication execution device; when the second authentication policy data is obtained, and the policy version of the above-mentioned second authentication policy data is different from the policy version of the above-mentioned first authentication policy data, the above-mentioned second authentication policy data is sent to the above-mentioned authentication execution device to trigger the above-mentioned authentication execution device to respond to the authentication request of the business processing device of the above-mentioned business system based on the above-mentioned second authentication policy data. In the present application, an authentication policy acquisition request sent by an authentication execution device of a business system can be received to obtain the first policy version identifier carried in the authentication policy acquisition request, and then when the second authentication policy data is obtained and the policy version of the second authentication policy data is different from the policy version of the first authentication policy data, the authentication policy data synchronization is triggered, which can reduce the repeated transmission of data with the same version to reduce the waste of transmission resources and reduce the pressure on data transmission. At the same time, it can realize the synchronous update of data after the authentication policy data changes, ensure the timeliness of the authentication policy data, and thus improve the credibility of the authentication result, with high applicability.

[0006] In a possible implementation of the first aspect, the above-mentioned receiving the authentication policy acquisition request sent by the authentication execution device of the business system based on a predetermined timing rule includes: receiving the authentication policy acquisition request sent by the authentication execution device of the business system based on a target period, wherein the authentication policy acquisition request carries the valid response time of the authentication policy acquisition request, and the valid response time is less than or equal to one cycle time of the target period. In the present application, the authentication policy acquisition request sent by the authentication execution device of the business system can be received based on the target period, and the authentication policy acquisition request carries the valid response time of the authentication policy acquisition request, and the valid response time is less than or equal to one cycle time of the target period, which can ensure that the authentication policy acquisition request becomes invalid after the valid response time. Based on the control of the valid response time, authentication problems caused by response delays can be avoided, and the reliability and timeliness of the authentication process can be improved. At the same time, the sending and receiving method based on the target period can maintain the timeliness of the authentication policy, thereby better adapting to the dynamic changes and security requirements of the business system.

[0007] In a possible implementation of the first aspect, the obtaining of the second authentication policy data includes: obtaining the stored authentication policy data from the local storage space within the effective response time after receiving the authentication policy acquisition request, and comparing the policy version of the stored authentication policy data with the policy version of the first authentication policy data; when the policy version of the stored authentication policy data is different from the policy version of the first authentication policy data, determining the stored authentication policy data as the second authentication policy data to obtain the second authentication policy data. In the present application, within the effective response time after receiving the authentication policy request, the stored authentication policy data can be obtained from the local storage space, and then the policy version of the authentication policy data can be compared with the policy version of the first authentication policy data. Only when the policy versions are different, the authentication policy data synchronization is triggered. This can achieve real-time synchronization of the authentication policy data when the authentication policy data versions are different within the effective time, that is, after the authentication policy data changes, thereby improving the authentication efficiency and the credibility of the authentication results, and having high applicability.

[0008] In a possible implementation of the first aspect, before the authentication policy acquisition request sent by the authentication execution device of the business system is received based on the predetermined timing rules, the method further includes: when the business object information of the business processing device of the business system is obtained to change, generating third authentication policy data applicable to the changed business object information and a third policy version identifier of the third authentication policy data, and updating the authentication policy data stored in the local storage space to the third authentication policy data, and updating the policy version identifier of the authentication policy data stored in the local storage space to the third policy version identifier; wherein the business object information includes at least one of the business object identifier, the role of the business object, or the role authority of the business object. In the present application, before receiving an authentication policy acquisition request, when the business object information of the business processing device in the business system is obtained to have changed, an authentication policy and version identifier adapted to the new business scenario can be generated immediately and updated synchronously to the local storage space, which can ensure that the policy data responds to the business status changes of the business system in a timely manner, avoiding the deviation of the authentication result caused by the delay in updating the authentication policy data. At the same time, the real-time refresh in the local storage space enables the subsequent comparison to be performed directly based on the latest policy version when responding to the authentication policy acquisition request, thereby improving the efficiency of the policy data version comparison, thereby reducing the response delay of the authentication policy acquisition request, improving the efficiency of policy data synchronization and the credibility of the authentication results, and having high applicability.

[0009] In a possible implementation of the first aspect, when the second authentication policy data is obtained and the policy version of the second authentication policy data is different from the policy version of the first authentication policy data, the second authentication policy data is sent to the authentication execution device, including: when the business object information of the business processing device of the above-mentioned business system is obtained within the above-mentioned effective response time after receiving the above-mentioned authentication policy acquisition request, the second authentication policy data applicable to the changed business object information and the second policy version identifier of the above-mentioned second authentication policy data are generated, and the above-mentioned second policy version identifier is different from the above-mentioned first policy version identifier; the second authentication policy data is sent to the above-mentioned authentication execution device; wherein the above-mentioned business object information includes at least one of the business object identifier, the role of the business object or the role authority of the business object. In this application, when a change in business object information is detected within the effective response time, new authentication policy data and version identifier that match the changed business scenario are generated in real time and actively pushed to the authentication execution device, thereby improving the efficiency of synchronizing the latest version of authentication policy data. By actively pushing synchronized data, the request frequency of the authentication execution device is reduced, and the waste of transmission resources for data synchronization is reduced, thereby optimizing network resource utilization and the overall response efficiency of the system. At the same time, the timeliness of policy data synchronization and the credibility of authentication results are improved, and the applicability is high.

[0010] In a possible implementation of the first aspect, after the second authentication policy data applicable to the changed business object information and the second policy version identifier of the second authentication policy data are generated, the method further includes: updating the authentication policy data stored in the local storage space to the second authentication policy data, and updating the policy version identifier of the authentication policy data stored in the local storage space to the second policy version identifier. In the present application, after the second authentication policy data and the second policy version identifier that adapt to the business object changes are dynamically generated, they can be stored in the local storage space in real time to ensure that the locally stored authentication policy data and policy data version serve the latest business object information, and then serve as a subsequent trusted version comparison benchmark, reducing redundant authentication policy data transmission and improving the synchronization efficiency of authentication policy data.

[0011] In the second aspect, the present application provides an authentication method applied to a business system, which is applicable to an authentication execution device, the method comprising: sending an authentication policy acquisition request to an authority control device based on a predetermined timing rule, wherein the authentication policy acquisition request carries a first policy version identifier, and the first policy version identifier is used to mark the policy version of the first authentication policy data stored in the authentication execution device of the business system, and enables the authority control device to determine whether it is necessary to issue the second authentication policy data to the authentication execution device according to the first policy version identifier, and the policy version of the second authentication policy data is different from the policy version of the first authentication policy data; receiving the second authentication policy data issued after the authority control device determines that the second authentication policy data needs to be issued according to the first policy version identifier; when receiving the first authentication request sent by the business processing device of the business system, performing authentication on the business object information carried in the first authentication request based on the second authentication policy data, and returning the authentication result of the business object information to the business processing device. In this application, an authentication policy acquisition request can be sent to the permission control device based on a preset timing rule. The request carries the identifier of the first policy version currently stored locally. When the permission control device returns the second authentication policy data with an updated version, the stored authentication policy data can be updated, and the second authentication policy data can be used for authentication when the authentication request is received. This not only avoids the high latency of the traditional polling method, but also reduces the load on the central node through localized authentication. At the same time, the version identification comparison mechanism ensures the accurate synchronization of policy updates, thereby achieving high availability and real-time performance of the authentication service, improving the accuracy and credibility of the authentication results, and having high applicability.

[0012] In a possible implementation of the second aspect, the sending of an authentication policy acquisition request to the permission control device based on a predetermined timing rule includes: sending an authentication policy acquisition request to the permission control device based on a target period, wherein the authentication policy acquisition request carries a valid response time of the authentication policy acquisition request, the valid response time is less than or equal to one period of the target period, and the period is the interval between any two adjacent authentication policy acquisition requests sent to the permission control device. In the present application, an authentication policy acquisition request can be sent to the permission control device based on a target period, the request carries a valid response time of the authentication policy acquisition request, the valid response time is less than or equal to one period of the target period, and the period is the interval between any two adjacent authentication policy acquisition requests sent to the permission control device. This ensures that the authentication policy acquisition request becomes invalid after the valid response time. Based on the control of the valid response time, authentication problems caused by response delays can be avoided, thereby improving the reliability and timeliness of the authentication process. At the same time, the target cycle-based sending and receiving method can maintain the timeliness of the authentication policy, thereby better adapting to the dynamic changes and security requirements of the business system.

[0013] In a possible implementation of the second aspect, the second authentication policy data is received within the nth cycle after the authentication policy acquisition request is sent, where n is an integer greater than or equal to 2. After the authentication policy acquisition request is sent to the authority control device based on the predetermined timing rule, the method further includes: when the second authentication request sent by the business processing device of the business system is received within the mth cycle, authentication is performed on the business object information carried in the second authentication request based on the authentication policy data stored by the authentication execution device, and the mth cycle is any cycle before the nth cycle. In the present application, local authentication policy data can be used for authentication before new authentication policy data is received, that is, local authentication policy data can be used to ensure service continuity, which has high applicability.

[0014] On the third aspect, the present application provides an authentication method applied to a business system, which is applicable to an authentication execution device, the method comprising: sending a policy version acquisition request to a permission control device; when, after sending the above-mentioned policy version acquisition request, a target policy version identifier fed back by the above-mentioned permission control device is received, and the above-mentioned target policy version identifier is different from the policy version identifier of the locally stored authentication policy data, sending a policy data synchronization request to the above-mentioned permission control device to trigger the above-mentioned permission control device to send the target authentication policy data corresponding to the above-mentioned target policy version identifier; when the above-mentioned target authentication policy data fed back by the above-mentioned permission control device is received, updating the above-mentioned locally stored authentication policy data to the above-mentioned target authentication policy data, and when receiving the authentication request sent by the business processing device of the business system, performing authentication on the business object information carried in the above-mentioned authentication request based on the above-mentioned target authentication policy data, and returning the authentication result of the above-mentioned business object information to the above-mentioned business processing device. In the present application, a policy version acquisition request can be sent to the permission control device. If a target policy version identifier different from the locally stored version is received, a policy data synchronization request is immediately triggered to obtain the corresponding target authentication policy data. This two-stage process of verifying version differences and then synchronizing policy data effectively reduces unnecessary data transmission and network overhead. Full policy synchronization is triggered only when version inconsistencies are detected. During the actual authentication process, the authentication execution device makes real-time authentication decisions based on the latest locally stored target authentication policy data. This improves the timeliness of authentication policy data and the accuracy of authentication results, ensuring high reliability and applicability.

[0015] In the fourth aspect, the present application provides an authentication method applied to a business system, which is applicable to a permission control device, and the method includes: receiving a policy version acquisition request sent by an authentication execution device of the business system; sending a target policy version identifier to the above-mentioned authentication execution device, wherein the above-mentioned target policy version identifier is used to mark the policy version of the target authentication policy data stored by the permission control device; when receiving a policy data synchronization request sent by the above-mentioned authentication execution device, sending the above-mentioned target authentication policy data to the above-mentioned authentication execution device. In the present application, after receiving the policy version acquisition request sent by the authentication execution device, the currently stored target policy version identifier can be returned to improve the timeliness of the version check operation, avoid the problem of long waiting time, ensure that the policy change can be detected more promptly, reduce latency, and avoid policy synchronization problems caused by delays. In addition, when the comparison finds that the returned target policy version identifier is inconsistent with the locally stored version, a policy data synchronization request will be immediately initiated to trigger the permission control device to send the complete target version policy data, effectively avoiding unnecessary data transmission, improving resource utilization, and high applicability.

[0016] In a possible implementation of the fourth aspect, the method further includes: when the business object information of the business processing device of the business system is detected to have changed, generating authentication policy data and a policy version identifier for the authentication policy data applicable to the changed business object information; and updating the target authentication policy data stored in the permission control device to the generated authentication policy data and the target policy version identifier to the generated policy version identifier. In the present application, when a change in the business object information of the business processing device of the business system is detected, new authentication policy data matching the changed business scenario is generated in real time, and a new policy version identifier is assigned to the authentication policy data, thereby ensuring that the policy permission data adapts to the change in business status in real time. In addition, the target authentication policy data and target policy version identifier stored in the permission control device are synchronously updated to the latest generated version and then sent to the authentication execution device, so that the permission adjustment can take effect immediately when the business demand changes. At the same time, the update of the version identifier provides an accurate version comparison basis for subsequent policy synchronization, ensuring that each business processing device can obtain the latest permission policy in a timely manner, effectively avoiding unnecessary data transmission, improving resource utilization, and improving the response speed of permission management while ensuring the accuracy of the authentication result, thereby achieving high applicability.

[0017] In a fifth aspect, the present application provides a permission management device, which includes a module or unit for executing the authentication method applied to the business system provided in the first aspect or any possible implementation method of the first aspect.

[0018] Exemplarily, the above-mentioned permission control device includes: a request receiving unit, configured to receive, based on a predetermined timing rule, an authentication policy acquisition request sent by an authentication execution device of a business system, wherein the authentication policy acquisition request carries a first policy version identifier, and the first policy version identifier is used to mark a policy version of the first authentication policy data stored by the authentication execution device; The data sending unit is used to send the second authentication policy data to the authentication execution device when the second authentication policy data is obtained and the policy version of the second authentication policy data is different from the policy version of the first authentication policy data, so as to trigger the authentication execution device to respond to the authentication request of the business processing device of the business system based on the second authentication policy data.

[0019] In a sixth aspect, the present application provides an authentication execution device, which includes a module or unit for executing the authentication method applied to a business system as provided in the second aspect or any possible implementation method of the second aspect.

[0020] Exemplarily, the authentication execution device includes: a policy request unit, configured to send an authentication policy acquisition request to the permission control device based on a predetermined timing rule, wherein the authentication policy acquisition request carries a first policy version identifier, the first policy version identifier being used to mark the policy version of first authentication policy data stored by the authentication execution device of the business system, and enabling the permission control device to determine, based on the first policy version identifier, whether to issue second authentication policy data to the authentication execution device, the policy version of the second authentication policy data being different from the policy version of the first authentication policy data; a policy updating unit configured to receive the second authentication policy data issued by the permission control device after determining that the second authentication policy data needs to be issued according to the first policy version identifier; The authentication execution unit is used to perform authentication on the business object information carried in the first authentication request based on the second authentication policy data when receiving the first authentication request sent by the business processing device of the above-mentioned business system, and return the authentication result of the above-mentioned business object information to the above-mentioned business processing device.

[0021] In a seventh aspect, the present application provides an authentication execution device, which includes a module or unit for executing the authentication method applied to a business system as provided in the third aspect or any possible implementation method of the third aspect.

[0022] Exemplarily, the authentication execution device includes: A version request unit, used to send a policy version acquisition request to the permission management device; a version acquisition unit configured to, upon receiving a target policy version identifier fed back by the permission control device after sending the policy version acquisition request, and if the target policy version identifier is different from the policy version identifier of the locally stored authentication policy data, send a policy data synchronization request to the permission control device to trigger the permission control device to send the target authentication policy data corresponding to the target policy version identifier; The authentication implementation unit is used to update the above-mentioned locally stored authentication policy data to the above-mentioned target authentication policy data when receiving the above-mentioned target authentication policy data fed back by the above-mentioned authority management device, and when receiving the authentication request sent by the business processing device of the business system, perform authentication on the business object information carried in the above-mentioned authentication request based on the above-mentioned target authentication policy data, and return the authentication result of the above-mentioned business object information to the above-mentioned business processing device.

[0023] In an eighth aspect, the present application provides a permission management device, which includes a module or unit for executing an authentication method applied to a business system as provided in the fourth aspect or any possible implementation method of the fourth aspect.

[0024] Exemplarily, the above-mentioned permission control device includes: A request acquisition unit, configured to receive a policy version acquisition request sent by an authentication execution device of a business system; A version sending unit, configured to send a target policy version identifier to the authentication execution device, wherein the target policy version identifier is used to mark the policy version of the target authentication policy data stored in the permission control device; The synchronization response unit is configured to send the target authentication policy data to the authentication execution device upon receiving the policy data synchronization request sent by the authentication execution device.

[0025] In the ninth aspect, the present application provides an authentication system based on the sidecar proxy model, the system including: the permission control device provided in the fifth aspect and the authentication execution device provided in the sixth aspect; or, the authentication execution device in the seventh aspect and the permission control device provided in the eighth aspect.

[0026] In the tenth aspect, the present application provides a computer-readable storage medium, which stores a computer program. The computer program can execute the authentication method applied to the business system provided by any possible implementation method of the first to fourth aspects or the first to fourth aspects.

[0027] In the eleventh aspect, the present application provides a computer program product, which includes: computer program code, which, when run, can execute the authentication method applied to the business system provided by any possible implementation of the above-mentioned first to fourth aspects or the first to fourth aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 This is a schematic diagram of the system architecture of the authentication method applied to a business system provided in an embodiment of the present application; Figure 2 This is a schematic diagram of an application scenario of the authentication method applied to a business system provided by an embodiment of the present application; Figure 3 This is a flow chart of an authentication method applied to a business system provided by an embodiment of the present application; Figure 4 This is a diagram showing the relationship between business object information provided in an embodiment of the present application; Figure 5 This is a flow chart of refreshing the policy version identifier provided by an embodiment of the present application; Figure 6 This is a flowchart of the authentication operation provided by the embodiment of the present application; Figure 7 This is another flowchart of the authentication method applied to a business system provided by an embodiment of the present application; Figure 8 This is another flowchart of the authentication method applied to a business system provided by an embodiment of the present application; Figure 9 This is another flowchart of the authentication method applied to a business system provided by an embodiment of the present application; Figure 10 This is a schematic diagram of the structure of the permission management device provided in the embodiment of the present application; Figure 11 This is a schematic diagram of the structure of the authentication execution device provided in an embodiment of the present application; Figure 12 This is another structural diagram of the permission management device provided in an embodiment of the present application; Figure 13 This is another structural diagram of the authentication execution device provided in an embodiment of the present application; Figure 14 This is a schematic diagram of the structure of an authentication system based on the sidecar proxy mode provided in an embodiment of the present application; Figure 15 This is another structural diagram of the authentication system based on the sidecar proxy mode provided in an embodiment of the present application. DETAILED DESCRIPTION

[0029] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0030] In a distributed computing environment, permission management systems, as core components for system security, typically employ an architecture model in which an IAM system works collaboratively with multiple business systems. Traditional implementations utilize a centralized permission management center responsible for user authentication, role assignment, and permission policy maintenance. Business systems (such as project management systems and procurement systems) implement permission verification requests through interface calls. While this architecture centralizes the logic of permission management, it suffers from significant technical drawbacks in practical applications. First, the permission verification process relies on real-time responses from central nodes, which can easily lead to performance bottlenecks in scenarios with network latency or high concurrency, resulting in delayed business system responses. For example, in online e-commerce shopping scenarios, massive user operations require permission verification. Using a traditional architecture, the IAM system carries excessive traffic pressure per unit time, increasing system availability risks and raising system operation and maintenance costs. Furthermore, as a central node, the IAM system amplifies the availability risks of other systems that rely on it, potentially leading to cascading system failures. Secondly, with local authentication, permission data synchronization mechanisms generally rely on a passive pull model, meaning that permission policies are synchronized through the business system in a one-way, scheduled manner. When permission policies are dynamically adjusted, it becomes difficult for the business system to obtain the latest authorization information in a timely manner, potentially reducing the credibility of the authentication results. For example, when integrating an SDK locally within a business system to implement local authentication, the SDK's requests for IAM data synchronization are one-way and scheduled. Consequently, the SDK's local permission policy data may not be updated in real time, meaning it cannot match the updated business object information, reducing the credibility of the authentication results.

[0031] The authentication method applied to the business system provided in the embodiment of the present application adopts an authentication system in a sidecar proxy mode. Through a policy version identification comparison mechanism between the devices on both sides of the authority management device and the authentication proxy device of the business system, authentication policy data synchronization is triggered when the version identification is inconsistent. This can reduce the repeated transmission of data with the same version to reduce the waste of transmission resources and reduce the pressure of data transmission. At the same time, it can realize the synchronous update of data after the authentication policy data changes, ensure the timeliness of the authentication policy data, and thus improve the credibility of the authentication result, with high applicability.

[0032] See Figure 1 , Figure 1 This is a schematic diagram of the system architecture of the authentication method applied to the business system provided by the embodiment of the present application. Figure 1As shown, the system architecture may include a server 201 and a terminal cluster. The terminal cluster may include terminal devices such as terminal device 200a, terminal device 200b, terminal device 200c, ..., and terminal device 200n. The server 201 may be a standalone physical server, a server cluster or a distributed system consisting of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud databases, cloud services, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal devices (including terminal devices 200a, terminal device 200b, terminal device 200c, ..., and terminal device 200n) may be, but are not limited to, smart terminals such as PDAs, smartphones, laptops, desktop computers, tablets, mobile internet devices (MIDs), wearable devices (such as smart watches and smart bracelets), and smart computers. It is understood that the server 201 described above can serve as the permission management server in the authentication system. The permission management server can generally serve as a central permission management system, uniformly responsible for user authorization, role permission management, permission verification, and other services for all connected business systems. Correspondingly, the terminal cluster can serve as the permission management client in the authentication system, and the multiple terminal devices in the terminal cluster can be regarded as multiple business systems.

[0033] Among them, the server 201 can establish a communication connection with each terminal device in the terminal cluster, and a communication connection can also be established between each terminal device in the terminal cluster. In other words, the server 201 can establish a communication connection with each terminal device in the terminal device 200a, terminal device 200b, terminal device 200c, ..., terminal device 200n. For example, a communication connection can be established between the terminal device 200a and the server 201. A communication connection can be established between the terminal device 200a and the terminal device 200b, and a communication connection can also be established between the terminal device 200a and the terminal device 200c. Among them, the above-mentioned communication connection does not limit the connection method, and can be directly or indirectly connected through a wired communication method, or can be directly or indirectly connected through a wireless communication method, etc., which can be determined according to the actual application scenario, and this application does not limit it here.

[0034] It should be understood that Figure 1Each terminal device in the terminal cluster shown can be used as the business system involved in the embodiment of the present application. Each terminal device can be deployed with a business processing device / service or module (hereinafter referred to as a business processing device for the convenience of description), an authentication execution device / service or module (hereinafter referred to as an authentication execution device for the convenience of description), etc. Here, the authentication execution device can be independent of the business processing device and correspond one-to-one with each business processing device. The specific details can be determined according to the actual application scenario and are not limited here. The authentication execution device acts as a permission control client and can be accessed from the permission control server (such as Figure 1 The server 201 in the system synchronizes the data required for authority control (such as authentication policy data, etc.) to respond to the authentication requests of the business processing devices of each business system, such as performing authority verification on user requests. When the authentication execution device runs on each terminal device, it can be respectively connected to the above-mentioned Figure 1 A secure communication channel is established between the servers 201 shown in FIG. 2 to achieve dynamic interaction of authentication policy data. For example, each terminal device (such as Figure 1 The authentication execution device corresponding to the terminal device 200a, terminal device 200b, ..., terminal device 200n shown in the figure) can send an authentication policy acquisition request to the server 201, and the request can carry data information such as the current locally stored permission policy version identifier and the request validity period. The server 201 can be deployed with a permission management module as a permission management device. After receiving the above-mentioned authentication policy acquisition request, it can dynamically generate or retrieve authentication policy data for corresponding business object information based on the RBAC model or the attribute-based access control (ABAC) model. Here, the authentication policy data can carry, including but not limited to permission rules, effective time, policy version identifier, etc., and be returned to the corresponding terminal device through the above-mentioned secure communication channel or other links. The specific details can be determined according to the actual application scenario and are not limited here.

[0035] Optionally, in some feasible implementations, the business object information may include, but is not limited to, at least one of a business object identifier, a business object role, or a business object role permissions. It is understood that business object information, as a core element for dynamic authentication policy adaptation, can include basic business object identifiers (e.g., unique identifiers such as user IDs, device serial numbers, and service instance UUIDs), as well as the roles of the associated business object in specific application scenarios (e.g., the "administrator" and "auditor" role hierarchies in project management) and role permissions (e.g., fine-grained permission configuration, such as "read and write permissions," "operation scope restrictions," and "time window constraints"). Depending on the business scenario, this information can be expanded to include dynamic attributes (e.g., geographic location, device security status, and session risk level). The specific attributes can be determined based on the actual application scenario and are not limited here. For example, in a financial transaction scenario, business object information may include the trader's identity, their departmental role (e.g., risk control department, trading department), and real-time transaction permissions (e.g., single transaction limits and trading time periods). In the Industrial Internet of Things (IIoT), the device object's identifier, its production line role (e.g., sensor node, control terminal), and current operating state permissions (e.g., operation restricted zones in high-temperature mode) together form the basis for permission decisions. When business object information changes (such as user role upgrades or changes in the device access environment), the system triggers policy reconstruction by capturing such change events in real time, ensuring that the authentication policy is strictly synchronized with the business object status. For example, when an operation and maintenance personnel is temporarily assigned an emergency maintenance role, their associated permission policy will be dynamically generated and marked with a new version identifier, and pushed to the relevant terminal devices through the incremental synchronization mechanism, so that the permission adjustment takes effect in real time, avoiding the risk of unauthorized operations or permission vacuums caused by information lags in traditional solutions, and improving the credibility of the authentication results.

[0036] Optionally, in some feasible implementations, the authentication execution device deployed on the business processing device supports multiple deployment forms. It can be run as an independent process (such as an independently running SDK package, etc.), or embedded in the business processing device (such as the permission management component of the project management system or an intrusive SDK, etc.), or integrated with the edge computing framework. The specific details can be determined according to the actual application scenario and are not specifically limited. When a user or system triggers a resource access request, the terminal device performs a real-time authentication decision based on the locally cached authentication policy data. Here, the security policy data maintains policy consistency with the server 201 through an incremental policy synchronization mechanism (such as version identification comparison, policy data synchronization, etc.). For example, when the server 201 detects a change in role permissions, it actively pushes the updated authentication policy data and version identification to the relevant terminal device. After receiving the updated authentication policy data, the terminal device immediately stores the updated authentication policy data to refresh the local policy library to ensure the real-time and accuracy of subsequent authentication operations.

[0037] Optionally, in some feasible implementations, the permission management device provided in the embodiments of the present application includes but is not limited to a centralized IAM service cluster, a policy management middleware (such as an OPA-based policy server) or a distributed authentication agent (such as an independently deployed authentication microservice). The specific details can be determined according to the actual application scenario and are not limited here. For example, when IAM is used as a core component, it can usually be deployed decoupled from the server in the form of an independent service cluster, and the two perform policy synchronization and decision interaction through a secure communication protocol (such as HTTPS, mTLS). Here, IAM is responsible for the generation, version management and change push of global policies, and the terminal device directly processes the authentication request through the locally associated authentication execution device, etc., and only initiates incremental synchronization to IAM when the policy version expires or a change event is detected, ensuring that the server 201 can achieve efficient and autonomous permission decisions. For the convenience of description, the permission management device and / or authentication execution device provided in the subsequent description of the embodiments of the present application will be explained using a server and / or computer as an example.

[0038] For the convenience of description, the SDK installed on the terminal device 200c and running independently is used as the authentication execution device, and the IAM system deployed on the server 201 is used as an example. Figure 2 The following describes the usage scenarios of the authentication method provided in the embodiments of the present application.

[0039] See also Figure 2 , Figure 2 This is a schematic diagram of an application scenario of the authentication method applied to a business system provided by an embodiment of the present application. Figure 2 The permission control server shown may include an identity and access management system. As a permission control server, the identity and access management system can be used to uniformly manage user identities, authentication policy data, and issue user permission credentials. The permission credentials here can be tokens or certificates that carry user role information. The authentication policy data can include but is not limited to the correspondence between users, roles, and permissions. The specific details can be determined according to the actual application scenario and are not limited here. The permission control client can include multiple business systems (such as Figure 2 As shown in FIG, business system 1, business system 2 and business system 3, each business system may include a business processing device (such as Figure 2 As shown in FIG, business processing device 1, business processing device 2 and business processing device 3), each business processing device can deploy an independently running SDK as an authentication execution device (such as Figure 2As shown in the SDK1, SDK2, and SDK3 diagram, each business processing device can be used to carry the actual business functions of the business system. After the SDK completes permission verification, it can allow users to access or perform operations. Here, the SDK can encapsulate the authentication protocol and interact with the permission management server to synchronize authentication policy data and perform authentication. Taking business processing device 1 and SDK1 in business system 1 as an example, assume that a user logs into the identity and access management system through a terminal device and obtains permission credentials related to business processing device 1 (such as an encrypted token containing user role information). When accessing business processing device 1, the user can carry this permission credential to initiate a user access request. SDK1 deployed on business processing device 1 can obtain this user access request and then perform authentication locally based on the locally stored authentication policy data. The authentication result is returned to business processing device 1, which then determines whether to allow the user to access the resources in business processing device 1 based on the authentication result. It can be understood that in this process, SDK1 can periodically send authentication policy acquisition requests to the identity and access management system. The identity and access management system returns the authentication policy data when the authentication policy data changes to refresh the authentication policy data stored locally by SDK1. Then, SDK1 can use the locally stored authentication policy data to authenticate the permission credentials carried in the user access request to obtain the authentication result. The method for accessing the business processing device 2 in the business system 2 or the business processing device 3 in the business system 3 is similar to the above process and will not be elaborated here. In an embodiment of the present application, the user's permission credentials are authenticated locally on the permission control client based on the authentication policy data, which can realize real-time synchronization of permission data and dynamic verification of permissions, ensuring that legitimate users access the corresponding business processing devices. At the same time, the independent deployment of the SDK reduces the coupling with the business processing devices and improves the authentication efficiency and security.

[0040] It is understandable that in the specific implementation of this application, when it involves object information and other related data, when the embodiments of this application are applied to specific products or technologies, it is necessary to obtain the object's permission or consent, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions.

[0041] The following will be combined Figures 3 to 13 The authentication method and device applied to the business system provided in the embodiments of the present application are described in detail.

[0042] Authentication method embodiment 1: See also Figure 3 , Figure 3 This is a flow chart of an authentication method applied to a business system provided by an embodiment of the present application. Figure 3As shown, the authentication method provided in the embodiment of the present application can be implemented by the interaction between the authentication execution device and the permission management device. The method may include the following steps: S301: The authentication execution device sends an authentication policy acquisition request to the authority control device based on a predetermined timing rule, wherein the authentication policy acquisition request carries a first policy version identifier.

[0043] In some feasible implementations, the authentication execution device can send an authentication policy acquisition request to the authority control device based on a predetermined timing rule. The first policy version identifier carried in the authentication policy acquisition request is used to mark the policy version of the first authentication policy data stored by the authentication execution device, and can enable the authority control device to determine whether it is necessary to send the second authentication policy data to the authentication execution device based on the above-mentioned first policy version identifier, wherein the policy version of the second authentication policy data is different from the policy version of the above-mentioned first authentication policy data. Here, the predetermined timing rule can be periodic or non-periodic. For example, it can be set to send an authentication policy acquisition request every 5 minutes, or it can be set to send an authentication policy acquisition request at a specific time point every day. The specific time can be determined according to the actual application scenario and is not limited here. Optionally, the above-mentioned authentication execution device can be an SDK that runs independently on the business processing device deployed in the business system, or it can be a hardware security module, an authentication microservice, a security component, a proxy gateway, etc. The specific time can be determined according to the actual application scenario and is not limited here. For the convenience of description, the SDK deployed on the business processing device in the business system and running independently will be used as the authentication execution device for example. The SDK deployed on the business processing device in the business system and running independently is non-invasive to the business processing device, reducing the system coupling. At the same time, the SDK can be packaged and run independently after it is applied to systems in different languages, avoiding the cost of developing and maintaining multiple language versions of the SDK and improving the flexibility of authentication SDK integration. For example, an SDK developed for the Java language can be packaged as a jar and run. The specific details can be determined according to the actual application scenario and are not restricted here.

[0044] In some feasible implementations, the authentication execution device may send an authentication policy acquisition request to the authority control device based on a target period, wherein the period duration of the target period is the interval between any two adjacent authentication policy acquisition requests sent to the authority control device, and the authentication policy acquisition request may carry the effective response duration of the authentication policy acquisition request. Optionally, the effective response duration may be less than or equal to one period duration. In the case of high real-time requirements, the effective response duration may be set equal to one period duration, that is, after an authentication policy acquisition request times out, a new authentication policy acquisition request may be sent to ensure real-time performance. In some cases, such as when the server is under great pressure or resource competition is fierce, the above-mentioned effective response time can be set to be less than a cycle time, that is, a cycle time can include an effective response time and a waiting time. When an authentication policy acquisition request times out and fails, it waits for a certain period of time before initiating the next authentication policy acquisition request, so as to reduce server pressure, balance real-time and performance, optimize resource allocation, etc. In other words, by reasonably configuring the ratio of effective time and cycle time (that is, configuring waiting time), a balance between system real-time, reliability and resource consumption can be achieved. The specific details can be determined according to the actual application scenario and are not restricted here.

[0045] Optionally, in some feasible implementations, the target period can be generated based on historical periods or historical feedback, or it can be user-configured. The specific implementation can be determined based on the actual application scenario and is not limited here. It is understood that the authentication policy acquisition request can be a signal format agreed upon by both the sender and receiver (i.e., the permission control device and the authentication execution device) based on a protocol to ensure that both parties can parse and process the data information contained in the authentication policy acquisition request, such as the effective response time and the target period duration. The protocol here can include, but is not limited to, HTTP / HTTPS, WebSocket, etc., and can be determined based on the actual communication method and is not limited here. For example, it can be a long-polling HTTP request with a timeout, etc., and can be determined based on the actual application scenario and is not limited here. For example, the configuration item "strategy" in the SDK's .properties configuration file containing the synchronization strategy can be set to "long-polling", which configures the SDK to long-polling push mode, in which the SDK initiates a long-polling HTTP request to the permission control device. It is understood that the long polling HTTP request may include, but is not limited to, the SDK's local authentication policy version identifier (i.e., the aforementioned first policy version identifier) ​​and the expiration time (i.e., the aforementioned effective response duration). The specific duration can be determined based on the actual application scenario and is not limited here. The expiration time (i.e., the effective response duration) can be set in the SDK via HTTP headers or parameters. The specific duration can be determined based on the actual application scenario and is not limited here.

[0046] Optionally, in some feasible implementations, the above-mentioned policy version identifier can be generated by the permission management device and sent to the authentication execution device along with the authentication policy data. The above-mentioned policy version identifier can include but is not limited to an N-bit integer (N is a positive integer, usually N can take a value of 32, 64 or 128, etc., which is determined according to the actual application scenario and is not limited here), a timestamp, a semantic version, a hash value, an incremental enumeration, etc., or it can be a composite version of the above-mentioned various types, which can be determined according to the actual application scenario and is not limited here.

[0047] S302, the authority control device receives an authentication policy acquisition request sent by the authentication execution device of the business system based on a predetermined timing rule, wherein the above-mentioned authentication policy acquisition request carries a first policy version identifier, and the above-mentioned first policy version identifier is used to mark the policy version of the first authentication policy data stored by the above-mentioned authentication execution device.

[0048] In some feasible implementations, the above-mentioned permission control device can be used to manage, store, and distribute authentication policy data. Here, the permission control device can be an IAM system, a policy administration point (PAP), a configuration management database (CMDB), etc., and the specific details can be determined according to the actual application scenario and are not limited here. Here, since the authentication policy acquisition request can be a signal form based on the protocol agreement between the sending and receiving ends (i.e., the permission control device and the authentication execution device), the permission control device can obtain the data information carried in the authentication policy acquisition request from the above-mentioned authentication policy acquisition request after obtaining the authentication policy acquisition request, such as the first policy version identifier and the effective response time of the authentication policy request.

[0049] In some feasible implementations, the authority control device can receive an authentication policy acquisition request sent by an authentication execution device of a business system based on a target period, wherein the authentication policy acquisition request carries the valid response time of the authentication policy acquisition request, and the valid response time is less than or equal to one cycle time of the target period. It can be understood that the interval between any two authentication policy acquisition requests is one cycle time of the target period. Optionally, the valid response time can be less than or equal to one cycle time, which can be determined according to the actual application scenario and is not limited here. In an embodiment of the present application, the authority control device can receive an authentication policy acquisition request sent by an authentication execution device of a business system based on a target period, and the authentication policy acquisition request carries the valid response time of the authentication policy acquisition request, and the valid response time is less than or equal to one cycle time of the target period. This can ensure that the authentication policy acquisition request becomes invalid after the valid response time. Based on the control of the valid response time, authentication problems caused by response delays can be avoided, thereby improving the reliability and timeliness of the authentication process. At the same time, the target cycle-based sending and receiving method can maintain the timeliness of the authentication policy, thereby better adapting to the dynamic changes and security requirements of the business system.

[0050] In some feasible implementations, the permission management device can utilize an IAM system and an IAM technology stack (such as AWS IAM, Azure AD, or the open-source Keycloak) to achieve real-time, efficient synchronization of security policy data through an application programming interface (API) mechanism in long-polling mode. For example, the authentication execution device can call the permission management device's policy synchronization API and send an authentication policy retrieval request to the permission management device. This request may include the identifier of the currently locally stored first policy version (e.g., policy_version=v1.2) and a valid response time (e.g., timeout=30s). Upon receiving the authentication policy retrieval request, the permission management device compares the policy version in the request with the latest version to ensure consistency. If the authentication execution device's policy version is outdated (i.e., the first policy version in the request is inconsistent with the authentication policy data stored on the permission management device), the device can immediately return the latest authentication policy data via an HTTP 200 response. HTTP 200 is a standard status code in the HTTP protocol that indicates that the authentication request initiated by the authentication enforcement device has been successfully received, understood, and processed by the permission control device (i.e., a new version of the authentication policy data has been issued in response to the request). The authentication policy data returned in the HTTP 200 response can be in a variety of structured formats, including but not limited to JSON policy documents, YAML format, and the Rego policy language. The specific format depends on the actual application scenario and is not limited here. If the authentication enforcement device's policy is already the latest version (i.e., the first policy version carried in the request is consistent with the authentication policy data stored in the permission control device), the connection remains suspended until the authentication policy data changes or the preset valid response time expires. At this point, an HTTP 304 status code is returned, the connection is disconnected, and the next authentication policy request is received. HTTP 304 is another standard status code in the HTTP protocol that indicates that the authentication policy data has not been modified (i.e., the policy has not been updated and the authentication enforcement device maintains its current state). It is understood that the above-mentioned authentication execution device can be connected to the permission management device through the form of a long polling API interface. Here, the long polling API interface for the IAM system may include but is not limited to a basic polling interface, a conditional filtering interface, a multi-protocol interface, a cloud service integration interface, etc. The specific interface can be determined according to the actual application scenario and is not limited here. In the embodiment of the present application, the use of the long polling API can achieve real-time synchronization of incremental authentication policy data between the permission management device and the authentication execution device, reduce system coupling, reduce most invalid polling requests, save bandwidth, and reduce resource consumption.

[0051] S303: When second authentication policy data is obtained and the policy version of the second authentication policy data is different from the policy version of the first authentication policy data, the permission control device sends the second authentication policy data to the authentication execution device.

[0052] Specifically, when the second authentication policy data is obtained and the policy version of the second authentication policy data is different from the policy version of the first authentication policy data, the authority management device sends the second authentication policy data to the authentication execution device to trigger the authentication execution device to respond to the authentication request of the business processing device of the business system based on the second authentication policy data.

[0053] In some feasible implementations, the permission control device may obtain the first policy version identifier carried in the authentication policy acquisition request sent by the authentication execution device. Simultaneously, the permission control device may also obtain second authentication policy data. It is understood that the second authentication policy data may be authentication policy data stored in the local storage space of the permission control device, and may be the latest version of authentication policy data applicable to the authentication of the current business object information. It is understood that business object information may include, but is not limited to, at least one of a business object identifier, a business object role, or a business object role permission. The specific changes may vary depending on the actual application scenario and are not limited here. When business object information (such as roles or permissions) changes, such as when a user edits a role, edits the relationship between a role and permissions, or edits permissions, the permission control device may generate a new version of authentication policy data applicable to the current business object information and refresh the policy version identifier. Assuming the policy version identifier is a 64-bit integer, the refreshed policy version identifier may be incremental. The specific changes may vary depending on the actual application scenario and are not limited here. For ease of description, the following explanation will use the incremental 64-bit integer as the policy version identifier after a refresh. It can be understood that the policy version of the above-mentioned second authentication policy data (i.e., the authentication policy stored by the authority control device) can be higher than or equal to the policy version of the first authentication policy data (i.e., the authentication policy stored by the authentication execution device). When the policy version of the above-mentioned second authentication policy data is equal to the policy version of the first authentication policy data, it can indicate that the authentication policy data stored by the authority control device and the authentication execution device are consistent; when the policy version of the above-mentioned second authentication policy data is higher than the policy version of the first authentication policy data, it can indicate that the authentication policy data stored by the authority control device and the authentication execution device are inconsistent, and the first authentication policy data may no longer be applicable to the latest business object information authentication, and a new version of authentication policy data applicable to the changed business object information needs to be generated. For example, see Figure 4 , Figure 4 This is a diagram showing the relationship between the business object information provided by the embodiment of this application. Figure 4The business object information shown includes users, roles, permissions, and the correspondence between the three. There is a correspondence between roles and permissions. For example, the role of "Project Administrator" corresponds to the permissions of "Add Project", "View Project", and "Delete Project". There can be a correspondence between roles and users, that is, roles can be authorized or assigned to users, a user can be assigned to multiple roles, and a role can be assigned to multiple users. The relationship between roles and permissions can be many-to-many, which can be determined according to the actual application scenario and is not limited here. Take a user as an example for explanation. Figure 4 The user shown in has two roles: "Project Administrator" and "Project Member Group Administrator". The "Project Administrator" role corresponds to the three permissions of "Add Project", "View Project" and "Delete Project". The "Project Member Group Administrator" role corresponds to the three permissions of "Add Project Group", "Add Member" and "Delete Project Group". Since the user has both the "Project Administrator" and "Project Member Group Administrator" roles, the user has a total of six permissions corresponding to the above two roles. Please refer to Figure 5 , Figure 5 This is a flow chart of refreshing the policy version identifier provided by the embodiment of the present application. Figure 5 As shown, the permission management device generates a 64-bit integer initial policy version identifier. It can be understood that the authentication policy data corresponding to the initial policy version identifier at this time can provide authentication for the initial business object information. The permission management device can continuously or periodically detect whether the business object information has changed. The specific details can be determined according to the actual application scenario and are not limited here. If it is detected that the business object information has not changed, the authentication policy data corresponding to the initial policy version identifier will continue to be used and the business object information will continue to be detected. If it is detected that the business object information has changed, the permission management device can refresh the policy version identifier, and the policy version identifier will be increased by one. Here, changes in business object information include but are not limited to user editing roles, the relationship between editing roles and permissions, editing permissions, etc., which can be determined according to the actual application scenario and are not limited here. As Figure 4 In the business object information shown, assuming that the user's "project member group administrator" identity is deleted, the business object information has changed. The authority management device can generate authentication policy data applicable to the changed business object information and refresh the policy version identifier. The policy version identifier is numerically increased by one compared to the initial policy version identifier of the authentication policy data before the update. The authentication policy data corresponding to the above-mentioned refreshed policy version identifier can be applicable to the changed business object information.

[0054] In some feasible implementations, since the authentication execution device can send an authentication policy acquisition request to the authority control device based on a target period, where the period duration of the target period can be the interval duration between any two adjacent authentication policy acquisition requests, and the authentication policy acquisition request can carry the valid response duration of the authentication policy acquisition request, then correspondingly, the authority control device can obtain the first policy version identifier and valid response duration carried in the above authentication policy acquisition request based on the target period. Furthermore, the authority control device can obtain the stored authentication policy data from the local storage space within the above valid response duration after receiving the above authentication policy acquisition request, and compare the policy version of the above stored authentication policy data with the policy version of the above first authentication policy data. When the policy version of the above stored authentication policy data is different from the policy version of the above first authentication policy data, the above stored authentication policy data is determined as the above second authentication policy data to obtain the above second authentication policy data. Here, the local storage space of the permission control device may include, but is not limited to, a relational database (such as MySQL), an embedded database (such as SQLite), a key-value store (such as Redis), a file system (such as a JSON / YAML file), or a security chip (such as a TPM). The data storage format of the authentication policy data stored in the local storage space may adopt, but is not limited to, a structured format (such as JSON, Protocol Buffers), a database table structure, or a security-enhanced format (such as encrypted JSON, signed YAML), etc., which can be determined based on the actual application scenario and is not limited here. Within the above-mentioned effective response period after receiving the above-mentioned authentication policy acquisition request, the permission control device may obtain the above-mentioned authentication policy data from the above-mentioned local storage space through file reading, database query, cache loading (such as Redis HGET), etc., and may combine multi-level caching, memory-mapped files, or pre-loading to optimize performance, etc., which can be determined based on the actual application scenario and is not limited here. In an embodiment of the present application, within the effective response time after receiving the authentication policy request, the stored authentication policy data can be obtained from the local storage space, and then the policy version of the above authentication policy data can be compared with the policy version of the first authentication policy data. Only when the policy versions are detected to be different, the authentication policy data synchronization is triggered. This can achieve real-time synchronization of the authentication policy data after the authentication policy data versions are different within the effective time, that is, the authentication policy data changes, thereby improving the authentication efficiency and the credibility of the authentication results, and having high applicability.

[0055] Optionally, in some feasible implementations, before the authority control device receives the authentication policy acquisition request sent by the authentication execution device, when it is detected that the business object information of the business processing device in the above-mentioned business system has changed, the authority control device can generate third authentication policy data applicable to the changed business object information and a third policy version identifier of the above-mentioned third authentication policy data, and update the authentication policy data stored in the above-mentioned local storage space to the above-mentioned third authentication policy data, and update the policy version identifier of the authentication policy data stored in the above-mentioned local storage space to the above-mentioned third policy version identifier. The above-mentioned business object information includes at least one of a business object identifier, a role of a business object, or a role authority of a business object. For an implementation method of generating the third authentication policy data applicable to the changed business object information and the third policy version identifier of the above-mentioned third authentication policy data after the authority control device detects that the business object information has changed, please refer to Figure 4 and Figure 5 The corresponding embodiments will not be described in detail here. It can be understood that before the authority control device obtains the authentication policy acquisition request sent by the authentication execution device, the authority control device continuously or periodically detects the business object information of the business processing device in the business system, and after detecting the change, it can generate the authentication policy data and policy version identifier to be used to update the local storage, so that the authentication policy data in the storage space of the authority control device can adapt to the dynamically changing business object information in real time, and then when receiving the authentication policy acquisition request sent by the authentication execution device, the authority control device can complete the policy version comparison in real time and issue the authentication policy data applicable to the current business object information, thereby improving the accuracy of the authentication result. In an embodiment of the present application, before receiving an authentication policy acquisition request, when the business object information of the business processing device in the business system is obtained to have changed, an authentication policy and version identifier that adapts to the new business scenario can be generated immediately and updated synchronously to the local storage space, which can ensure that the policy data is strictly consistent with the business status, avoiding the deviation in the authentication result caused by the delay in updating the authentication policy data. At the same time, real-time refresh in the local storage space can enable subsequent authentication processes to be directly compared based on the latest policy version, reducing latency and improving the efficiency of policy data version comparison, thereby improving the efficiency of policy data synchronization and the credibility of the authentication results, and has high applicability.

[0056] In some feasible implementations, after the authority control device receives the above-mentioned authentication policy acquisition request, when the authority management device obtains that the business processing object information of the business processing device in the above-mentioned business system has changed, the authority control device can generate second authentication policy data applicable to the changed business object information and a second policy version identifier of the above-mentioned second authentication policy data, where the above-mentioned second policy version identifier is different from the above-mentioned first policy version identifier. The authority control device can send the above-mentioned second authentication policy data to the above-mentioned authentication execution device, wherein the above-mentioned business object information includes at least one of the business object identifier, the role of the business object, or the role authority of the business object. The implementation method of the authority control device generating the authentication policy data applicable to the changed business object information and the policy version identifier of the above-mentioned authentication policy data after detecting that the business object information has changed can be found in. Figure 4 and Figure 5 The corresponding embodiments will not be described in detail here.

[0057] Optionally, in some feasible implementations, the authority control device may receive an authentication policy acquisition request carrying an effective response time based on a target period. Here, the effective response time and the target period may refer to the aforementioned embodiment and will not be elaborated here. Within the above-mentioned effective response time after the authority control device receives the above-mentioned authentication policy acquisition request, the authority control device may obtain that when the business object information of the business processing device in the above-mentioned business system changes, the authority control device may generate second authentication policy data applicable to the changed business object information and a second policy version identifier of the above-mentioned second authentication policy data. Here, the above-mentioned second policy version identifier is different from the above-mentioned first policy version identifier. The authority control device may send the above-mentioned second authentication policy data to the above-mentioned authentication execution device, wherein the above-mentioned business object information includes at least one of a business object identifier, a role of a business object, or a role authority of a business object. The implementation method of the authority control device generating the authentication policy data applicable to the changed business object information and the policy version identifier of the above-mentioned authentication policy data after detecting that the business object information has changed can be referred to. Figure 4 and Figure 5The corresponding embodiments will not be described in detail here. It can be understood that within the effective response time after the authority control device obtains the authentication policy acquisition request sent by the authentication execution device, the authority control device continuously or periodically detects the business object information of the business processing device in the business system, and after detecting the change, it can generate and use the second authentication policy data and the second policy version identifier. Here, the second policy version identifier is different from the first policy version identifier. For example, the second policy version identifier can be the value of the first policy version identifier plus one, and the specific form can be determined according to the form of the policy version identifier, which is not limited here. After generating the above-mentioned second authentication policy data and the second policy version identifier, the authority control device sends the above-mentioned second authentication policy data to the authentication execution device to update the first authentication policy data stored in the authentication execution device, so that the first authentication policy data in the storage space of the authentication execution device can be applied to the changed business object information, thereby enabling the authentication execution device to perform authentication based on the updated first authentication policy data, thereby improving the accuracy of the authentication result. In an embodiment of the present application, when the authority control device detects that the business object information has changed within the effective response time of the authentication policy acquisition request, the authority control device can generate new authentication policy data and version identifier that matches the changed business scenario in real time, and actively push it to the authentication execution device, thereby reducing the delay in synchronizing the latest version of the authentication policy data. By actively pushing synchronized data, the frequency of authentication execution device requests is reduced, resource waste is reduced, network resource utilization and overall system response efficiency are optimized, and at the same time, the efficiency of policy data synchronization and the credibility of authentication results are improved, with high applicability.

[0058] In some feasible implementations, after the authority control device generates the second authentication policy data applicable to the changed business object information and the second policy version identifier of the second authentication policy data, it can update the authentication policy data stored in the local storage space to the second authentication policy data, and update the policy version identifier of the authentication policy data stored in the local storage space to the second policy version identifier. The implementation method of the authority control device generating the authentication policy data applicable to the changed business object information and the policy version identifier of the authentication policy data after detecting that the business object information has changed can be found in Figure 4 and Figure 5The corresponding embodiments will not be described in detail here. It can be understood that after the permission control device generates and issues the second authentication policy data and the second policy version identifier applicable to the changed business object information, it can update the authentication policy data stored in the local storage space to the second authentication policy data, so as to keep the authentication policy data in the permission control device storage space applicable to the changed business object information in real time, and then serve as a subsequent trusted version comparison benchmark. In an embodiment of the present application, after dynamically generating the second authentication policy data and the second policy version identifier that adapt to the business object change, they are stored in the local storage space in real time to ensure that the locally stored authentication policy data and policy data version serve the latest business object information, and then serve as a subsequent trusted version comparison benchmark, reducing redundant authentication policy data transmission and improving the synchronization efficiency of authentication policy data.

[0059] S304: The authentication execution device receives the second authentication policy data issued by the permission control device after determining that the second authentication policy data needs to be issued according to the first policy version identifier.

[0060] In some feasible implementations, the authentication execution device can receive and store the second authentication policy data returned by the permission control device. It is understood that the second authentication policy data applies to the changed current business object information. In other words, the first authentication policy data stored in the authentication execution device is no longer applicable to the current business object information. If authentication is performed based on the first authentication policy data, the credibility and accuracy of the authentication result will be affected. Here, the authentication execution device can store the second authentication policy data in its local storage space. The local storage space of the authentication execution device can include, but is not limited to, a relational database (e.g., MySQL), an embedded database (e.g., SQLite), a key-value store (e.g., Redis), a file system (e.g., a JSON / YAML file), or a security chip (e.g., a TPM). The data storage format of the authentication policy data stored in the local storage space of the authentication execution device can include, but is not limited to, structured formats (e.g., JSON, Protocol Buffers), database table structures, or security-enhanced formats (e.g., encrypted JSON, signed YAML). The specific format can be determined based on the actual application scenario and is not limited here.

[0061] S305, when receiving the first authentication request sent by the business processing device of the above-mentioned business system, the authentication execution device performs authentication on the business object information carried in the above-mentioned first authentication request based on the above-mentioned second authentication policy data, and returns the authentication result of the above-mentioned business object information to the above-mentioned business processing device.

[0062] In some feasible implementations, the business processing device in the business system can send a first authentication request to the authentication execution device. Here, the cross-process request between the business processing device and the SDK can be implemented through HTTP, remote procedure call (RPC), etc. The authentication execution device can receive the above-mentioned first authentication request, and obtain the business object information carried in the first authentication request based on the above-mentioned first authentication request. For example, the authentication execution device can obtain the role information owned by the user, and then based on the correspondence between the role and the authority in the authentication policy data, it can verify whether the user's request is legal, and then return the authentication result to the business processing device in the business system. The business processing device can further perform business processing based on the authentication result: when the authentication result is passed, the user's request can be responded to normally; when the authentication result is not passed, the user's request is rejected. For the sake of ease of understanding, the project management system is used as the business processing device in the business system, the SDK deployed on the project management system and runs independently as the authentication execution device, and the project management system and the SDK deployed on the project management system are used as business systems for example. Please refer to Figure 4 and Figure 6 , Figure 6 This is a flow chart of the authentication operation provided by the embodiment of the present application. Figure 4 The business object information shown shows that the role of "Project Administrator" corresponds to the three permissions of "Add Project", "View Project" and "Delete Project". Figure 6 As shown, assume that a user has the "Project Administrator" role. Here, business object information such as the user's role can be stored in a session control or a small text file (cookie), without the user's awareness. This information can be determined based on the actual application scenario and is not limited here. Assuming that the user wishes to access the project management system to view a project, the project management system can send a first authentication request to the SDK. The SDK receives and decrypts the first authentication request to obtain the user's role information. Then, based on the user's role and the corresponding permission information in the authentication policy data, the SDK can determine the user's permissions: "Add Project," "View Project," and "Delete Project." Furthermore, the SDK performs authentication and returns the result to the project management system. Here, since the user's "Project Administrator" role has the "View Project" permission, the authentication is successful, i.e., the result is "Authentication Passed." After receiving the authentication result, the project management system determines that the result is "Passed," allowing the user to view the project (i.e., display project information), and the authentication process ends. If the authentication result is failed, the user will be denied access to the project information.

[0063] Optionally, in some feasible implementations, the authentication execution device may send an authentication policy acquisition request carrying an effective response time to the authority control device based on a target period, wherein the authentication policy acquisition request carries the effective response time of the authentication policy acquisition request, and the effective response time is less than or equal to one period of the target period, and the period is the interval between any two adjacent authentication policy acquisition requests sent to the authority control device. Here, the effective response time and the target period can be found in the above embodiment and will not be elaborated here. The authentication execution device may receive the second authentication policy data within the nth period after sending the target authentication policy acquisition request, where n is an integer greater than or equal to 2. When the second authentication request sent by the business processing device of the business system is received within the mth period, the business object information carried in the second authentication request is authenticated based on the authentication policy data stored by the authentication execution device, and the mth period is any period before the nth period. It can be understood that when the policy version identifier carried in the target authentication policy acquisition request is consistent with the policy version identifier of the second authentication policy data in the authority control device, the authority control device will not feedback the second authentication policy data to the authentication execution device. Correspondingly, the authentication execution device will not receive the second authentication policy data during the period of sending the target authentication policy acquisition request, that is, the authentication execution device has not received any new authentication policy data update and will perform authentication based on the locally stored authentication policy data. For example, taking n as 2 and m as 1 as an example, the authentication execution device can receive the above-mentioned second authentication policy data within the second period after sending the target authentication policy acquisition request. Then, when receiving the authentication request sent by the business processing device in the business system within the first period after sending the target authentication policy acquisition request, the authentication execution device will perform authentication based on the locally stored authentication policy data. After receiving the second authentication policy data in the second cycle, the authentication execution device updates the locally stored authentication policy data with the second authentication policy data. Upon receiving another authentication request, the authentication execution device performs authentication based on the updated authentication policy data (i.e., the second authentication policy data). In this embodiment of the present application, local authentication policy data can be used for authentication before new authentication policy data is received. This ensures service continuity and is highly applicable.

[0064] To facilitate understanding of the process of the authentication method applied to the business system, the embodiment of the present application is combined with Figure 7 See Figure 7 , Figure 7 This is another flow chart of the authentication method applied to the business system provided by the embodiment of the present application, which uses the SDK deployed on the business processing device and runs independently as the authentication execution device, and uses IAM as the permission management device for example. Figure 7 As shown, the SDK can initiate an authentication policy acquisition request to the IAM based on the target period, wherein the authentication policy acquisition request may include but is not limited to the first policy version identifier and the effective response time of the authentication policy acquisition request. It can be understood that the above-mentioned first policy version identifier can be used to mark the policy version of the first authentication policy data stored in the SDK, and the above-mentioned effective response time can be less than or equal to one cycle time of the target period. The cycle time is the interval between any two adjacent authentication policy acquisition requests sent to the IAM. The specific effective response time and cycle time can be determined according to the actual application scenario and are not limited here. Assuming that the effective response time is less than 10 seconds, one cycle time of the target period, that is, the cycle time of a target period is equal to one effective response time plus a waiting time of 10 seconds. After one effective response time, the SDK will wait for 10 seconds before re-initiating the authentication policy acquisition request. As shown Figure 7 As shown, IAM determines whether the first policy version identifier is consistent with the second policy version identifier of the second authentication policy data stored locally by IAM. If the first policy version identifier is inconsistent with the second policy version identifier of the second authentication policy data stored locally by IAM, IAM is triggered to return the second authentication policy data and the corresponding second policy version identifier to the SDK. The SDK can update the locally stored first authentication policy data to the above second authentication policy data, and refresh the locally stored first policy version identifier to the above second policy version identifier. The SDK waits for 10 seconds after completing the refresh, and then re-initiates an authentication policy acquisition request to IAM. Figure 7 As shown, IAM determines whether the first policy version identifier is consistent with the second policy version identifier of the second authentication policy data stored locally by IAM. If the first policy version identifier is consistent with the second policy version identifier stored locally by IAM, IAM will wait for the authentication policy version identifier to change. When the valid response time ( Figure 7 The SDK then disconnects from the IAM, waits 10 seconds, and then resends the authentication policy request to the SDK. If the business object information changes within the validity period, the IAM will update the second authentication policy data and refresh the second policy version identifier. The updated second authentication policy data can be applied to the changed business object information. The process by which the IAM synchronizes the updated second authentication policy data and the corresponding second policy version identifier with the SDK can be found in the previous embodiment and will not be further described here.

[0065] In some feasible implementations, while the SDK waits for 10 seconds, the business object information may change. At this time, the IAM will update the second authentication policy data and refresh the second policy version identifier. Here, the updated second authentication policy data can be applied to the changed business object information. Furthermore, the second authentication policy data and the second policy version identifier are stored in local storage space, and within the valid response time of the next authentication policy acquisition request, the second policy version identifier is compared and then sent to the SDK for synchronization. The process of comparing the policy version identifier and sending the synchronization to the SDK after synchronization can be seen in the previous embodiment and will not be repeated here.

[0066] In general, the authentication method applied to the business system provided by the embodiment of the present application sends a message carrying the current policy version identifier to the authority control device through the authentication execution device, and the authority control device compares the request version with the latest policy version, and returns the latest authentication policy data if they are inconsistent. After receiving the new authentication policy data, the authentication execution device updates the locally stored authentication policy data so that subsequent authentication requests automatically adopt the new authentication policy data. Redundant transmission is reduced by comparing the policy version identifiers, and fast authentication is achieved by combining local caching, which significantly improves the authentication efficiency and real-time performance while ensuring security. It can be seen that the authentication method provided by the embodiment of the present application can improve the user experience and enhance the market competitiveness of the product, providing various types of enterprises with a more secure, reliable, efficient and high-performance authentication solution.

[0067] Authentication method embodiment 2: The present application also discloses another authentication method for a business system. Figure 8 , Figure 8 This is another flow chart of the authentication method applied to the business system provided by the embodiment of the present application. Figure 8 As shown, the authentication method provided in the embodiment of the present application can be implemented by the interaction between the authentication execution device and the permission management device. The method may include the following steps: S801: The authentication execution device sends a policy version acquisition request to the permission management device.

[0068] Optionally, the above-mentioned authentication execution device can be an SDK that runs independently on a business processing device deployed in a business system, or it can be a hardware security module, authentication microservice, security component, proxy gateway, etc. The specific details can be determined according to the actual application scenario and are not limited here. For the convenience of description, the SDK that runs independently on a business processing device deployed in a business system will be used as an example for authentication execution device. The SDK that runs independently on a business processing device is non-invasive to the business processing device, which reduces the coupling between the SDK and the business processing device. At the same time, the SDK is packaged and runs independently, which can be applied to systems in different languages, avoiding the cost of developing and maintaining multiple language versions of SDKs and improving the flexibility of authentication SDK integration. For example, an SDK developed for Java language can be run as a packaged jar. The specific details can be determined according to the actual application scenario and are not limited here.

[0069] Optionally, in some feasible implementations, the authentication enforcement device may send a policy version acquisition request to the permission control device, including a policy version feedback timeout, so that the permission control device responds to the authentication enforcement device according to the agreed-upon time point or periodic duration of the policy version feedback timeout. The specific duration can be determined based on actual application scenarios and is not limited here. The policy version feedback timeout can be generated based on historical duration data or historical feedback data, or can be configured by the user. The specific duration can be determined based on actual application scenarios and is not limited here. It is understood that the policy version acquisition request can be a signal format agreed upon by both the sender and receiver (i.e., the permission control device and the authentication enforcement device) based on a protocol to ensure that both parties can parse and process the data information contained in the policy version acquisition request. The protocol can include, but is not limited to, HTTP / HTTPS, WebSocket, etc., and can be determined based on the actual communication method and is not limited here. For example, the configuration item "strategy" in the SDK's .properties configuration file containing the synchronization strategy can be set to "Scheduled," which configures the SDK to use scheduled synchronization mode. The SDK will periodically (e.g., every 10 seconds) synchronize the policy version identifier stored on the permission control device with the permission control device.

[0070] S802: The authority management device receives a policy version acquisition request sent by the authentication execution device of the business system.

[0071] Optionally, the aforementioned permission control device can be used to manage, store, and distribute authentication policy data. Here, the permission control device can be an IAM system, a policy management server, a configuration management database, etc., and the specific details can be determined based on the actual application scenario and are not limited here. Here, since the policy version acquisition request can be a signal form based on the protocol agreement between the sending and receiving ends (i.e., the permission control device and the authentication execution device), the permission control device can obtain the data information carried in the policy version acquisition request from the above-mentioned policy version acquisition request after obtaining it, such as the policy version feedback duration, etc., and the specific details can be determined based on the actual application scenario and are not limited here.

[0072] S803: The authority control device sends a target policy version identifier to the authentication execution device, wherein the target policy version identifier is used to mark the policy version of the target authentication policy data stored in the authority control device.

[0073] In some feasible implementations, the permission control device may store the target authentication policy data and the corresponding target policy version identifier in a local storage space of the permission control device. The local storage space of the permission control device may include, but is not limited to, a relational database (e.g., MySQL), an embedded database (e.g., SQLite), a key-value store (e.g., Redis), a file system (e.g., a JSON / YAML file), or a security chip (e.g., TPM). The data storage format of the target authentication policy data and the target policy version identifier stored in the local storage space may adopt, but is not limited to, a structured format (e.g., JSON, Protocol Buffers), a database table structure, or a security-enhanced format (e.g., encrypted JSON, signed YAML). The specific format may be determined based on the actual application scenario and is not limited here. Before the permission control device sends the target policy version identifier to the authentication execution device, the permission control device may obtain the target policy version identifier from the local storage space through file reading, database query, cache loading (e.g., Redis HGET), and may combine multi-level caching, memory-mapped files, or pre-loading to optimize performance. The specific format may be determined based on the actual application scenario and is not limited here.

[0074] Optionally, in some feasible implementations, the above-mentioned target policy version identifier can be generated by a permission management device. The above-mentioned target policy version identifier can include but is not limited to an N-bit integer (N is a positive integer, usually N can take a value of 32, 64 or 128, etc., which is determined according to the actual application scenario and is not limited here), a timestamp, a semantic version, a hash value, an incremental enumeration and other types, or a composite version of the above-mentioned various types, which can be determined according to the actual application scenario and is not limited here.

[0075] In some feasible implementations, when the authority control device obtains that the business object information of the business processing device in the business system has changed, it can generate authentication policy data applicable to the changed business object information and a policy version identifier of the above-mentioned authentication policy data. Further, the authority control device can update the target authentication policy data stored in the authority control device to the above-mentioned authentication policy data generated, and update the above-mentioned target policy version identifier to the above-mentioned policy version identifier generated. Here, the above-mentioned business object information includes at least one of the business object identifier, the role of the business object, or the role authority of the business object. In an embodiment of the present application, when it is detected that the business object information of the business processing device in the business system has changed, new authentication policy data matching the changed business scenario is generated in real time, and a new policy version identifier is assigned to the authentication policy data, which can ensure that the policy authority data adapts to the changes in the business status in real time. In addition, the target authentication policy data and the target policy version identifier stored in the authority control device will be synchronously updated to the latest generated version and then sent to the authentication execution device, so that the authority adjustment can take effect as soon as the business demand changes. At the same time, the update of the version identifier provides an accurate version comparison basis for subsequent policy synchronization, ensuring that the business processing equipment in the business system can obtain the latest permission policy in a timely manner, effectively avoiding unnecessary data transmission, improving resource utilization, and improving the response speed of permission management while ensuring the accuracy of authentication results, with high applicability.

[0076] S804: After sending the policy version acquisition request, if a target policy version identifier is received from the permission control device, and the target policy version identifier is different from the policy version identifier of the locally stored authentication policy data, a policy data synchronization request is sent to the permission control device to trigger the permission control device to send the target authentication policy data corresponding to the target policy version identifier. In some feasible implementations, the authentication execution device may periodically or periodically receive a target policy version identifier from the permission control device. It is understood that the authentication policy data corresponding to the target policy version identifier may be the latest version of the authentication policy data applicable to the authentication of the current business object information. Here, the business object information may include, but is not limited to, at least one of a business object identifier, a business object role, or a business object role permission. The specific version may vary depending on the actual application scenario and is not limited here. When business object information (such as roles or permissions) changes, such as when a user edits a role, edits the relationship between roles and permissions, or edits permissions, the permission control device may generate a new version of the authentication policy data applicable to the current business object information and refresh the policy version identifier. Assuming the policy version identifier is a 64-bit integer, the refreshed policy version identifier may be incremental. The specific version may vary depending on the actual application scenario and is not limited here. For ease of description, the following explanation will use the incremental 64-bit integer as the policy version identifier after refreshing. It is understood that the policy version of the target authentication policy data (i.e., the authentication policy stored by the permission control device) may be greater than or equal to the policy version of the authentication policy stored locally on the authentication execution device. When the policy version of the target authentication policy data is equal to the policy version of the authentication policy data stored locally by the authentication execution device, it can indicate that the authentication policy data stored by the permission control device and the authentication execution device are consistent. When the policy version of the target authentication policy data is higher than the policy version of the authentication policy data stored locally by the authentication execution device, it can indicate that the authentication policy data stored by the permission control device and the authentication execution device are inconsistent. The authentication policy data stored locally by the authentication execution device may no longer be applicable to the latest business object information authentication and needs to be updated to a new version of authentication policy data applicable to the changed business object information. Therefore, when the authentication execution device receives the target policy version identifier fed back by the permission control device, and the target policy version identifier is different from the policy version identifier of the locally stored authentication policy data, the authentication execution device can send a policy data synchronization request to the permission control device. Optionally, the policy data synchronization request can be in the form of a signal agreed upon by both the sending and receiving ends (i.e., the permission control device and the authentication execution device) based on a protocol to ensure that both parties can parse and process the information carried by the policy data synchronization request signal. Here, the protocol may include but is not limited to HTTP / HTTPS protocol, WebSocket protocol, etc., and may be determined according to the actual communication method and is not limited here. For example, the SDK may synchronize the authentication policy data of the permission control device through HTTP request.

[0077] S805: When receiving the policy data synchronization request sent by the authentication execution device, the authority management device sends the target authentication policy data to the authentication execution device.

[0078] S806, when receiving the above-mentioned target authentication policy data fed back by the above-mentioned authority management device, the authentication execution device updates the above-mentioned locally stored authentication policy data to the above-mentioned target authentication policy data, and when receiving the authentication request sent by the business processing device of the business system, it performs authentication on the business object information carried in the above-mentioned authentication request based on the above-mentioned target authentication policy data, and returns the authentication result of the above-mentioned business object information to the above-mentioned business processing device.

[0079] In some feasible implementations, when the authentication execution device receives the target authentication policy data fed back by the permission control device, the authentication execution device may update the locally stored authentication policy data to the target authentication policy data. It is understood that the target authentication policy data applies to the changed current business object information. In other words, the authentication policy data stored in the authentication execution device is no longer applicable to the current business object information. If authentication is performed based on the authentication policy data, the credibility and accuracy of the authentication result will be affected. Here, the authentication execution device may store the target authentication policy data in its local storage space. The local storage space of the authentication execution device may include, but is not limited to, a relational database (e.g., MySQL), an embedded database (e.g., SQLite), a key-value store (e.g., Redis), a file system (e.g., a JSON / YAML file), or a security chip (e.g., a TPM). The data storage format of the authentication policy data stored in the local storage space of the authentication execution device may include, but is not limited to, a structured format (e.g., JSON, Protocol Buffers), a database table structure, or a security-enhanced format (e.g., encrypted JSON, signed YAML). The specific format can be determined based on the actual application scenario and is not limited here. In an embodiment of the present application, when a change in the business object information of a business processing device in a business system is detected, new authentication policy data that matches the changed business scenario is generated in real time, and a new policy version identifier is assigned to the authentication policy data, which can ensure that the policy permission data adapts to changes in the business status in real time. In addition, the target authentication policy data and target policy version identifier stored in the permission management device will be synchronously updated to the latest generated version and then sent to the authentication execution device, so that the permission adjustment can take effect as soon as the business needs change. At the same time, the update of the version identifier provides an accurate version comparison basis for subsequent policy synchronization, ensuring that the business processing devices in the business system can obtain the latest permission policy in a timely manner, effectively avoiding unnecessary data transmission, improving resource utilization, and improving the response speed of permission management while ensuring the accuracy of the authentication results, and has high applicability.

[0080] In some feasible implementations, the business processing device in the business system can send an authentication request to the authentication execution device SDK. Here, the cross-process request between the business processing device and the SDK can be implemented through HTTP, remote procedure call, etc. The authentication execution device can receive the above authentication request and obtain the business object information carried in the authentication request based on the above authentication request. For example, the authentication execution device can obtain the role information of the user, and then based on the correspondence between the role and the authority in the authentication policy data, it can verify whether the user's request is legal, and then return the authentication result to the business processing device. The business processing device can further perform business processing based on the authentication result: when the authentication result is passed, the user's request can be responded to normally; when the authentication result is not passed, the user's request is rejected. For details, please refer to the above embodiment and will not be repeated here.

[0081] To facilitate understanding of another process of the authentication method applied to the business system, the embodiment of the present application is combined with Figure 9 See Figure 9 , Figure 9 This is another flowchart of the authentication method applied to the business system provided by the embodiment of the present application, which uses the SDK deployed on the business processing device in the business system and runs independently as the authentication execution device, and uses IAM as the permission management device for example. Figure 9 As shown, the SDK periodically synchronizes the target policy version identifier stored by IAM. Here, the SDK sends a policy version acquisition request carrying the policy version feedback duration to IAM, which can trigger IAM to periodically synchronize the authentication execution device stored in IAM to the SDK based on the policy version feedback duration. The specific policy version feedback duration can be determined according to the actual application scenario and is not restricted here. The SDK compares the target policy version identifier with the policy version identifier of the locally stored authentication policy data to determine whether the target policy version identifier is consistent with the policy version identifier of the locally stored authentication policy data. As shown Figure 9As shown, if the target policy version identifier is inconsistent with the policy version identifier of the locally stored authentication policy data, the SDK can send a policy data synchronization request to IAM to trigger IAM to return the target authentication policy data and the corresponding target policy version identifier to the SDK. The SDK can update the locally stored authentication policy data to the target authentication policy data, and refresh the policy version identifier of the locally stored authentication policy data to the target policy version identifier. If the target policy version identifier is consistent with the policy version identifier of the locally stored authentication policy data, the SDK will continue to synchronize the target policy version identifier stored by IAM at regular intervals and continue to compare, which will not be repeated here. It can be understood that at any time, the business object information can change, and IAM will update the target authentication policy data and refresh the target policy version identifier. Here, the updated target authentication policy data can be applied to the changed business object information. Furthermore, the target authentication policy data and the target policy version identifier can be stored in the local storage space of the IAM. At the same time, the target policy version identifier can be detected to be inconsistent with the policy version identifier of the authentication policy data stored in the SDK when it is synchronized to the SDK next time, thereby allowing the updated target authentication policy data to be synchronized to the SDK. For details, please refer to the aforementioned embodiment and will not be elaborated here.

[0082] In general, the authentication method applied to the business system provided by the embodiment of the present application sends a policy version acquisition request to the authority control device through the authentication execution device. The authority control device can synchronize the target policy version identifier to the authentication execution device. The authentication execution device can compare the target policy version identifier with the policy version identifier of the locally stored authentication policy data to see if they are consistent. If they are inconsistent, a policy data synchronization request is sent to the authority control device to obtain the corresponding target authentication policy data and update the local storage. Through the two-stage process of first verifying the version difference and then synchronizing the policy data, unnecessary data transmission is effectively reduced, network overhead is reduced, and complete policy synchronization is triggered only when version inconsistency is detected. In addition, the authentication execution device makes real-time authentication decisions based on the latest locally stored target authentication policy data, which improves the timeliness and accuracy of the authentication results, and the authentication results are highly credible and applicable. It can be seen that the authentication method provided by the embodiment of the present application can improve user experience and enhance the market competitiveness of products, providing various types of enterprises with more secure, reliable, efficient and high-performance authentication solutions.

[0083] Based on the description of the above-mentioned embodiment of the authentication method, the embodiment of the present application also discloses a permission control device. The permission control device can be applied to Figures 3 to 7 In the authentication method of the embodiment shown, the step of executing the authority control device in the authentication method is used. Here, the authority control device can be the above-mentioned Figures 3 to 7 The authority control device in the embodiment shown, that is, the authority control device can be the above-mentioned Figures 3 to 7 The execution subject of one side of the authentication method in the embodiment shown. Figure 10 , Figure 10 This is a schematic diagram of the structure of the permission control device provided in the embodiment of the present application. Figure 10 As shown, in the embodiment of the present application, the permission management device 10 can run the following units: A request receiving unit 100 is configured to receive, based on a predetermined timing rule, an authentication policy acquisition request sent by an authentication execution device of a business system, wherein the authentication policy acquisition request carries a first policy version identifier, and the first policy version identifier is used to mark the policy version of the first authentication policy data stored by the authentication execution device; The data sending unit 101 is used to send the second authentication policy data to the authentication execution device when the second authentication policy data is obtained and the policy version of the second authentication policy data is different from the policy version of the first authentication policy data, so as to trigger the authentication execution device to respond to the authentication request of the business processing device of the business system based on the second authentication policy data.

[0084] In some feasible implementations, the request receiving unit 100 is configured to: An authentication policy acquisition request sent by an authentication execution device of a business system is received based on a target period, wherein the authentication policy acquisition request carries a valid response time of the authentication policy acquisition request, and the valid response time is less than or equal to one cycle time of the target period.

[0085] In some feasible implementations, the data sending unit 101 is configured to: within the valid response time after receiving the authentication policy acquisition request, obtaining the stored authentication policy data from the local storage space, and comparing the policy version of the stored authentication policy data with the policy version of the first authentication policy data; When the policy version of the stored authentication policy data is different from the policy version of the first authentication policy data, the stored authentication policy data is determined as the second authentication policy data to obtain the second authentication policy data.

[0086] In some feasible implementations, the above-mentioned permission management device 10 further includes: The data update unit 102 is used to generate third authentication policy data applicable to the changed business object information and a third policy version identifier of the above-mentioned third authentication policy data when the business object information of the business processing device of the business system is changed, and update the authentication policy data stored in the above-mentioned local storage space to the above-mentioned third authentication policy data, and update the policy version identifier of the authentication policy data stored in the above-mentioned local storage space to the above-mentioned third policy version identifier; wherein the above-mentioned business object information includes at least one of the business object identifier, the role of the business object or the role authority of the business object.

[0087] In some feasible implementations, the data sending unit 101 is configured to: When, within the valid response time period after receiving the authentication policy acquisition request, the business object information of the business processing device of the business system changes, generating second authentication policy data applicable to the changed business object information and a second policy version identifier of the second authentication policy data, the second policy version identifier being different from the first policy version identifier; Sending the second authentication policy data to the authentication execution device; The business object information includes at least one of a business object identifier, a role of the business object, or a role authority of the business object.

[0088] In some feasible implementations, the data sending unit 101 is further configured to: The authentication policy data stored in the local storage space is updated to the second authentication policy data, and the policy version identifier of the authentication policy data stored in the local storage space is updated to the second policy version identifier.

[0089] Based on the description of the above-mentioned embodiment of the authentication method, the embodiment of the present application also discloses an authentication execution device. The authentication execution device can be applied to Figures 3 to 7 In the authentication method of the embodiment shown, the authentication execution device is used to execute the steps of the authentication method. Here, the authentication execution device can be the above-mentioned Figures 3 to 7 The authentication execution device in the embodiment shown, that is, the authentication execution device can be the above-mentioned Figures 3 to 7 The execution subject of one side of the authentication method in the embodiment shown. Figure 11 , Figure 11 This is a schematic diagram of the structure of the authentication execution device provided in the embodiment of the present application. Figure 11 As shown, in the embodiment of the present application, the authentication execution device 11 can run the following units: The policy request unit 110 is configured to send an authentication policy acquisition request to the permission control device based on a predetermined timing rule, wherein the authentication policy acquisition request carries a first policy version identifier, the first policy version identifier being used to mark the policy version of the first authentication policy data stored by the authentication execution device of the business system, and enabling the permission control device to determine whether to issue second authentication policy data to the authentication execution device based on the first policy version identifier, where the policy version of the second authentication policy data is different from the policy version of the first authentication policy data; A policy updating unit 111 is configured to receive the second authentication policy data issued by the permission control device after the permission control device determines that the second authentication policy data needs to be issued according to the first policy version identifier; The authentication execution unit 112 is used to perform authentication on the business object information carried in the first authentication request based on the second authentication policy data when receiving the first authentication request sent by the business processing device of the above-mentioned business system, and return the authentication result of the above-mentioned business object information to the above-mentioned business processing device.

[0090] In some feasible implementations, the policy request unit 110 is configured to: An authentication policy acquisition request is sent to the permission control device based on the target period, wherein the authentication policy acquisition request carries the valid response time of the authentication policy acquisition request, and the valid response time is less than or equal to one cycle time of the target period, and the cycle time is the interval between any two adjacent authentication policy acquisition requests sent to the permission control device.

[0091] In some feasible implementations, the second authentication policy data is received within the nth period after sending the target authentication policy acquisition request, where n is an integer greater than or equal to 2. After sending the authentication policy acquisition request to the permission control device based on the predetermined timing rule, the authentication execution unit 112 is further configured to: When a second authentication request is received from a business processing device of the business system within the mth cycle, authentication is performed on the business object information carried in the second authentication request based on the authentication policy data stored by the authentication execution device, and the mth cycle is any cycle before the nth cycle.

[0092] In some feasible implementations, the above Figures 3 to 7 The implementation of each step in the authentication method shown can be achieved by Figure 10 or Figure 11 Each unit of the device shown in the figure is executed. For example, Figure 3 In the authentication method shown, steps S301, S304 and S305 can be respectively Figure 11The policy request unit 110, the policy update unit 111 and the authentication execution unit 112 in the authentication execution device 11 shown in FIG. 1 are executed, and steps S302 and S303 can be respectively performed by Figure 10 The request receiving unit 100 and the data sending unit 101 in the shown permission control device 10 are executed. The implementation methods executed by the above units can refer to the implementation methods provided in the various steps of the above embodiments, which will not be repeated here.

[0093] Based on the description of the second embodiment of the above authentication method, the embodiment of the present application also discloses another permission control device. The permission control device can be applied to Figure 8 or Figure 9 In the authentication method of the embodiment shown, the step of executing the authority control device in the authentication method is used. Here, the authority control device can be the above-mentioned Figure 8 or Figure 9 The authority control device in the embodiment shown, that is, the authority control device can be the above-mentioned Figure 8 or Figure 9 The execution subject of one side of the authentication method in the embodiment shown. Figure 12 , Figure 12 This is another structural diagram of the permission control device provided in the embodiment of the present application. Figure 12 As shown, in the embodiment of the present application, the permission management device 12 can run the following units: The request acquisition unit 120 is configured to receive a policy version acquisition request sent by an authentication execution device of a business system; The version sending unit 121 is used to send a target policy version identifier to the authentication execution device, wherein the target policy version identifier is used to mark the policy version of the target authentication policy data stored in the permission control device; The synchronization response unit 122 is configured to send the target authentication policy data to the authentication execution device upon receiving a policy data synchronization request sent by the authentication execution device.

[0094] In some feasible implementations, the permission management device 12 further includes: The information changing unit 123 is configured to generate authentication policy data applicable to the changed business object information and a policy version identifier of the authentication policy data when the business object information of the business processing device of the business system is changed; The information changing unit 123 is further configured to update the target authentication policy data stored in the permission control device to the generated authentication policy data, and update the target policy version identifier to the generated policy version identifier.

[0095] Based on the description of the second embodiment of the above authentication method, the embodiment of the present application also discloses another authentication execution device. The authentication execution device can be applied to Figure 8 or Figure 9 In the authentication method of the embodiment shown, the authentication execution device is used to execute the steps of the authentication method. Here, the authentication execution device can be the above-mentioned Figure 8 or Figure 9 The authentication execution device in the embodiment shown, that is, the authentication execution device can be the above-mentioned Figure 8 or Figure 9 The execution subject of one side of the authentication method in the embodiment shown. Figure 13 , Figure 13 This is another structural diagram of the authentication execution device provided in the embodiment of the present application. Figure 13 As shown, in the embodiment of the present application, the authentication execution device 13 can run the following units: The version request unit 130 is used to send a policy version acquisition request to the permission management device; The version acquisition unit 131 is configured to, upon receiving a target policy version identifier fed back by the permission control device after sending the policy version acquisition request, and if the target policy version identifier is different from the policy version identifier of the locally stored authentication policy data, send a policy data synchronization request to the permission control device to trigger the permission control device to send the target authentication policy data corresponding to the target policy version identifier; The authentication implementation unit 132 is used to update the locally stored authentication policy data to the target authentication policy data when receiving the target authentication policy data fed back by the permission management device, and when receiving the authentication request sent by the business processing device of the business system, perform authentication on the business object information carried in the authentication request based on the target authentication policy data, and return the authentication result of the business object information to the business processing device.

[0096] In some feasible implementations, the above Figure 8 or Figure 9 The implementation of each step in the authentication method shown can be achieved by Figure 12 or Figure 13 Each unit of the device shown in the figure is executed. For example, Figure 8 In the authentication method shown, steps S801, S804 and S806 can be respectively Figure 13 The version request unit 130, the version acquisition unit 131 and the authentication implementation unit 132 in the authentication execution device 13 shown in FIG. 1 are executed, and steps S802, S803 and S805 can be respectively performed by Figure 12The request acquisition unit 120, version sending unit 121 and synchronous response unit 122 in the shown permission control device 12 are executed. The implementation methods executed by the above units can refer to the implementation methods provided in the various steps of the above embodiments, which will not be repeated here.

[0097] In the embodiment of the present application, the above Figure 12 or Figure 13 The various units in the device shown can be individually or all combined into one or several other units to constitute, or one (or some) of the units can be further divided into multiple functionally smaller units to constitute, which can achieve the same operation without affecting the realization of the technical effects of the embodiments of the present application. The above-mentioned units are divided based on logical functions. In actual applications, the functions of one unit can also be implemented by multiple units, or the functions of multiple units can be implemented by one unit. In other feasible implementations of the present application, the above-mentioned device may also include other units. In actual applications, these functions can also be implemented with the assistance of other units, and can be implemented by the collaboration of multiple units, which is not limited here.

[0098] See also Figure 14 , Figure 14 This is a schematic diagram of the structure of the authentication system based on the sidecar proxy mode provided by the embodiment of the present application. Figure 14 The authentication system based on the sidecar proxy mode shown (for the convenience of description, it can be referred to as the authentication system) can include connections such as Figure 10 The authority control device 10 shown and Figure 11 The authentication execution device 11 shown is used to execute the above Figures 3 to 7 The implementation methods provided by each step in the authentication method shown, that is, the above Figures 3 to 7 The implementation of each step in the authentication method shown can be achieved by Figure 14 In the system shown, each unit in the authority control device 10 and the authentication execution device 11 executes. Figure 3 The authentication method shown in the figure can be performed by the authentication execution device side. Figure 14 Each unit in the authentication execution device 11 executes the above Figure 3 The method for controlling the authority of the device side in the authentication method shown can be Figure 14 The implementation methods implemented by the various units in the middle authority control device 10 can refer to the implementation methods provided in the various steps of the above embodiments, and will not be repeated here.

[0099] Optionally, in some feasible implementations, see Figure 15 , Figure 15 This is another structural diagram of the authentication system based on the sidecar proxy mode provided by the embodiment of the present application. Figure 15 The authentication system based on the sidecar proxy mode shown (for the convenience of description, it can be referred to as the authentication system) can include connections such as Figure 12 The authority control device 12 shown and Figure 13 The authentication execution device 13 shown in the figure is used to execute the above Figure 8 or Figure 9 The implementation methods provided by each step in the authentication method shown, that is, the above Figure 8 or Figure 9 The implementation of each step in the authentication method shown can be achieved by Figure 15 The system shown in FIG. 1 is executed by each unit in the authority control device 12 and the authentication execution device 13. For example, the above Figure 8 The authentication method shown in the figure can be performed by the authentication execution device side. Figure 15 Each unit in the authentication execution device 13 executes the above Figure 8 The method for controlling the authority of the device side in the authentication method shown can be Figure 15 The implementation methods implemented by the various units in the middle authority control device 12 can refer to the implementation methods provided in the various steps of the above embodiments, and will not be repeated here.

[0100] In general, the authentication system based on the sidecar proxy model provided by the embodiment of the present application is composed of at least an authentication execution device and a permission management device, which can realize data synchronization and information interaction between the devices on both sides. Through the policy version identification comparison mechanism, authentication policy data synchronization is triggered when the version identification is inconsistent, which can reduce the repeated transmission of data with the same version, reduce the data transmission pressure, and reduce the data synchronization delay after the authentication policy data changes, thereby improving the credibility of the authentication result, and the authentication efficiency is high and the applicability is high. It can be seen that the authentication system based on the sidecar proxy model provided by the embodiment of the present application can improve the user experience and enhance the market competitiveness of the product, providing a safe, reliable, efficient and high-performance authentication solution for various enterprises.

[0101] The present invention also provides a computer-readable storage medium that stores a computer program. The computer program includes program instructions that are executed by a processor to implement Figures 3 to 9 The authentication methods applied to the business system provided in each step are detailed in the above Figures 3 to 9 The implementation of the authentication method applied to the business system provided in each step will not be repeated here.

[0102] The computer-readable storage medium may be an internal storage unit of the authentication execution device or permission management device provided in any of the aforementioned embodiments, such as a hard disk or memory of a computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash memory card, etc. Furthermore, the computer-readable storage medium may include both an internal storage unit and an external storage device of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium may also be used to temporarily store data that has been output or is about to be output.

[0103] The term "comprising" and any variations thereof in the description, claims, and drawings of the embodiments of this application are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to the process, method, apparatus, product, or device.

[0104] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0105] The methods and related devices provided by the embodiments of the present application are described with reference to the method flow charts and / or structural diagrams provided by the embodiments of the present application. Specifically, each process and / or block in the method flow charts and / or structural diagrams, as well as the combination of processes and / or blocks in the flow charts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 Schematic diagram of one or more processes and / or structures Figure 1These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer-readable memory produce a product including the instruction device, which implements the function specified in the process. Figure 1 Schematic diagram of one or more processes and / or structures Figure 1 These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the process. Figure 1 The flow or flows and / or structures illustrate the steps of the functions specified in one block or multiple blocks.

[0106] The above disclosure is only a preferred embodiment of the present application, and certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. An authentication method applied to a business system, characterized in that: include: receiving, based on a predetermined timing rule, an authentication policy acquisition request sent by an authentication execution device of a business system, wherein the authentication policy acquisition request carries a first policy version identifier, and the first policy version identifier is used to mark a policy version of first authentication policy data stored by the authentication execution device; When second authentication policy data is obtained and the policy version of the second authentication policy data is different from the policy version of the first authentication policy data, the second authentication policy data is sent to the authentication execution device to trigger the authentication execution device to respond to the authentication request of the business processing device of the business system based on the second authentication policy data.

2. The method according to claim 1, characterized in that The receiving, based on a predetermined timing rule, an authentication policy acquisition request sent by an authentication execution device of a business system includes: An authentication policy acquisition request sent by an authentication execution device of a business system is received based on a target period, wherein the authentication policy acquisition request carries a valid response time of the authentication policy acquisition request, and the valid response time is less than or equal to one cycle time of the target period.

3. The method according to claim 2, characterized in that The obtaining of the second authentication policy data includes: within the effective response time after receiving the authentication policy acquisition request, obtaining the stored authentication policy data from the local storage space, and comparing the policy version of the stored authentication policy data with the policy version of the first authentication policy data; When the policy version of the stored authentication policy data is different from the policy version of the first authentication policy data, the stored authentication policy data is determined as the second authentication policy data to obtain the second authentication policy data.

4. The method according to claim 3, characterized in that Before receiving the authentication policy acquisition request sent by the authentication execution device of the business system based on the predetermined timing rule, the method further includes: When the business object information of the business processing device of the business system is obtained to have changed, third authentication policy data applicable to the changed business object information and a third policy version identifier of the third authentication policy data are generated, and the authentication policy data stored in the local storage space is updated to the third authentication policy data, and the policy version identifier of the authentication policy data stored in the local storage space is updated to the third policy version identifier; The business object information includes at least one of a business object identifier, a role of the business object, or a role authority of the business object.

5. The method according to claim 2, characterized in that When the second authentication policy data is obtained and the policy version of the second authentication policy data is different from the policy version of the first authentication policy data, sending the second authentication policy data to the authentication execution device includes: When, within the valid response time after receiving the authentication policy acquisition request, the business object information of the business processing device of the business system is changed, generating second authentication policy data applicable to the changed business object information and a second policy version identifier of the second authentication policy data, the second policy version identifier being different from the first policy version identifier; sending the second authentication policy data to the authentication execution device; The business object information includes at least one of a business object identifier, a role of the business object, or a role authority of the business object.

6. The method according to claim 5, characterized in that After generating the second authentication policy data applicable to the changed business object information and the second policy version identifier of the second authentication policy data, the method further includes: The authentication policy data stored in the local storage space is updated to the second authentication policy data, and the policy version identifier of the authentication policy data stored in the local storage space is updated to the second policy version identifier.

7. An authentication method applied to a business system, characterized in that: include: Sending an authentication policy acquisition request to the authority control device based on a predetermined timing rule, wherein the authentication policy acquisition request carries a first policy version identifier, the first policy version identifier being used to mark a policy version of first authentication policy data stored by an authentication execution device of the business system, and enabling the authority control device to determine, based on the first policy version identifier, whether it is necessary to issue second authentication policy data to the authentication execution device, where the policy version of the second authentication policy data is different from the policy version of the first authentication policy data; receiving the second authentication policy data issued by the permission control device after determining that the second authentication policy data needs to be issued according to the first policy version identifier; Upon receiving a first authentication request sent by a service processing device of the service system, authentication is performed on the service object information carried in the first authentication request based on the second authentication policy data, and an authentication result of the service object information is returned to the service processing device.

8. The method according to claim 7, characterized in that The sending of an authentication policy acquisition request to the authority control device based on a predetermined timing rule includes: An authentication policy acquisition request is sent to the authority control device based on a target period, wherein the authentication policy acquisition request carries a valid response time of the authentication policy acquisition request, and the valid response time is less than or equal to one cycle time of the target period, and the cycle time is the interval between any two adjacent authentication policy acquisition requests sent to the authority control device.

9. The method according to claim 8, characterized in that The second authentication policy data is received within the nth period after sending the authentication policy acquisition request, where n is an integer greater than or equal to 2. After sending the authentication policy acquisition request to the authority control device based on the predetermined timing rule, the method further includes: When a second authentication request is received from a business processing device of the business system within the mth cycle, authentication is performed on the business object information carried in the second authentication request based on the authentication policy data stored by the authentication execution device, and the mth cycle is any cycle before the nth cycle.

10. An authentication method applied to a business system, characterized in that: include: Send a policy version acquisition request to the permission management device; After sending the policy version acquisition request, when a target policy version identifier fed back by the permission control device is received, and the target policy version identifier is different from the policy version identifier of the locally stored authentication policy data, a policy data synchronization request is sent to the permission control device to trigger the permission control device to send the target authentication policy data corresponding to the target policy version identifier; When the target authentication policy data fed back by the authority management device is received, the locally stored authentication policy data is updated to the target authentication policy data, and when an authentication request sent by the business processing device of the business system is received, the business object information carried in the authentication request is authenticated based on the target authentication policy data, and the authentication result of the business object information is returned to the business processing device.

11. An authentication method applied to a business system, characterized in that: include: Receive a policy version acquisition request sent by an authentication execution device of a business system; Sending a target policy version identifier to the authentication execution device, wherein the target policy version identifier is used to mark the policy version of the target authentication policy data stored in the permission management device; When receiving the policy data synchronization request sent by the authentication execution device, the target authentication policy data is sent to the authentication execution device.

12. The method according to claim 11, characterized in that The method further comprises: When the business object information of the business processing device of the business system is obtained to be changed, generating authentication policy data applicable to the changed business object information and a policy version identifier of the authentication policy data; The target authentication policy data stored in the authority control device is updated to be the generated authentication policy data, and the target policy version identifier is updated to be the generated policy version identifier.

13. A permission management device, characterized in that: include: a request receiving unit, configured to receive, based on a predetermined timing rule, an authentication policy acquisition request sent by an authentication execution device of a business system, wherein the authentication policy acquisition request carries a first policy version identifier, and the first policy version identifier is used to mark a policy version of the first authentication policy data stored by the authentication execution device; A data sending unit is used to send the second authentication policy data to the authentication execution device when the second authentication policy data is obtained and the policy version of the second authentication policy data is different from the policy version of the first authentication policy data, so as to trigger the authentication execution device to respond to the authentication request of the business processing device of the business system based on the second authentication policy data.

14. An authentication execution device, characterized in that: include: a policy request unit, configured to send an authentication policy acquisition request to the authority control device based on a predetermined timing rule, wherein the authentication policy acquisition request carries a first policy version identifier, the first policy version identifier being used to mark the policy version of first authentication policy data stored by the authentication execution device of the business system, and enabling the authority control device to determine, based on the first policy version identifier, whether to issue second authentication policy data to the authentication execution device, where the policy version of the second authentication policy data is different from the policy version of the first authentication policy data; a policy updating unit, configured to receive the second authentication policy data issued by the permission control device after determining that the second authentication policy data needs to be issued according to the first policy version identifier; An authentication execution unit is used to, upon receiving a first authentication request sent by a business processing device of the business system, authenticate the business object information carried in the first authentication request based on the second authentication policy data, and return the authentication result of the business object information to the business processing device.

15. An authentication execution device, characterized in that: include: A version request unit, used to send a policy version acquisition request to the permission management device; a version acquisition unit, configured to, upon receiving a target policy version identifier fed back by the permission control device after sending the policy version acquisition request, and if the target policy version identifier is different from the policy version identifier of the locally stored authentication policy data, send a policy data synchronization request to the permission control device to trigger the permission control device to send the target authentication policy data corresponding to the target policy version identifier; An authentication implementation unit is used to update the locally stored authentication policy data to the target authentication policy data when receiving the target authentication policy data fed back by the permission management device, and when receiving an authentication request sent by the business processing device of the business system, perform authentication on the business object information carried in the authentication request based on the target authentication policy data, and return the authentication result of the business object information to the business processing device.

16. A permission management device, characterized in that: include: A request acquisition unit, configured to receive a policy version acquisition request sent by an authentication execution device of a business system; A version sending unit, configured to send a target policy version identifier to the authentication execution device, wherein the target policy version identifier is used to mark the policy version of the target authentication policy data stored in the permission management device; The synchronization response unit is configured to send the target authentication policy data to the authentication execution device when receiving the policy data synchronization request sent by the authentication execution device.

17. An authentication system based on a sidecar proxy model, comprising: The rights management device according to claim 13 and the authentication execution device according to claim 14; Alternatively, the authentication execution device as claimed in claim 15 and the permission management device as claimed in claim 16.

18. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program capable of executing the method according to any one of claims 1 to 12.

19. A computer program product, characterized in that The computer program product comprises: a computer program code, and when the computer program code is executed, the method according to any one of claims 1 to 12 can be executed.

Images