Method and system for guaranteeing data security transmission in service cross-domain calling process

Abstract

The invention discloses a method and system for guaranteeing data security transmission in a service cross-domain calling process, and the method comprises the steps: S1, an authentication control program of a first sub-domain sends a request header comprising a user token and an application token and an authentication factor real-time synchronization service strategy to a client which sends a service request, and carries out the global synchronization, the first sub-domain detection and control point performs detection and control point verification, and then performs authentication verification based on the request header; s2, the first sub-domain establishes a connection with a second sub-domain through an encryption channel assembly and obtains a session key and a temporary access token based on the connection, and the client performs data encryption and data packaging based on the session key and the temporary access token, and transmits the data to a second sub-domain detection and control point through the encryption channel assembly; and S3, checking the detection and control point of the second sub-domain, performing authentication checking based on the request header, performing data unpacking and decryption by the second sub-domain, calling a corresponding service according to the service request, and returning a service result.

Description

Technical Field

[0001] The present invention relates to the field of cross - domain data invocation, and specifically to a method and system for ensuring secure data transmission during cross - domain service invocation. Background Art

[0002] With the rapid development of information technology, cross - domain service invocation has become a common requirement in modern distributed systems. Cross - domain service invocation allows applications between different domains or sub - domains to communicate and share resources with each other, which is crucial for building flexible and scalable system architectures. However, cross - domain service invocation also brings challenges in data security and privacy protection. In traditional cross - domain service invocation, data transmission often faces the following problems:

[0003] Authentication and authorization issues: The authentication and authorization mechanisms between different domains may be incompatible, making it difficult to achieve unified management of user authentication and permission control. This may lead to unauthorized access or data leakage.

[0004] Data transmission security issues: During cross - domain data transmission, data may be intercepted or tampered with, especially when using non - encrypted or weakly encrypted communication protocols. This requires the development of more powerful encryption technologies and secure communication protocols to protect data.

[0005] Policy management and synchronization issues: In a distributed environment, policy management and synchronization become complex. Different domains may have different security policies and control measures, and how to effectively synchronize and manage these policies becomes a challenge.

[0006] Terminal device security issues: With the popularization of mobile devices and Internet of Things devices, the security of terminal devices has become an important consideration in cross - domain service invocation. Unsecure terminal devices may become an entry point for attackers to invade the system.

[0007] Compliance and privacy protection issues: Laws and regulations in different regions and countries have different requirements for data privacy and protection. Cross - domain service invocation needs to ensure compliance with these laws and regulations while protecting users' personal privacy.

[0008] To address these challenges, the industry has proposed various solutions and technologies. Although existing cross - domain service invocation technologies have, to a certain extent, solved the problems of data security and privacy protection, there are still some deficiencies:

[0009] Fragmentation of authentication and authorization: Existing authentication and authorization mechanisms are often limited within a single domain, and there is a lack of unified standards and mechanisms for authentication and authorization across domains. As a result, users need to repeat authentication when switching between different domains, increasing the operational complexity for users.

[0010] Insufficient security in data transmission: Although encryption technologies such as HTTPS and TLS / SSL provide basic data transmission security guarantees, in complex network environments, these technologies may not be sufficient to cope with advanced man-in-the-middle attacks and data tampering.

[0011] Complexity of policy management and synchronization: In a multi-domain environment, the management and synchronization of security policies often lack automation and centralization, resulting in low efficiency of policy updates and synchronization and prone to security vulnerabilities.

[0012] Neglect of terminal device security: Existing security solutions often focus on server-side security and insufficiently consider the security of terminal devices, especially in the context of the increasing number of mobile devices and Internet of Things devices.

[0013] Compliance challenges in privacy protection: With the increasing strictness of global data protection regulations, such as the EU's GDPR, existing cross-domain service invocation solutions may be difficult to meet the privacy protection requirements of different regions.

[0014] The security and privacy protection of cross-domain service invocation remains an area of continuous development. With the emergence of new technologies and changes in laws and regulations, it is necessary to continuously update and improve existing security measures to cope with changing security threats. Summary of the Invention

[0015] In view of the technical problems in the prior art, the present application proposes a method for ensuring secure data transmission during cross-domain service invocation, including the following steps:

[0016] S1, The authentication and control program of the first sub-domain sends a request header including a user token and an application token to the client sending the service request. The authentication factor synchronizes the service policy in real time and performs global synchronization. The checkpoint of the first sub-domain performs checkpoint verification, and then performs authentication verification based on the request header;

[0017] S2, The first sub-domain establishes a connection with the second sub-domain through the encryption channel component and obtains a session key and a temporary access token based on the connection. The client encrypts and packets the data based on the session key and the temporary access token, and transmits it to the checkpoint of the second sub-domain through the encryption channel component;

[0018] S3, The checkpoint of the second sub-domain performs checkpoint verification, and then performs authentication verification based on the request header. The second sub-domain unpacks and decrypts the data, invokes the corresponding service according to the service request, and returns the service result.

[0019] Preferably, the real-time synchronization service policy of the authentication factor and the global synchronization specifically include: the first sub-domain authentication factor and the second sub-domain authentication factor achieve real-time synchronization of the authentication service and the permission control service through timed polling, and synchronize with the global authentication factor of the total domain to achieve global synchronization.

[0020] Preferably, the checkpoint verification of the first sub-domain checkpoint specifically includes verifying the validity, expiration date of the user token and the application token, and the security of the terminal device, and determining whether the service request can pass;

[0021] The checkpoint verification of the second sub-domain checkpoint specifically includes verifying the validity, expiration date of the user token and the application token, and the security of the terminal device, determining whether the service request can pass, and determining whether the service request is a request initiated by the second sub-domain. If not, identity verification is performed based on the authentication factor.

[0022] Further preferably, the authentication verification based on the request header specifically includes, based on the request header, performing service verification in the authentication management center, determining whether there is permission to call according to the request url of the request header, and determining whether it is a service within the domain:

[0023] When it is determined that it is a service within the domain, data-level authorization and service-level authorization are performed based on the permission policy service of the authentication factor, and token verification is performed based on the authentication service of the authentication factor;

[0024] When it is determined that it is not a service within the domain, service-level authorization is performed based on the permission policy service of the authentication factor, and token verification is performed based on the authentication service of the authentication factor.

[0025] Preferably, the first sub-domain establishes a connection with the second sub-domain through an encrypted channel component and obtains a session key and a temporary access token based on the connection: the first sub-domain uses the SSL / TLS protocol to establish the encrypted channel component, and the client encrypts the authentication information with the private key of the client and sends the SSL / TLS certificate to the second sub-domain through the encrypted channel component to transmit the public key of the client. The authentication information includes the business system identifier of the client, the time stamp, a random sequence with a fixed 8-bit length, and a digital signature generated based on the SM2 algorithm. After the second sub-domain decrypts the encrypted authentication information with the public key of the client and verifies the digital signature, it creates the temporary access token accessToken and the session key, encrypts them with the public key of the client, and then sends them to the client.

[0026] Further preferably, the client encrypts and packets data based on the session key and the temporary access token, which specifically includes: the client calculates the SM3 hash digest of the request data packet of the service request to obtain the original SM3 hash digest, encrypts the original SM3 hash digest with the private key of the client, then encrypts the request data packet with the session key, generates an original hash value for the request parameters of the service request using a hash function, encrypts the original hash value with the private key of the client to generate a signature value, and packets the identity information corresponding to the service request, the temporary access token accessToken, the request data packet to be transmitted, and the signature value.

[0027] Further preferably, the second subdomain unpacks and decrypts the data, invokes the corresponding service according to the service request, and returns the service result, which specifically includes: the second subdomain unpacks the data, performs identity and permission verification based on the identity information corresponding to the service request and the temporary access token accessToken. After passing the identity and permission verification, the second subdomain decrypts the signature value with the public key of the client to obtain the original hash value, calculates the hash value of the signature value again, and compares it with the original hash value. When the hash value of the signature value is consistent with the original hash value, the second subdomain decrypts the encrypted original SM3 hash digest with the public key of the client, calculates the SM3 hash digest of the request data packet again, and compares it with the original SM3 hash digest for verification. After passing the verification, the second subdomain decrypts the request data packet with the session key, invokes the corresponding service, and returns the service result.

[0028] Further preferably, the identity information includes the business system identifier of the client, the institution code to which the SSL / TLS certificate belongs, and the business transaction number generated by the client based on the service request.

[0029] According to one aspect of the present invention, a system for ensuring secure data transmission during cross-domain service invocation is proposed, including the following modules:

[0030] Service request module: The authentication and control program of the first subdomain sends a request header including a user token and an application token to the client sending the service request. The authentication factor synchronizes the service policy in real time and performs global synchronization. The checkpoint of the first subdomain performs checkpoint verification, and then performs authentication verification based on the request header;

[0031] Data transmission module: The first subdomain establishes a connection with the second subdomain through the encryption channel component and obtains a session key and a temporary access token based on the connection. The client encrypts and packets data based on the session key and the temporary access token, and transmits it to the checkpoint of the second subdomain through the encryption channel component;

[0032] Service call module: The second sub-domain checkpoint performs checkpoint verification, then performs authentication verification based on the request header. The second sub-domain unpacks and decrypts the data, and calls the corresponding service according to the service request and returns the service result.

[0033] According to one aspect of the present invention, a computer program product is provided, on which a computer program is stored. When the computer program is executed by a processor, the method described in any one of the first aspects is implemented.

[0034] The beneficial effects of the present invention are as follows:

[0035] 1. Global authentication factor synchronization: By synchronizing the authentication factors of the first sub-domain and the second sub-domain to the global authentication factor of the total domain, unified authentication and authorization management across domains are achieved, simplifying the user's authentication process and improving the user experience.

[0036] 2. Enhanced data security for encrypted transmission: The present invention also introduces data signature and encrypted channel components, such as SSL / TSL, further enhancing the security of data transmission and effectively defending against man-in-the-middle attacks and data tampering.

[0037] 3. Automation of policy management and synchronization: By means of timed polling, the authentication management, permission policies, and control policies within the domain are synchronously updated to the authentication factor in real time, realizing the automation of policy management and synchronization, and improving the efficiency and security of policy updates.

[0038] 4. Enhancement of terminal device security: The check on the security of the terminal device is added in the checkpoint verification, ensuring the security of the terminal device during the cross-domain service call process and reducing security risks.

[0039] 5. Enhancement of privacy protection compliance: The requirements of global data protection regulations are considered during the design. Through fine-grained permission control and data encryption, the protection of user privacy during the cross-domain service call process is ensured, meeting the compliance requirements of different regions.

[0040] Through these improvement points, a more comprehensive, efficient, and secure solution is provided for ensuring cross-domain data security transmission. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The accompanying drawings are included to provide a further understanding of the embodiments and are incorporated in and constitute a part of this specification. The drawings illustrate the embodiments and, together with the description, are used to explain the principles of the present invention. Other embodiments and many of the intended advantages of the embodiments will be readily apparent as they become better understood by reference to the following detailed description. The elements of the drawings are not necessarily to scale with each other. The same reference numerals refer to corresponding like parts.

[0042] Figure 1 Shows a schematic flowchart of a method for ensuring secure data transmission during cross - domain invocation of services according to the present invention;

[0043] Figure 2 Shows a specific schematic flowchart of secure data transmission during cross - domain invocation of services according to the method of the present invention;

[0044] Figure 3 Shows a schematic flowchart of establishing a cross - domain connection to obtain a session key and a temporary access token according to the method of the present invention;

[0045] Figure 4 Shows a schematic structural diagram of a system for ensuring secure data transmission during cross - domain invocation of services according to the present invention;

[0046] Figure 5 Shows a schematic structural diagram of a computer system of an electronic device suitable for implementing the embodiments of the present application. Detailed implementation manners

[0047] The following further elaborates on the present application with reference to the accompanying drawings and embodiments. It can be understood that the specific embodiments described herein are merely for explaining the relevant invention and not for limiting the invention. Additionally, it should be noted that for ease of description, only parts related to the relevant invention are shown in the drawings.

[0048] It should be noted that, without conflict, the embodiments in the present application and the features in the embodiments can be combined with each other. The following will detail the present application with reference to the drawings and embodiments.

[0049] As Figure 1 shown, the present application proposes a method for ensuring secure data transmission during cross - domain invocation of services, including the following steps:

[0050] S1. The authentication and control program of the first sub - domain sends a request header including a user token and an application token to the client that sends a service request. The authentication factor synchronizes the service policy in real - time and performs global synchronization. The checkpoint of the first sub - domain performs checkpoint verification, and then performs authentication verification based on the request header;

[0051] S2. The first sub - domain establishes a connection with the second sub - domain through an encryption channel component and obtains a session key and a temporary access token based on the connection. The client encrypts and packets the data based on the session key and the temporary access token, and transmits it to the checkpoint of the second sub - domain through the encryption channel component;

[0052] S3, the second subdomain detection point performs detection point verification, and then performs authentication verification based on the request header. The second subdomain unpacks and decrypts the data, calls the corresponding service according to the service request and returns the service result.

[0053] In the first subdomain, when the client initiates a request to the application, the authentication and control program of the first subdomain will issue a user token and an application token to the client and place them in the browser request header for subsequent prosecution, authentication, and permission control.

[0054] The specific meanings of user token and application token are as follows:

[0055] Application token: It is a token issued for an application. Each application will be issued a token. For example, when application A logs in, it will be issued a token of its own. When application B logs in, it will be issued a token of its own. The information of each token records the information of the application, such as the application's permissions.

[0056] User token: It is a token issued to the user, which records the user information, including the current login information, the user's permissions, etc.

[0057] The first subdomain authentication factor and the second subdomain authentication factor realize real-time synchronization authentication service and authority management service through timed polling, and realize full domain synchronization with the global authentication factor of the total domain.

[0058] Among them, authentication factors include portrait authentication, voiceprint authentication, identity management, authentication center, etc. The overall domain contains the credential information, permission information, and authentication information of each subdomain, and distributes this information to the authentication factors of each subdomain, which are then synchronized to the authentication service and permission management service within the domain.

[0059] When the user brings the user token and application token to the inspection point, Figure 2 As shown, the first subdomain (i.e. Figure 2 The A domain in the authentication center will verify the validity, validity period and terminal device security of the user token and the application token to determine whether the service request can be passed. The terminal device refers to the computer device used by the client. The security of the terminal device is verified by installing environmental sensing in the computer, detecting whether the terminal has viruses, and whether the hardware and software of the current environment have crawlers. Comprehensive measurements will generate a score and transmit it to the authentication center.

[0060] After verification by the inspection point, the client will initiate a service request to the service resource gateway. Then, based on the request url in the request header, the resource gateway will convert the service request, including protocol information conversion and message format conversion.

[0061] Next, the client will carry the request header with the application token and user token to the authentication management center for service verification, determine whether the URL of the current request has the permission to be called, and determine whether it is a service within the domain. If it is a service within the domain, data-level authentication, service-level authentication, and token verification are required. Otherwise, only service-level authentication and token verification are performed.

[0062] Among them, service-level authentication means taking the current application token, user token, and authentication factor to the permission center to determine whether the user of the current client can call the service. If the call is not allowed, "no permission to call" will be returned to prevent the service from being called by unauthorized people; data-level authentication means taking the current application token, user token, and authentication factor to the permission center to determine which fields the current user has permission to return, and only the fields with permission can display the data.

[0063] As Figure 3 shown, the first sub-domain establishes a connection with the second sub-domain through the encryption channel component and obtains a session key and a temporary access token based on the connection. Before establishing a service connection, the caller of the client uses its own private key to encrypt and sign the authentication information including the business system identifier, a timestamp accurate to milliseconds (13 digits in total), a random sequence (fixed 8-bit length), and a digital signature generated based on the SM2 algorithm to form a secure authentication credential. The first sub-domain uses the SSL / TLS protocol to establish the encryption channel component, and the client uses the private key of the client to encrypt the authentication information and sends the SSL / TLS certificate to the second sub-domain through the encryption channel component to transmit the public key of the client.

[0064] After receiving the above authentication information, the server of the second sub-domain uses the SST / TTL certificate to decrypt and obtain the public key provided by the client caller to verify the authenticity and integrity of the digital signature.

[0065] Once the authentication process is error-free, a temporary access token accessToken (fixed length of 32 bits) with a validity period of one hour is immediately generated, and it is stored in the buffer together with the session key created specifically for this interaction. Then, accessToken and the session key are fed back and encrypted to the caller through the public key of the client. During this period, the caller can seamlessly connect to the service interface with accessToken and the session key.

[0066] When the client caller wants to start a service request, it first automatically generates a unique business serial number, which is combined with accessToken, the business system identification code of the client, the organization code and the request data packet to be transmitted to form a complete request data body. The client sends a service call request, calculates the SM3 hash digest of the request data packet of the service request to obtain the original SM3 hash digest, and encrypts the original SM3 hash digest using the client's private key. The request data packet is then encrypted using the session key, and the request parameters of the service request are hashed using a hash function to generate an original hash value. The original hash value is encrypted using the client's private key to generate a signature value, and the identity information corresponding to the service request, the temporary access token accessToken, and the request data packet to be transmitted and the signature value are packaged.

[0067] Then, after passing through the encrypted communication component, the second subdomain inspection point verifies the legitimacy and validity period of the user token and application token, as well as the security of the terminal device, to determine whether the request can be approved or rejected. When verifying the token, it is also necessary to determine whether the request is initiated by this domain. If not, the authentication center of the general domain is synchronized for identity verification.

[0068] Subsequently, the service request content is converted through the request URL to the resource gateway, including protocol information conversion and message format conversion.

[0069] Next, based on the request header carrying the application token and user token, determine whether it is a service in this domain. If it is a service in this domain, data-level authentication, service-level authentication and token verification are required. Otherwise, only service-level authentication and token verification are performed.

[0070] The server of the second subdomain (corresponding to Figure 2 In the B domain), based on the accessToken and identity information, the caller's identity and authority are double-checked to ensure legality and compliance. After passing the identity and authority verification, the second subdomain uses the client's public key to decrypt the signature value to obtain the original hash value, and calculates the hash value of the signature value again, and compares it with the original hash value. When the hash value of the signature value is consistent with the original hash value, the second subdomain uses the client's public key to decrypt the encrypted original SM3 hash digest, and calculates the SM3 hash digest of the request data packet again, and compares it with the original SM3 hash digest for verification. After verification, the request data packet is decrypted by the session key, the corresponding service is called and the service result is returned. The digital signature verification is completed with the help of the caller's public key, and the encrypted package is unpacked using the shared session key. Further verify the caller's access rights to the requested service.

[0071] In one embodiment, the identity information includes the business system identifier of the client, the organization code to which the SSL / TLS certificate belongs, and the business transaction number generated by the client based on the service request.

[0072] In the final stage, the invoker obtains the result returned by the server. If necessary, the previously saved session key is used to decrypt and interpret the encrypted data packet carried therein, thus successfully completing a complete service call cycle.

[0073] As Figure 4 shown, according to one aspect of the present invention, a system for ensuring secure data transmission during cross-domain service calls is proposed, including the following modules:

[0074] Service request module 401: The authentication and control program of the first subdomain sends a request header including a user token and an application token to the client that sends the service request. The authentication factor synchronizes the service policy in real time and performs global synchronization. The checkpoint of the first subdomain performs checkpoint verification, and then performs authentication verification based on the request header;

[0075] Data transmission module 402: The first subdomain establishes a connection with the second subdomain through an encryption channel component and obtains a session key and a temporary access token based on the connection. The client encrypts and packets the data based on the session key and the temporary access token, and transmits it to the checkpoint of the second subdomain through the encryption channel component;

[0076] Service call module 403: The checkpoint of the second subdomain performs checkpoint verification, and then performs authentication verification based on the request header. The second subdomain unpacks and decrypts the data, calls the corresponding service according to the service request, and returns the service result.

[0077] Next, refer to Figure 5 , which shows a schematic structural diagram of a computer system 500 of an electronic device suitable for implementing the embodiments of the present application. Figure 5 The electronic device shown is only an example and should not impose any restrictions on the functions and usage scope of the embodiments of the present application.

[0078] As Figure 5 shown, the computer system 500 includes a central processing unit (CPU) 501, which performs various appropriate actions and processes according to the program stored in the read-only memory (ROM) 502 or the program loaded from the storage section 509 into the random access memory (RAM) 504. In the RAM 504, various programs and data required for the operation of the system 500 are also stored. The CPU 501, ROM 502, ROM 503, and RAM 504 are connected to each other through a bus 505. The input / output (I / O) interface 506 is also connected to the bus 505.

[0079] The following components are connected to the I / O interface 506: an input section 507 including a keyboard, a mouse, etc.; an output section 508 including, for example, a liquid crystal display (LCD), etc. and a speaker, etc.; a storage section 509 including a hard disk, etc.; and a communication section 510 including a network interface card such as a LAN card, a modem, etc. The communication section 510 performs communication processing via a network such as the Internet. A drive 511 is also connected to the I / O interface 506 as needed. A removable medium 512 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is mounted on the drive 511 as needed so that a computer program read therefrom is installed into the storage section 509 as needed.

[0080] Specifically, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts are implemented as computer software programs. For example, an embodiment of the present disclosure includes a computer program product that includes a computer program carried on a computer-readable storage medium, the computer program including program codes for performing the methods shown in the flowcharts. In such an embodiment, the computer program is downloaded and installed from a network via the communication section 510, and / or installed from the removable medium 512. When the computer program is executed by a central processing unit (CPU) 501, the above-described functions defined in the method of the present application are executed.

[0081] It should be noted that the computer-readable storage medium of the present application is a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. The computer-readable storage medium is, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the computer-readable storage medium include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, the computer-readable storage medium is any tangible medium that contains or stores a program, and the program is used by or in combination with an instruction execution system, apparatus, or device. In the present application, the computer-readable signal medium includes a data signal propagated in a baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal takes various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer-readable signal medium is also any computer-readable storage medium other than the computer-readable storage medium, and the computer-readable storage medium sends, propagates, or transmits a program for use by or in combination with an instruction execution system, apparatus, or device. The program code contained on the computer-readable storage medium is transmitted by any suitable medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0082] Computer program code for performing the operations of the present application is written in one or more programming languages or combinations thereof. The programming languages include object-oriented programming languages - such as Java, Smalltalk, C++, and also include conventional procedural programming languages - such as the "C" language or similar programming languages. The program code is executed entirely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer is connected to the user's computer through any type of network - including a local area network (LAN) or a wide area network (WAN) - or, connected to an external computer (for example, by using an Internet service provider to connect through the Internet).

[0083] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagram represents a module, a segment of a program, or a part of code that contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks occur in a different order than that marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they sometimes may be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, as well as combinations of blocks in the block diagram and / or flowchart, are implemented by a dedicated hardware-based system for performing the specified functions or operations, or by a combination of dedicated hardware and computer instructions.

[0084] The modules involved in the embodiments described in the present application are implemented in software and also in hardware.

[0085] On the other hand, the present application also provides a computer-readable storage medium, which is included in the electronic device described in the above embodiments; it also exists separately without being assembled into the electronic device. The above computer-readable storage medium carries one or more programs. When the above one or more programs are executed by the electronic device, the electronic device performs the following: S1, the authentication control program in the first subdomain sends a request header including a user token and an application token to the client that sends a service request. The authentication factor synchronizes the service policy in real time and performs global synchronization. The checkpoint in the first subdomain performs checkpoint verification, and then performs authentication verification based on the request header; S2, the client encrypts the service request and transmits it to the checkpoint in the second subdomain through the encryption channel component; S3, the checkpoint in the second subdomain performs checkpoint verification, and then performs authentication verification based on the request header. The second subdomain decrypts the data, invokes the corresponding service according to the service request, and returns the service result.

[0086] The above description is only for the preferred embodiments of the present application and the explanation of the applied technical principles. Those skilled in the art should understand that the scope of the invention involved in the present application is not limited to the technical solutions formed by the specific combination of the above technical features, but also covers other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above inventive concept. For example, technical solutions formed by mutually replacing the above features with (but not limited to) technical features with similar functions disclosed in the present application.

Claims

1. A method for ensuring secure data transmission during cross-domain service invocation, characterized in that: The following steps are involved: S1, the authentication control program of the first subdomain sends a request header including a user token and an application token to the client sending the service request, the authentication factor synchronizes the service policy in real time and performs global synchronization, the first subdomain inspection point performs inspection point verification, and then performs authentication verification based on the request header; S2, the first subdomain establishes a connection with the second subdomain through an encryption channel component and obtains a session key and a temporary access token based on the connection, the client encrypts and packages data based on the session key and the temporary access token, and transmits the data to the second subdomain control point through the encryption channel component; S3, the second subdomain detection point performs detection point verification, and then performs authentication verification based on the request header. The second subdomain unpacks and decrypts the data, calls the corresponding service according to the service request and returns the service result.

2. A method for ensuring secure data transmission during cross-domain service invocation according to claim 1, characterized in that: The authentication factor real-time synchronization service strategy and global synchronization specifically include: the first subdomain authentication factor and the second subdomain authentication factor implement real-time synchronization authentication service and authority management service by means of timed polling, and synchronize with the global authentication factor of the total domain to achieve global synchronization.

3. A method for ensuring data security transmission during cross-domain service invocation according to claim 1, characterized in that: The first subdomain inspection point performs inspection point verification specifically including verifying the validity and validity period of the user token and the application token and the security of the terminal device to determine whether the service request can be passed; The second subdomain control point performs control point verification specifically including verifying the validity and validity period of the user token and the application token and the security of the terminal device to determine whether the service request can be passed, and determine whether the service request is a request initiated by the second subdomain. If not, identity verification is performed based on the authentication factor.

4. A method for ensuring data security transmission during cross-domain service invocation according to claim 2, characterized in that: The authentication verification based on the request header specifically includes: based on the request header, performing service verification at the authentication management center, judging whether there is permission to call according to the request url of the request header, and judging whether it is a service in this domain: When it is determined that the service is in this domain, data-level authentication and service-level authentication are performed based on the authority policy service of the authentication factor, and token verification is performed based on the authentication service of the authentication factor; When it is determined that the service is not in this domain, service-level authentication is performed based on the authority policy service of the authentication factor, and token verification is performed based on the authentication service of the authentication factor.

5. A method for ensuring data security transmission during cross-domain service invocation according to claim 1, characterized in that: The first subdomain establishes a connection with the second subdomain through an encryption channel component and obtains a session key and a temporary access token based on the connection: the first subdomain uses the SSL / TLS protocol to establish the encryption channel component, the client uses the client's private key to encrypt authentication information and sends an SSL / TLS certificate to the second subdomain through the encryption channel component to transmit the client's public key, the authentication information includes the client's business system identifier, timestamp, a random sequence with a fixed 8-bit length, and a digital signature generated based on the SM2 algorithm, the second subdomain decrypts the encrypted authentication information through the client's public key and verifies the digital signature, then creates the temporary access token accessToken and the session key and encrypts them through the client's public key, and then sends them to the client.

6. A method for ensuring secure data transmission during cross-domain service invocation according to claim 5, characterized in that: The client performs data encryption and data packaging based on the session key and the temporary access token, specifically including: the client calculates the SM3 hash digest of the request data packet of the service request to obtain the original SM3 hash digest, and encrypts the original SM3 hash digest by the private key of the client, and then encrypts the request data packet by the session key, and generates an original hash value for the request parameters of the service request using a hash function, encrypts the original hash value using the private key of the client to generate a signature value, and packages the identity information corresponding to the service request, the temporary access token accessToken, and the request data packet to be transmitted and the signature value.

7. A method for ensuring secure data transmission during cross-domain service invocation according to claim 6, characterized in that: The second subdomain unpacks and decrypts the data, calls the corresponding service according to the service request and returns the service result, specifically including: the second subdomain unpacks the data, performs identity and authority verification based on the identity information corresponding to the service request and the temporary access token accessToken, after passing the identity and authority verification, the second subdomain uses the public key of the client to decrypt the signature value to obtain the original hash value, and recalculates the hash value of the signature value and compares it with the original hash value. When the hash value of the signature value is consistent with the original hash value, the second subdomain uses the public key of the client to decrypt the encrypted original SM3 hash digest, and recalculates the SM3 hash digest of the request data packet, compares it with the original SM3 hash digest for verification, and after verification, decrypts the request data packet using the session key, calls the corresponding service and returns the service result.

8. A method for ensuring secure data transmission during cross-domain service invocation according to claim 6 or 7, characterized in that: The identity information includes the client's business system identifier, the agency code of the SSL / TLS certificate, and the business serial number generated by the client based on the service request.

9. A system for ensuring secure data transmission during cross-domain service calls, characterized in that: Includes the following modules: Service request module: the authentication control program of the first subdomain sends a request header including a user token and an application token to the client sending the service request, the authentication factor synchronizes the service policy in real time and performs global synchronization, the first subdomain inspection point performs inspection point verification, and then performs authentication verification based on the request header; Data transmission module: the first subdomain establishes a connection with the second subdomain through an encryption channel component and obtains a session key and a temporary access token based on the connection, the client encrypts and packages data based on the session key and the temporary access token, and transmits the data to the second subdomain inspection point through the encryption channel component; Service calling module: The second subdomain detection point performs detection point verification, and then performs authentication verification based on the request header. The second subdomain unpacks and decrypts data, calls the corresponding service according to the service request and returns the service result.

10. A computer program product having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method according to any one of claims 1 to 8.

Images