Single sign-on method based on flow interception and voucher injection

Abstract

The invention discloses a single sign-on method and system based on flow interception and credential injection, and the method comprises the steps: a user completes UKey authentication through a gateway client, a gateway generates a session bound with the client and stores the session in a Redis cluster, and a dynamic TTL mechanism renews the session according to the operation of the user; when a user accesses an application system, a gateway captures traffic through a kernel layer, and a quintuple rule and a Bloom filter are adopted to intercept malicious requests; for a logged-in user, after the gateway queries the session state, an encrypted user certificate is called and a signature is added, and a request header is injected by a zero-copy technology and then forwarded to an application server. The system comprises a gateway client, an authentication gateway, a database and an application server. According to the invention, through a cryptographic algorithm, hardware-level key management and kernel layer flow optimization, the problems of complex integration, low security and performance bottleneck of a traditional single sign-on system are solved, and zero transformation access, microsecond-level delay and financial-level security compliance are realized.

Description

Technical Field

[0001] The present invention relates to the field of computer network security, and particularly to a single sign-on method for intercepting traffic and injecting user credentials through an authentication gateway. Background Art

[0002] In existing network applications, users usually need to log in separately in multiple application systems, which not only increases the operation complexity of users, but also may lead to the leakage of user credentials. The single sign-on technology aims to solve this problem and allows users to access other associated application systems after logging in to a single authentication system. However, existing single sign-on systems often rely on specific authentication protocols and complex integration work, which limits their versatility and flexibility in different application systems.

[0003] The prior art, such as publication number: CN107070880A, discloses a single sign-on method and system, an authentication center server. The method is applied to an authentication center server and includes: receiving a request for applying for a token sent by a system initiating a login request; obtaining user information corresponding to the request for applying for a token; generating a token according to the request for applying for a token; saving the authentication information and user information of the token; sending the token to the system initiating the login request so that the system initiating the login request sends the token to the system to be logged in; receiving the token sent by the system to be logged in; verifying the token sent by the system to be logged in according to the saved authentication information of the token. When the token passes the verification, allowing the user to log in to the system to be logged in and sending the user information to the system to be logged in so that the system to be logged in creates a user session of the user according to the user information. The present invention can improve the security of single sign-on.

[0004] Existing single sign-on technologies include the following: one is Cookie-based SSO, which is simple and does not require an additional server, but has security risks (XSS) and cross-domain limitations; the second is Token-based SSO, which has high security and can cross domains, but is complex to implement and requires maintaining the token state; the third is based on standard protocols such as CAS, etc., which requires an authentication server and increases additional hardware costs.

[0005] The main disadvantages of existing single sign-on technologies are: one is that traditional systems (such as old applications based on form login) need to develop additional adaptation logic to access SSO, increasing the transformation cost; the second is that an independent authentication server needs to be deployed and verification logic needs to be developed, which is costly for small and medium-sized enterprises. Summary of the Invention

[0006] The purpose of the present invention is to provide a single sign-on method based on traffic interception and credential injection, which intercepts user traffic through an authentication gateway and automatically injects user credentials when a login request is detected, thereby realizing a single sign-on function without the user having to manually enter credentials.

[0007] To achieve the above object, the present invention discloses a single sign-on method based on traffic interception and credential injection, which is characterized by comprising the following steps:

[0008] Step 1: The user enters the user credentials through the gateway client and initiates a login request to the gateway. The user credentials include UKey authentication:

[0009] The user inserts the UKey and verifies the PIN code. The gateway client generates a random number RA, uses the UKey private key to sign the RA and the random number RB generated by the gateway through the SM2 algorithm, generates Token data, and sends verification data containing the UKey public key certificate to the gateway.

[0010] After the gateway verifies the validity of the signature and the random number RB matches, it marks the user as logged in;

[0011] Step 2: The gateway stores the session information in the Redis cluster. The session ID is generated by combining the client IP address, MAC address and timestamp through the HMAC-SM3 algorithm. The session data includes IP, MAC, UserID, last access time and dynamic TTL. The dynamic TTL is renewed based on user operations.

[0012] Step 3: The user initiates an application system access request through the browser. The gateway captures the original data frame through the Linux kernel layer and uses the five-tuple filtering rules and Bloom filter to intercept malicious IP traffic.

[0013] Step 4: The gateway extracts the source and destination addresses of the request, generates a query key, and queries the user session status through Redis. If the user is logged in and the TTL is valid, the gateway obtains the master key from the HSM, encrypts the user credentials using the SM4-CBC mode to generate a token, appends an HMAC-SM3 signature, injects it into the request header, and forwards it to the application server through kernel-mode zero-copy.

[0014] Step 5: The application server decrypts and verifies the token signature, returns the resource after successful verification, and the user accesses the application system through the gateway.

[0015] Preferably, the Token data format of the UKey authentication in step 1 is RA||RB||A||SignData, wherein A is the UKey unique identifier, SignData is the SM2 signature value, and the verification data includes the UKey public key certificate CertA.

[0016] Preferably, in step 3, the five-tuple filtering rule includes: the protocol type is TCP, the source address, the destination address, the source port, and the destination port are 80 or 443.

[0017] Preferably, in step 4, the zero-copy forwarding is implemented through the Linux kernel AF_XDP framework, and the throughput calculation formula is: throughput (pps) = network card bandwidth (bps) / (packet length (bits) × 8).

[0018] Preferably, when the application server verifies the token in step 5, it uses the public key in the HSM to decrypt and verify the HMAC-SM3 signature, and verifies the validity of the timestamp; the session expiration handling includes: the Redis expiration event triggers a callback to delete the session cache and returns a 401 Unauthorized status code to the client.

[0019] The present invention also discloses a single sign-on system based on traffic interception and credential injection, which is characterized by including:

[0020] Gateway client: configured to receive the UKey inserted by the user, generate Token data containing the SM2 signature after verifying the PIN code, and initiate a login request to the authentication gateway;

[0021] The authentication gateway includes the following modules:

[0022] Authentication module: verifies the matching of the UKey public key certificate, the SM2 signature, and the random number, and marks the user login status;

[0023] Session management module: uses a Redis cluster to store session information, the session ID is generated through the HMAC-SM3 algorithm, binds the client IP and MAC address, and the dynamic TTL is renewed by user operations;

[0024] Traffic interception module: integrates the PF_PACKET socket packet capture component at the Linux kernel layer, configures the five-tuple filtering rule and the Bloom filter (k = 5, m = 8 × 10^6 bits) to intercept malicious traffic;

[0025] Credential injection module: obtains the user credentials by querying the key `SM3(source address || destination address)`, calls the HSM hardware to encrypt and generate a token using SM4-CBC, and injects it into the request header after attaching the HMAC-SM3 signature;

[0026] Database: stores session information and the host mapping table, and the host mapping table associates the Host header of the application system with the credential storage key;

[0027] Application server: verifies the decrypted token signature and returns the resource to the gateway;

[0028] Among them, the authentication gateway is configured to forward the request for injecting credentials to the application server through the kernel state zero-copy technology.

[0029] Preferably, when the application server verifies the token, it uses the public key in the HSM to decrypt and verify the HMAC-SM3 signature, and verifies the validity of the timestamp.

[0030] Preferably, when the session management module detects session expiration, it clears the data through the Redis expiration event callback and returns a 401 status code to the client.

[0031] Preferably, the misjudgment rate calculation formula of the Bloom filter is: ∈=(1 - e^(-k·n / m))^k; where n = 10^6, m = 8×10^6, and when k = 5, the misjudgment rate ∈≈0.022%.

[0032] The present invention also discloses a non-volatile storage medium, characterized in that the non-volatile storage medium includes a stored program, wherein when the program runs, it controls the device where the non-volatile storage medium is located to execute the above method.

[0033] The present invention also discloses a terminal device, characterized in that the terminal device includes: a processor, a memory, a communication interface, and a bus; the processor, the memory, and the communication interface are connected through the bus and complete communication with each other; the memory stores executable program code; the processor runs the program corresponding to the executable program code by reading the executable program code stored in the memory to execute the above method.

[0034] Beneficial effects

[0035] Based on the single sign-on model solution of traffic interception and credential injection, the present invention realizes the single sign-on and secure access control of users through the collaborative work of each component, improving the security of the system and the user experience. Brief description of the drawings

[0036] Figure 1 It is a schematic diagram of the single sign-on structure based on traffic interception and credential injection of the present invention;

[0037] Figure 2 It is a flowchart of the single sign-on method based on traffic interception and credential injection of the present invention;

[0038] Figure 3 It is a schematic diagram of the process of logging in using a UKEY;

[0039] Figure 4 It is a schematic diagram of the session storage mechanism process of the present invention;

[0040] Figure 5A schematic diagram of the process of the gateway intercepting the traffic requested by the application;

[0041] Figure 6 A flow chart showing the process of the gateway querying the database for user credentials and login status through the source address and destination address of the access request. DETAILED DESCRIPTION

[0042] The present invention is further described below in conjunction with the accompanying drawings and embodiments. The embodiments of the present invention include but are not limited to the following embodiments.

[0043] like Figure 1 As shown, the present invention discloses a single sign-on method based on traffic interception and credential injection, comprising the following steps:

[0044] Step 1: The user enters the user credentials through the gateway client and initiates a login request to the gateway. The user credentials include UKey authentication. The specific process is as follows: the user inserts the UKey and verifies the PIN code, the gateway client generates a random number RA, uses the UKey private key to sign RA and the random number RB generated by the gateway through the SM2 algorithm, generates Token data RA||RB||UKey identification||signature, and sends verification data containing the UKey public key certificate to the gateway; after the gateway verifies the validity of the signature and the match of the random number RB, it marks the user as logged in;

[0045] The process of logging in using UKEY is as follows Figure 3 As shown, the process description:

[0046] (1) The user inserts the USBKEY into the gateway client, enters and verifies the PIN code; enters and verifies the password

[0047] (2) The gateway client initiates an authentication request to the gateway;

[0048] (3) The gateway generates and returns a random number RB;

[0049] (4) The gateway client generates a random number RA, and uses the private key of the role authentication key pair to generate signature data SignData = Sign(RA||RB) through the SM2 algorithm, and assembles token data Token = RA||RB||A||SignData, where A is the unique identifier of the administrator USB KEY;

[0050] (5) The client sends verification data ValidData=CertA||Token to the gateway, where CertA is the public key certificate of the role authentication key pair in the USB KEY.

[0051] After the gateway receives the verification information ValidData, it first verifies the validity of CertA, then verifies whether the signature value SignData is correct, and finally compares whether the transmitted random number RB is equal to the local RB.

[0052] (7) The gateway compares the CertA information with the user information reserved in the system to find the corresponding identity information, obtains the user's permissions and marks the login status.

[0053] Step 2: The gateway stores the session information in the Redis cluster. The session ID is generated by the HMAC-SM3 algorithm in combination with the client IP address, MAC address, and timestamp. The session data includes IP, MAC, UserID, the last access time, and a dynamic TTL. The dynamic TTL is renewed according to user operations.

[0054] The session storage mechanism is as follows: The gateway uses Redis to save the session information, and the session ID is bound to the user IP and MAC address. The session timeout mechanism is implemented through TTL (Time-To-Live): TTL = t current +Δ texpire , if the user does not operate for more than the threshold (such as 30 minutes), the session will automatically expire. The specific process is as Figure 4 shown.

[0055] (1) In the session creation phase, a session ID is generated. The HMAC-SM3 algorithm is used to generate a unique ID in combination with the client fingerprint. SID = HMAC-SM3(IP||MAC||timestamp, master key). Compared with the traditional UUID, it avoids the risk of pseudo-random number collision and is strongly bound to the client hardware fingerprint to prevent session forgery.

[0056] The formula for generating the session ID is: ID = HMAC-SM3(IP||MAC||timestamp, master key).

[0057] (2) Bind the client information. The data structure is as follows: Store fields such as IP, MAC, UserID, and the last access time. The json representation is as follows:

[0058]

[0059] Compared with pure UserID binding: IP / MAC dual verification can defend against session hijacking.

[0060] (3) Store the session information in the Redis cluster. Compared with local memory storage: It supports distributed high availability, and the session data is automatically migrated in case of node failure.

[0061] (4) During the session maintenance phase, dynamic TTL updates use the heartbeat mechanism: Each user operation triggers a TTL reset. Compare with the fixed TTL: Dynamically extend the active session lifecycle (e.g., renew for 15 minutes each time an operation is performed), reducing the occupation of invalid memory.

[0062] (5) The session expiration handling method is automatic cleaning: Redis expiration events trigger callbacks. Subsequent operations: Delete the gateway local session cache, send 401 Unauthorized to the client, and force re-authentication.

[0063] Using this solution compared with traditional solutions (such as Tomcat Session) has the following benefits: First, the storage architecture uses Redis Cluster sharding, which supports horizontal expansion. The traditional solution uses single-node memory storage without scalability. Second, for security protection, IP / MAC binding plus hardware encryption is used. The traditional solution only uses Cookie signing and is vulnerable to man-in-the-middle attacks. Third, when managing TTL, this solution uses dynamic TTL renewal, increasing resource utilization by 30%. The traditional solution uses fixed timeouts, which may expire prematurely or occupy memory for a long time. Fourth, in terms of compliance, this solution uses national cryptographic algorithms SM2 / 3 / 4, while the traditional solution relies on non-national cryptographic algorithms (such as SHA-256, AES, RSA, etc.). Using this solution can meet the mandatory compliance requirements in the financial / government affairs fields.

[0064] Step 3: The user initiates an application system access request through the browser. The gateway captures the original data frame through the PF_PACKET socket in the Linux kernel layer, and uses the five-tuple filtering rule (protocol type is TCP, destination port is 80 or 443) and Bloom filter to intercept malicious IP traffic. The Bloom filter is configured with the number of hash functions k = 5 and the length of the bit array m = 8×10^6 bits.

[0065] The user initiates a request to log in to the application system through the browser, and the gateway intercepts the traffic of the application request. For the specific process, see Figure 5 as shown below:

[0066] (1) Traffic capture and preliminary filtering. Packet capture at the kernel layer (libpcap). Technical principle: Use the Linux PF_PACKET socket to capture the original frame at the data link layer (L2), bypass the kernel protocol stack, and achieve zero-copy packet capture. The packet capture efficiency formula is as follows:

[0067]

[0068] Under a 1Gbps network card, when the packet length is 1500 bytes, the theoretical maximum throughput ≈ 812,740 bps.

[0069] (2) Five-tuple filtering rule. The interception conditions are as follows:

[0070]

[0071] P proto = TCP: The interception protocol is the TCP protocol, which is used to filter the UDP protocol P dport Indicates that the port numbers to be monitored include port 80 for http and port 443 for https. The optimization methods are as follows: Use bytecode precompiled filtering rules to offload the filtering logic to the network card hardware and reduce the CPU occupancy rate.

[0072] (3) Malicious IP interception (Bloom filter), the false positive rate formula is as follows:

[0073]

[0074] Among them:

[0075] m: The length of the bit array (bits)

[0076] n: The number of elements

[0077] k: The number of hash functions. Reference example, when n = 10 6 , m = 8×10 6 , k = 5, ∈≈0.00022 (0.022%).

[0078] (4) The dynamic update mechanism uses the blacklist synchronization method. The following is the pseudo code implementation of the Bloom filter:

[0079]

[0080]

[0081] The Bloom filter realizes efficient element existence detection through a binary bit array and multiple hash functions: When adding an element, map it through all hash functions to multiple positions in the bit array and set them to 1; when querying, if all corresponding positions are 1, it is considered that the element may exist (there may be false positives), and if any position is 0, it must not exist. It achieves fast judgment at a very small space cost, but cannot delete elements and the false positive rate increases with the increase of elements. It is necessary to balance performance and accuracy by adjusting the length of the bit array and the number of hash functions.

[0082] The false positive rate calculation formula of the Bloom filter is: ∈ = (1 - e^(-k·n / m))^k; where n = 10^6, m = 8×10^6, and when k = 5, the false positive rate ∈≈0.022%.

[0083] (5) TCP stream reassembly and HTTP parsing, kernel buffer management, use the sliding window protocol to solve the out-of-order packet problem; HTTP protocol parsing uses regular expression matching: as follows:

[0084] Host header extraction: ^Host:\s*([\w.-]+)

[0085] Function: Used to extract the value of the Host field from the HTTP request header (such as Host: example.com).

[0086] Structural analysis:

[0087] ^Host:^ matches the start of the line to ensure that the matched line starts with Host:.

[0088] Precisely match the string Host: (case-sensitive).

[0089] \s*: \s matches any whitespace character (space, tab, etc.), and * means zero or more matches, allowing any amount of whitespace or no whitespace between Host: and the value.

[0090] ([\w.-]+): The [...] character group matches any character within it. \w matches letters, digits, and underscores ([a-zA-Z0-9_]),. and - match the literal dot and hyphen, and + means one or more matches to ensure at least one character. Use the capture group () to extract the result.

[0091] Examples are as follows:

[0092] Input: Host: www.example.com

[0093] Extraction result: www.example.com

[0094] URI path extraction: ^(GET|POST)\s+([^\s?]+)

[0095] Function: Used to extract the request method (GET / POST) and the URI path (excluding query parameters) from the HTTP request line.

[0096] Structural analysis:

[0097] ^(GET|POST): ^ matches the start of the line to ensure matching from the beginning of the request line. (GET|POST) matches GET or POST (case-sensitive), and other HTTP methods (such as PUT / DELETE) will not be matched.

[0098] \s+: \s matches any whitespace character, and + means one or more matches, requiring at least one whitespace character between the method name and the URI path.

[0099] ([^\s?]+): [^\s?] matches any character that is not a whitespace character and not a question mark (?), and + means one or more matches until a whitespace or a? (query parameter start symbol) is encountered.

[0100] Use a capture group () to extract the URI path.

[0101] Example

[0102] Input: GET / path / to / resource?param=1 HTTP / 1.1

[0103] Extraction result: Method GET, path / path / to / resource.

[0104] Using this solution compared with the traditional solution (such as iptables + Nginx) has the following benefits: First, the interception layer is at the kernel layer (L2 / L3) and zero-copy processing can be performed. The traditional solution requires multiple memory copies in the user-state proxy (L7), and the latency is reduced by 90% (from 1ms to 0.1ms); Second, the IP filtering efficiency. The Bloom filter occupies 8MB of memory (10^6 IPs), while the traditional solution uses a hash table and requires 800MB, saving 99% of memory; Third, the dynamic scalability. This solution can perform program hot-loading of new rules, while the traditional solution requires restarting the service to load the configuration, and the rule update latency is reduced from the minute level to the millisecond level.

[0105] Step 4: The gateway extracts the source address and destination address of the request, generates a query key SM3 (source address || destination address), and queries the user session status through Redis; if the user is logged in and the TTL is valid, obtain the master key from the HSM, encrypt the user credentials using the SM4-CBC mode to generate a token, append the HMAC-SM3 signature, and inject it into the request header X-App-Credential: Bearer <Base64(token || signature || timestamp)>, and forward it to the application server through kernel-state zero-copy.

[0106] The gateway queries the user credentials and login status in the database by accessing the source address and destination address of the request. If the user is not logged in, the request information is discarded. If the user is already logged in, the user's identity credentials are added to the request, and the request is forwarded to the application server. For the specific process, see the appendix Figure 6 As shown, the process is as follows:

[0107] (1) The session status verification method is implemented using source address resolution and database query technology to extract the client IP and destination Host header, and combine the query key: Key = SM3(Source_IP||Destination_Host). Use the Redis query instruction: HMGET session:{Key} UserID Status TTL. Status determination: If Status = "active" and TTL > 0, the user is logged in; otherwise, it is considered not logged in.

[0108] (2) Credential mapping and encryption. The data table structure for querying application credentials is as follows:

[0109] The following is a typical example of application credentials in JSON format:

[0110]

[0111] The Redis query logic is as follows:

[0112] -- Obtain the AppID and DB_Key based on the Host header

[0113] local app_info = redis.call("HGETALL", "host_mapping:"..Host)

[0114] local credential = redis.call("HGET", app_info["DB_Key"], UserID)

[0115] The session token generation and encryption are as follows. Use the SM4-CTR mode for encryption. The formula is as follows:

[0116] Token = SM4-CTR(Key master , UserID∥AppID∥Nonce), where Key master is the master key hosted by the Hardware Security Module (HSM). Use HMAC-SM3 for integrity verification. The verification formula is as follows: Signature = HMAC-SM3(Key sign , Token∥Timestamp), where Key sign is the integrity protection key of the Hardware Security Module (HSM).

[0117] Token generation logic analysis (Token = SM4-CTR(Keymaster, UserID ∥ AppID ∥ Nonce)). Data concatenation: UserID ∥ AppID ∥ Nonce means concatenating the user ID, application ID, and nonce in sequence into a binary data stream as the plaintext input for encryption; Encryption mode and key, SM4-CTR: Adopt the counter mode (CTR) of the national cryptographic SM4 algorithm. It is necessary to ensure that the Nonce (nonce) is random enough and non-repeating, which is used to generate the key stream for exclusive OR operation with the plaintext. Keymaster: The master key hosted by the hardware security module (HSM) is used for SM4 encryption to ensure the secure storage and invocation of the key.

[0118] Signature logic analysis (Signature = HMAC-SM3(Key sign , Token ∥ Timestamp)). Data concatenation: Token ∥ Timestamp means concatenating the encrypted token and the timestamp as the input data for signature. Signature algorithm and key: HMAC-SM3: Message authentication code based on the national cryptographic SM3 hash algorithm, which is used to verify data integrity and authenticity. Keysign: The integrity protection private key hosted by the HSM.

[0119] Function of timestamp: Prevent replay attacks. It is necessary to ensure the clock synchronization between the client and the server.

[0120] (3) Request header injection and zero-copy forwarding. Example of injected fields:

[0121] The following is a typical content example of an http request header:

[0122] GET / resource HTTP / 1.1 / / Protocol header, indicating that the protocol is http1.1 version

[0123] Host: api.example.com / / Target application address

[0124] X-App-Credential: Bearer <Base64(Credential)> / / Standard OAuth header stores the core token

[0125] The content encoded by Base64(Credential) is Token||Signature||Timestamp.

[0126] Among them, Token is the core token, Signature is the signature verification information, and Timestamp represents the timestamp information

[0127] (4) Zero-copy forwarding optimization, using the kernel to directly complete the data transfer from the network card to the Socket in the kernel state, without user-space memory copying. The throughput formula is as follows:

[0128]

[0129] When Payload_Size = 1KB, Encryption_Time = 1μs, Network_Latency = 50μs, the theoretical throughput of a single core ≈ 19,607 QPS.

[0130] Nworkers (Number of worker threads):

[0131] Definition: This refers to the number of worker threads running simultaneously in the system. Worker threads are responsible for tasks such as handling packet transmission and encryption.

[0132] Impact: The more worker threads, the higher the theoretical throughput of the system should be, but it is also limited by other factors (such as network latency and encryption time).

[0133] Payload_Size (Payload size):

[0134] Definition: The amount of data carried by each worker thread in one transmission, in bytes (Byte). In the figure, the payload size is set to 1KB (i.e., 1024 bytes).

[0135] Impact: The payload size directly affects the amount of information that can be carried in each transmission. A larger payload size can improve transmission efficiency, but it may also increase network latency and encryption time.

[0136] Network_Latency (Network latency):

[0137] Definition: The time required for a data packet to be transmitted from the sender to the receiver, in microseconds (μs). Network latency includes multiple aspects such as transmission latency, propagation latency, and processing latency.

[0138] Impact: Network latency is one of the important factors limiting the system throughput. Higher network latency will reduce the system throughput because it takes more time to complete the transmission of data packets.

[0139] Encryption_Time (Encryption time):

[0140] Definition: The time required to encrypt a data packet, in microseconds (μs). The encryption time depends on the efficiency of the encryption algorithm and the performance of the hardware.

[0141] Impact: Encryption time is another important factor affecting system throughput. Longer encryption time will reduce the number of valid requests that the system can process per second, thus reducing throughput.

[0142] In summary, these parameters together determine the system throughput. By optimizing these parameters (such as increasing the number of worker threads, selecting an appropriate payload size, reducing network latency and encryption time, etc.), the performance of the system can be improved.

[0143] The following are the gains of using this solution compared with traditional solutions (such as Nginx reverse proxy): First, the credential management uses dynamic key derivation to prevent key reuse, while the traditional solution uses a static API Key, which is prone to leakage, resulting in a significant improvement in security; Second, the SM4 encryption uses a dedicated hardware module for acceleration, which is faster and more secure than the traditional software AES encryption; Third, the forwarding efficiency uses the zero-copy method, which has higher performance than the traditional user-state buffer copy; Fourth, the key management uses HSM hardware to isolate the master key, while the traditional method stores the key in a file, which has a risk of leakage.

[0144] Step 5: The application server decrypts and verifies the token signature. After successful verification, it returns the resource, and the user accesses the application system through the gateway.

[0145] The application server verifies the user identity information. If the verification is successful, it obtains the relevant application resources and returns them to the user through the gateway for use. Subsequently, the user can normally access the application.

[0146] The present invention discloses a single sign-on method based on traffic interception and credential injection. The method intercepts user traffic through an authentication gateway, parses and identifies login requests, automatically injects user credentials, and simulates the user to initiate a login request, realizing single sign-on without the need for the user to manually input credentials, improving the user experience and security.

[0147] The above shows and describes the basic principles, main features and advantages of the present invention. Those skilled in the art of this industry should understand that the present invention is not limited by the above embodiments. What is described in the above embodiments and the specification is only the principle of the present invention. Without departing from the spirit and scope of the present invention, the present invention will have various changes and improvements, and these changes and improvements all fall within the scope of the present invention claimed. The scope of protection required by the present invention is defined by the appended claims and their equivalents.

Claims

1. A single sign-on method based on traffic interception and credential injection, characterized in that: The following steps are involved: Step 1: The user enters the user credentials through the gateway client and initiates a login request to the gateway. The user credentials include UKey authentication: The user inserts the UKey and verifies the PIN code. The gateway client generates a random number RA, uses the UKey private key to sign the RA and the random number RB generated by the gateway through the SM2 algorithm, generates Token data, and sends verification data containing the UKey public key certificate to the gateway. After the gateway verifies the validity of the signature and the random number RB matches, it marks the user as logged in; Step 2: The gateway stores the session information in the Redis cluster. The session ID is generated by combining the client IP address, MAC address and timestamp through the HMAC-SM3 algorithm. The session data includes IP, MAC, UserID, last access time and dynamic TTL. The dynamic TTL is renewed based on user operations. Step 3: The user initiates an application system access request through the browser. The gateway captures the original data frame through the Linux kernel layer and uses five-tuple filtering rules and Bloom filters to intercept malicious IP traffic. Step 4: The gateway extracts the source address and destination address of the request, generates a query key, and queries the user session status through Redis; If the user has logged in and the TTL is valid, the master key is obtained from the HSM, the user credentials are encrypted using the SM4-CBC mode to generate a token, an HMAC-SM3 signature is added and injected into the request header, and the token is forwarded to the application server via kernel-mode zero copy. Step 5: The application server decrypts and verifies the token signature, returns the resource after successful verification, and the user accesses the application system through the gateway.

2. The method according to claim 1, characterized in that The Token data format of UKey authentication in step 1 is RA||RB||A||SignData, where A is the UKey unique identifier, SignData is the SM2 signature value, and the verification data includes the UKey public key certificate CertA.

3. The method according to claim 1, characterized in that The five-tuple filtering rules in step 3 include: the protocol type is TCP, the source address, the destination address, the source port and the destination port are 80 or 443.

4. The method according to claim 1, characterized in that In step 4, zero-copy forwarding is implemented through the Linux kernel AF_XDP framework, and the throughput calculation formula is: throughput (pps) = network card bandwidth (bps) / (packet length (bits)×8).

5. The method according to claim 1, characterized in that When the application server verifies the token in step 5, it uses the public key in the HSM to decrypt and verify the HMAC-SM3 signature to verify the validity of the timestamp; The session invalidation process includes: a Redis expiration event triggers a callback to delete the session cache, and returns a 401 Unauthorized status code to the client.

6. A single sign-on system based on traffic interception and credential injection, characterized in that: include: Gateway client: configured to receive the UKey inserted by the user, generate Token data containing the SM2 signature after verifying the PIN code, and initiate a login request to the authentication gateway; The authentication gateway includes the following modules: Authentication module: Verify UKey public key certificate, SM2 signature and random number matching, and mark user login status; Session management module: Redis cluster is used to store session information. The session ID is generated by HMAC-SM3 algorithm and bound to the client IP and MAC address. Dynamic TTL is triggered by user operation to renew the session. Traffic interception module: Integrates the PF_PACKET socket packet capture component of the Linux kernel layer, configures five-tuple filtering rules and Bloom filters to intercept malicious traffic; Credential injection module: obtains user credentials through query keys, calls HSM hardware to generate tokens using SM4-CBC encryption, appends HMAC-SM3 signatures, and injects them into request headers; Database: stores session information and host mapping table, which associates the Host header of the application system with the credential storage key; Application server: Verifies the decrypted token signature and returns the resource to the gateway; The authentication gateway is configured to forward the request for injecting credentials to the application server through kernel-mode zero-copy technology.

7. The system according to claim 6, characterized in that When the application server verifies the token, it uses the public key in the HSM to decrypt and verify the HMAC-SM3 signature to verify the validity of the timestamp.

8. The system according to claim 6, characterized in that When the session fails, the session management module cleans up the data through the Redis expiration event callback and returns a 401 status code to the client.

9. A non-volatile storage medium, characterized in that: The non-volatile storage medium includes a stored program, wherein the program controls the device where the non-volatile storage medium is located to execute the method described in claim 1 when the program is executed.

10. A terminal device, characterized in that: The terminal device comprises: a processor, a memory, a communication interface and a bus; the processor, the memory and the communication interface are connected through the bus and communicate with each other; the memory stores executable program codes; The processor runs a program corresponding to the executable program code by reading the executable program code stored in the memory, so as to execute the method as claimed in claim 1.

Images