Request parameter value authority authentication method and system

Abstract

The invention provides a request parameter value authority authentication method and system, and relates to the technical field of network security, and the method comprises the steps: creating an access control list configuration and binding a service when a gateway registers the service, building the association mapping of a consumer and the service, and setting a parameter authority list; encrypting the sensitive field by adopting an advanced encryption standard algorithm and synchronizing the sensitive field to a distributed cache; and verifying the validity of the token when the service request is received, verifying the authority of the consumer, and verifying the parameter value. According to the invention, unauthorized access can be effectively prevented, the system security is improved, and the authentication efficiency is improved through the distributed cache.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, and in particular to a request parameter value permission authentication method and system. BACKGROUND

[0002] With the rapid development of Internet technology, microservice architecture and API gateway mode are increasingly adopted by enterprises. Under this architecture, the gateway serves as the entrance of the system, bearing important functions such as request routing, load balancing, and security authentication. As the complexity of business increases, the requirements for API access control are becoming more and more refined. Not only is it necessary to control whether a user can access a certain service, but it is also necessary to limit the user's access permission to specific parameter values in the service.

[0003] Currently, common API gateway access control is mainly based on service-level permission verification, that is, it is determined whether a user has the right to call a certain API, but there is a lack of permission control for specific parameter values in the API. Traditional parameter checking is usually performed within the business service, which not only increases the complexity of the business service, but also causes the permission control logic to be scattered in various services, making it difficult to manage and maintain uniformly. SUMMARY

[0004] The embodiments of the present application provide a request parameter value permission authentication method and system, which can solve the problems in the prior art.

[0005] In a first aspect of the embodiments of the present application, a request parameter value permission authentication method is provided, comprising: When a service is registered in the gateway, an access control list configuration is created and bound to the service; when a consumer applies for access permission to the service, an association mapping between the consumer identifier and the service is established in the access control list configuration, and a parameter permission list of the consumer is set; Sensitive fields in the parameter permission list are encrypted using an advanced encryption standard algorithm, and the encrypted configuration information is stored in the database of the gateway; at the same time, the encrypted configuration information is synchronized to the distributed cache, and the consistency of the configuration information in the database and the distributed cache is maintained through a combination of timing tasks and change notifications; When a service access request carrying a token is received, the validity of the token is verified and the corresponding consumer information is obtained; based on the consumer information, it is checked whether the consumer has the permission to access the service; If the access permission is available, the parameter permission list of the consumer is obtained from the access control list configuration, and the parameter value in the request is checked for permission; If the parameter value is not within the permission range, a response information of no permission access is returned; if the parameter value is within the permission range, service forwarding is performed.

[0006] When registering a service in the gateway, an access control list configuration is created and bound to the service; when a consumer requests access to the service, an association mapping between the consumer identifier and the service is established in the access control list configuration, and the consumer's parameter permission list is set, including: Receive a service registration request and parse the parameter permission verification identifier within it; determine whether to enable parameter permission verification based on the parameter permission verification identifier; when parameter permission verification is enabled, generate an access control list configuration template containing an input parameter configuration area and an output parameter configuration area, and assign a globally unique configuration identifier to the access control list configuration template; write the globally unique configuration identifier into the service's metadata to complete the binding of the access control list configuration with the service; The system receives parameter permission requests from consumers for the service; retrieves the globally unique configuration identifier from the service's metadata; locates the corresponding access control list (ACL) configuration template based on the globally unique configuration identifier; sets the consumer's input parameter access range in the input parameter configuration area of ​​the ACL configuration template, and sets the consumer's output parameter access range in the output parameter configuration area; generates a mapping record containing consumer identifiers and service identifiers; writes the mapping record into the mapping area of ​​the ACL configuration template, and sets the consumer's parameter permission list.

[0007] Sensitive fields in the parameter permission list are encrypted using an Advanced Encryption Standard (AES) algorithm, and the encrypted configuration information is stored in the gateway's database. Simultaneously, the encrypted configuration information is synchronized to a distributed cache, and consistency between the database and the distributed cache is maintained through a combination of scheduled tasks and change notifications. Obtain the master key from the gateway's key manager; generate a data encryption key by executing a key derivation algorithm based on the master key; combine the data encryption key with the current timestamp to generate an encrypted session identifier; write the encrypted session identifier into the metadata area of ​​the parameter permission list; encrypt the parameter values ​​in the parameter permission list one by one according to the data encryption key to generate an encrypted parameter set; construct an encrypted configuration package containing the encrypted session identifier and the encrypted parameter set, and write the encrypted configuration package into the secure storage partition of the gateway database; A configuration synchronization task is constructed, which periodically accesses the gateway database carrying the encrypted session identifier; based on the encrypted session identifier, the encrypted configuration package in the gateway database is retrieved, the encrypted session identifier is extracted from the encrypted configuration package, and the corresponding data encryption key is requested from the key manager; The encrypted parameter set is decrypted using the acquired data encryption key to obtain the original parameter permission data; the original parameter permission data is written into the distributed cache system; a configuration change message containing the encrypted session identifier is generated; the configuration change message is broadcast to all gateway nodes through the message bus, triggering each node to update its local cache data based on the same encrypted session identifier.

[0008] Based on the data encryption key, the parameter values ​​in the parameter permission list are encrypted one by one to generate an encrypted parameter set including: Read the parameter value to be encrypted from the parameter permission list; calculate the data length of the parameter value to be encrypted; when the data length is greater than the preset group length, group the parameter value to be encrypted into groups of fixed size; generate random padding bytes for each data group; The random padding bytes are combined with data blocks to form encrypted blocks; symmetric encryption operations are performed on each encrypted block using the data encryption key; a message authentication code is calculated for each encryption result; and the encryption result is combined with the corresponding message authentication code to generate an encryption parameter item. All encrypted parameter items are sequentially combined to form an encrypted parameter set; the global message authentication code of the encrypted parameter set is calculated; and the global message authentication code is appended to the end of the encrypted parameter set.

[0009] Upon receiving a service access request carrying a token, the validity of the token is verified and the corresponding consumer information is obtained. Based on the consumer information, the verification of whether the consumer has permission to access the service includes: Extract the token string from the service access request; parse the token string to obtain the signature algorithm identifier and the consumer identity identifier; Construct a token plaintext containing all but the token signature; obtain the corresponding verification public key from the gateway database based on the signature algorithm identifier; verify the token plaintext and token signature using the verification public key; when the verification passes, write the consumer identity identifier into the request context; Based on the consumer identity identifier, query the consumer information database to obtain the consumer's authorization policy identifier; use the authorization policy identifier to obtain access control rules from the gateway's authorization policy library; extract the token authorization scope from the token plaintext; match the token authorization scope with the access control rules to verify whether the consumer has permission to access the service.

[0010] Based on the signature algorithm identifier, the corresponding verification public key is obtained from the gateway database; the verification of the token plaintext and token signature using the verification public key includes: The signature algorithm identifier is parsed to obtain the signature algorithm type and key length parameters; the key index is obtained by querying the gateway key configuration table based on the signature algorithm type; the signature verification public key ciphertext is obtained from the key management service using the key index; the key decryption key is read from the hardware security module; the signature verification public key ciphertext is decrypted using the key decryption key to obtain the signature verification public key plaintext; the key length of the signature verification public key plaintext is verified to match the key length parameter; if they match, the signature verification public key plaintext is loaded into the key cache area. Extract the signature verification field from the token plaintext; calculate the hash digest of the signature verification field; extract the digital signature value from the token string; decrypt the digital signature value using the signature verification public key plaintext to obtain the signature digest; compare the signature digest with the hash digest for consistency; when the comparison result is consistent, generate a signature verification pass identifier; write the signature verification pass identifier into the verification result record; clear the signature verification public key plaintext in the key cache area; write the verification result record into the request context.

[0011] A second aspect of the present invention provides a request parameter value permission authentication system, comprising: The first unit is used to create an access control list configuration and bind it to the service when registering a service in the gateway; when a consumer requests access to the service, it establishes an association mapping between the consumer identifier and the service in the access control list configuration and sets the parameter permission list of the consumer. The second unit is used to encrypt the sensitive fields in the parameter permission list using advanced encryption standard algorithms, and store the encrypted configuration information in the gateway's database; at the same time, the encrypted configuration information is synchronized to the distributed cache, and the consistency of the configuration information in the database and the distributed cache is maintained through a combination of scheduled tasks and change notifications. The third unit is used to verify the validity of the token and obtain the corresponding consumer information when receiving a service access request carrying a token; based on the consumer information, it verifies whether the consumer has the permission to access the service. The fourth unit is used to obtain the parameter permission list of the consumer from the access control list configuration if it has access rights, and to perform permission verification on the parameter values ​​in the request. The fifth unit is used to return a response message indicating that access is not permitted if the parameter value is outside the permission range; otherwise, it performs service forwarding.

[0012] A third aspect of the present invention, An electronic device is provided, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0013] Fourth aspect of the present invention, A computer-readable storage medium is provided, having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0014] The beneficial effects of this application are as follows: By configuring access control lists in the gateway and establishing an association mapping between consumer identifiers and services, and setting parameter permission lists for consumers, fine-grained permission control for service calls is achieved. This allows different consumers to access data within a specified range according to their business needs, effectively preventing unauthorized access to data.

[0015] Sensitive fields are encrypted and stored using advanced encryption standard algorithms, and configuration information is saved through a distributed cache in conjunction with the database. This ensures data security, improves the performance of permission verification, reduces the access pressure on the database, and effectively copes with high-concurrency service request scenarios.

[0016] Based on a dual authentication mechanism that combines token verification and parameter value permission verification, more granular access control is achieved while keeping the original interface unchanged. This not only meets the differentiated data access needs of different business scenarios, but also reduces the complexity and maintenance cost of the system. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the parameter value permission authentication method according to an embodiment of the present invention. Figure 2 This is a flowchart illustrating the key generation and data encryption security processing of an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0020] Figure 1This is a flowchart illustrating the parameter value permission authentication method according to an embodiment of the present invention, as shown below. Figure 1 As shown, the method includes: When registering a service in the gateway, an access control list configuration is created and bound to the service; when a consumer requests access to the service, an association mapping between the consumer identifier and the service is established in the access control list configuration, and the parameter permission list of the consumer is set. The sensitive fields in the parameter permission list are encrypted using an advanced encryption standard algorithm, and the encrypted configuration information is stored in the gateway's database. At the same time, the encrypted configuration information is synchronized to the distributed cache, and the consistency of the configuration information in the database and the distributed cache is maintained through a combination of scheduled tasks and change notifications. When a service access request carrying a token is received, the validity of the token is verified and the corresponding consumer information is obtained; based on the consumer information, it is verified whether the consumer has permission to access the service. If access permissions are granted, the parameter permission list of the consumer is obtained from the access control list configuration, and the parameter values ​​in the request are verified for permissions. If the parameter value is outside the permission range, a response message indicating that access is not permitted is returned; if the parameter value is within the permission range, service forwarding is performed.

[0021] In one optional implementation, when registering a service in the gateway, an access control list configuration is created and bound to the service; when a consumer requests access to the service, an association mapping between the consumer identifier and the service is established in the access control list configuration, and the consumer's parameter permission list is set, including: Receive a service registration request and parse the parameter permission verification identifier within it; determine whether to enable parameter permission verification based on the parameter permission verification identifier; when parameter permission verification is enabled, generate an access control list configuration template containing an input parameter configuration area and an output parameter configuration area, and assign a globally unique configuration identifier to the access control list configuration template; write the globally unique configuration identifier into the service's metadata to complete the binding of the access control list configuration with the service; The system receives parameter permission requests from consumers for the service; retrieves the globally unique configuration identifier from the service's metadata; locates the corresponding access control list (ACL) configuration template based on the globally unique configuration identifier; sets the consumer's input parameter access range in the input parameter configuration area of ​​the ACL configuration template, and sets the consumer's output parameter access range in the output parameter configuration area; generates a mapping record containing consumer identifiers and service identifiers; writes the mapping record into the mapping area of ​​the ACL configuration template, and sets the consumer's parameter permission list.

[0022] For example, during the gateway service registration phase, when a service provider registers its service with the gateway, the gateway receives the service registration request and parses the metadata information contained in the request, extracting a parameter permission check flag. This flag can be a Boolean value; for example, "parameterPermissionCheck=true" indicates that parameter permission check is enabled, and "parameterPermissionCheck=false" indicates that it is not enabled. The gateway determines whether a parameter-level access control list configuration needs to be created for the service based on this flag. If the parameter permission check flag is "true", the gateway generates an access control list configuration template, which includes input parameter configuration areas and output parameter configuration areas.

[0023] When generating the access control list configuration template, the gateway system uses the UUID algorithm to generate a globally unique configuration identifier for the template, such as "acl-config-7e9f8g7h-6j5k-4l3m-2n1o-0p9q8r7s6t5u". The input parameter configuration area is used to subsequently set the range of request parameters that consumers can access. Its data structure is in key-value pair format, where the key is the consumer identifier and the value is a list of allowed parameter names. The output parameter configuration area also uses a key-value pair structure to set the range of response parameters that consumers can obtain. The configuration template also includes a mapping area to store the association between consumer identifiers and service identifiers.

[0024] The gateway writes the generated globally unique configuration identifier into the service's metadata, for example, adding the key-value pair "aclConfigId=acl-config-7e9f8g7h-6j5k-4l3m-2n1o-0p9q8r7s6t5u" to the service metadata. In this way, the gateway completes the binding between the access control list configuration and the service. This binding relationship is stored in the gateway's configuration database, enabling the gateway to quickly locate the corresponding access control configuration when processing requests for that service.

[0025] During the permission request phase, when a consumer needs to access a service, it submits a service access permission request to the gateway. This request includes the consumer identifier (e.g., "consumer-9s8d7f-6g5h-4j3k"), the target service identifier (e.g., "payment-service-v1"), and parameter permission request information. The parameter permission request information details the input parameters the consumer wishes to access and the output parameters it expects to obtain. For example, a consumer might request access to the "userId" and "amount" input parameters and the "transactionId" and "status" output parameters of the payment service, but does not need access to sensitive parameters such as "cardDetails" or "userAddress".

[0026] After receiving a parameter permission request, the gateway retrieves a globally unique configuration identifier from the target service's metadata. Using this identifier, the gateway searches the configuration database for the corresponding access control list configuration template. Once the template is found, the gateway sets the input parameter access scope for the consumer in the input parameter configuration area of ​​the template, based on the consumer's request information. For example, the key-value pair "consumer-9s8d7f-6g5h-4j3k: ['userId', 'amount']" is added to the input parameter configuration area. Similarly, the key-value pair "consumer-9s8d7f-6g5h-4j3k: ['transactionId', 'status']" is added to the output parameter configuration area to set the consumer's output parameter access scope.

[0027] After completing the parameter permission settings, the gateway generates a mapping record containing consumer identifiers and service identifiers, in the form of "{consumerId: 'consumer-9s8d7f-6g5h-4j3k', serviceId: 'payment-service-v1'}". The gateway writes this mapping record to the mapping area of ​​the access control list configuration, establishing the association between the consumer and the service. This mapping relationship allows the gateway to quickly determine whether the requester has permission to access the target service when it receives a service request.

[0028] During the request processing phase, when the gateway receives a service call request from a consumer, it first extracts the consumer identifier and the target service identifier from the request. The gateway then checks the mapping area configured in the access control list to verify whether the consumer has the right to access the service. If the verification passes, the gateway further parses the list of input parameters from the request and compares it with the range of input parameters accessed by the consumer in the access control list. If the request contains unauthorized parameters, the gateway will reject the request and return a permission error response.

[0029] If the input parameters are validated successfully, the gateway forwards the request to the backend service. Upon receiving the service response, the gateway filters the response data based on the access scope of the consumer's output parameters. For example, if the consumer only has permission to access "transactionId" and "status," but the response also includes "cardDetails," the gateway will remove the "cardDetails" field before returning it to the consumer. In this way, even if the backend service returns complete data, the gateway ensures that the consumer can only access the data fields it is authorized to access.

[0030] This parameter-based, fine-grained access control mechanism enables service providers to precisely control different consumers' access permissions to service parameters, effectively protecting the security of sensitive data while meeting the differentiated access needs of different consumers.

[0031] In one optional implementation, the sensitive fields in the parameter permission list are encrypted using an Advanced Encryption Standard (AES) algorithm, and the encrypted configuration information is stored in the gateway's database. Simultaneously, the encrypted configuration information is synchronized to a distributed cache, and consistency between the configuration information in the database and the distributed cache is maintained through a combination of scheduled tasks and change notifications. Obtain the master key from the gateway's key manager; generate a data encryption key by executing a key derivation algorithm based on the master key; combine the data encryption key with the current timestamp to generate an encrypted session identifier; write the encrypted session identifier into the metadata area of ​​the parameter permission list; encrypt the parameter values ​​in the parameter permission list one by one according to the data encryption key to generate an encrypted parameter set; construct an encrypted configuration package containing the encrypted session identifier and the encrypted parameter set, and write the encrypted configuration package into the secure storage partition of the gateway database; A configuration synchronization task is constructed, which periodically accesses the gateway database carrying the encrypted session identifier; based on the encrypted session identifier, the encrypted configuration package in the gateway database is retrieved, the encrypted session identifier is extracted from the encrypted configuration package, and the corresponding data encryption key is requested from the key manager; The encrypted parameter set is decrypted using the acquired data encryption key to obtain the original parameter permission data; the original parameter permission data is written into the distributed cache system; a configuration change message containing the encrypted session identifier is generated; the configuration change message is broadcast to all gateway nodes through the message bus, triggering each node to update its local cache data based on the same encrypted session identifier.

[0032] like Figure 2 As shown, the method includes: In this embodiment, the gateway system first needs to ensure that sensitive fields in the parameter permission list are effectively protected. This process begins by retrieving the master key from the gateway's key manager. This master key is typically a 256-bit key material, securely stored in a hardware security module. To prevent the master key from being directly exposed during the business data encryption process, a key derivation algorithm is executed based on this master key to generate a data encryption key. In practice, the HKDF (HMAC-based Key Derivation Function) key derivation function can be used to combine the master key with a randomly generated salt value, generating a 128-bit key specifically for data encryption through multiple rounds of iterative computation. For example, when the master key is "a9d8f7e6c5b4a3b2c1d0e9f8a7b6c5d4", the HKDF algorithm, combined with the salt value "5f4e3d2c1b0a", can generate the data encryption key "e7c6b5a4d3c2b1a0".

[0033] After generating the data encryption key, this key is combined with the current UTC timestamp (accurate to milliseconds) to generate an encrypted session identifier. For example, if the data encryption key is "e7c6b5a4d3c2b1a0" and the current timestamp is "1633506789123", the generated encrypted session identifier will be "e7c6b5a4d3c2b1a0-1633506789123". This encrypted session identifier will be written to the metadata area of ​​the parameter permission list as an associated index for subsequent encryption and decryption operations.

[0034] Subsequently, each parameter value in the parameter permission list is encrypted one by one according to the data encryption key. Encryption uses AES-GCM mode, which provides both data encryption and data integrity verification. For each sensitive field in the parameter permission list, such as the API access key "api_key:AbCdEf123456", it is encrypted using the data encryption key to obtain the corresponding ciphertext, such as "encrypted:8a7b6c5d4e3f2g1h0i9j8k7l6m5n4o3". All the encrypted parameter values ​​combined constitute the encrypted parameter set.

[0035] The encrypted session identifier and the set of encrypted parameters are combined to form a complete encrypted configuration package. A typical JSON structure for an encrypted configuration package is as follows: {"session_id":"e7c6b5a4d3c2b1a0-1633506789123", "encrypted_params":{"api_key":"encrypted:8a7b6c5d4e3f2g1h0i9j8k7l6m5n4o3", "access_token":"encrypted:7f6e5d4c3b2a1b2c3d4e5f6g7h8i9j0"}}. This encrypted configuration package is written to the secure storage partition of the gateway database to ensure the security of sensitive data in a static storage state.

[0036] To ensure the consistency of configuration data across gateway nodes in a distributed environment, a configuration synchronization task can be constructed. This task periodically accesses the gateway database at fixed intervals (typically 5 seconds), carrying an encrypted session identifier. During each access, the task retrieves an encrypted configuration packet from the gateway database based on the encrypted session identifier "e7c6b5a4d3c2b1a0-1633506789123". After obtaining the configuration packet, the synchronization task extracts the encrypted session identifier and sends a request to the key manager to obtain the corresponding data encryption key "e7c6b5a4d3c2b1a0".

[0037] After successfully obtaining the data encryption key, the synchronization task uses this key to decrypt each encrypted parameter value in the encrypted parameter set. Taking the encrypted API key as an example, decrypting "encrypted:8a7b6c5d4e3f2g1h0i9j8k7l6m5n4o3" using AES-GCM yields the original value "api_key:AbCdEf123456". After decrypting all parameters, the complete original parameter permission data is obtained.

[0038] The synchronization task writes the decrypted original parameter permission data to a distributed caching system (such as a Redis cluster) and sets an appropriate expiration time (such as 3600 seconds). The cache key name typically uses the format "config:gateway:{gateway_id}:params" to ensure that configuration data from different gateway instances is isolated from each other. After writing to the cache, a configuration change message containing an encrypted session identifier is generated: {"event":"config_changed", "session_id":"e7c6b5a4d3c2b1a0-1633506789123", "timestamp":1633506789123}.

[0039] This configuration change message is broadcast to all gateway nodes via a message bus (such as Kafka). The specific topic can be set to "gateway.config.updates", and the message partition key is the gateway ID, ensuring that configuration update messages for the same gateway are processed sequentially. Upon receiving this message, the configuration listening component on each gateway node extracts the encrypted session identifier and uses it as an index to retrieve the latest configuration data from the distributed cache, updating its local memory cache. This mechanism ensures that all gateway nodes can synchronously obtain the latest configuration information in the shortest possible time without frequent database access.

[0040] In addition, a scheduled check task is set up on each gateway node to check every 30 seconds whether the timestamp of the configuration data in the local cache is consistent with the timestamp in the distributed cache. If an inconsistency is found, the latest configuration is actively retrieved from the distributed cache to ensure that even if there is a temporary failure in the message bus, the configuration data of each node will eventually remain consistent.

[0041] In one optional implementation, the parameter values ​​in the parameter permission list are encrypted one by one according to the data encryption key to generate an encrypted parameter set, including: Read the parameter value to be encrypted from the parameter permission list; calculate the data length of the parameter value to be encrypted; when the data length is greater than the preset group length, group the parameter value to be encrypted into groups of fixed size; generate random padding bytes for each data group; The random padding bytes are combined with data blocks to form encrypted blocks; symmetric encryption operations are performed on each encrypted block using the data encryption key; a message authentication code is calculated for each encryption result; and the encryption result is combined with the corresponding message authentication code to generate an encryption parameter item. All encrypted parameter items are sequentially combined to form an encrypted parameter set; the global message authentication code of the encrypted parameter set is calculated; and the global message authentication code is appended to the end of the encrypted parameter set.

[0042] This embodiment provides a parameter permission encryption method that ensures data security by encrypting the parameter values ​​in the parameter permission list. The method combines symmetric encryption with message authentication to ensure data confidentiality and integrity.

[0043] This method first requires pre-setting a data encryption key, which can be 128-bit, 192-bit, or 256-bit binary data, used for subsequent encryption operations. It also requires pre-setting a block length, for example, 16 bytes, as the base size for the data blocks.

[0044] In actual implementation, the parameter values ​​to be encrypted are obtained from the parameter permission list. Assume there is a parameter permission list containing several parameter items, each consisting of a parameter name and a parameter value. For example, the parameter name is "user_id" with a corresponding value of "admin12345"; the parameter name is "access_level" with a corresponding value of "super_admin"; and the parameter name is "permission_details" with a corresponding value of a long permission description text.

[0045] For each parameter value to be encrypted, its data length is first calculated. Taking "admin12345" as an example, the string length is 10 bytes. This length is compared with the preset block length (16 bytes). Since 10 bytes is less than 16 bytes, no block processing is needed, and it can be processed as a complete data block.

[0046] For longer parameter values, such as the permission description text corresponding to "permission_details" which is assumed to be 50 bytes long, exceeding the preset 16-byte group length, it will be divided into 4 data groups: the first 3 groups are 16 bytes each, and the last group is 2 bytes.

[0047] For each data group or complete short parameter value, generate random padding bytes. Random padding bytes can be generated using a secure random number generator, and the padding length can be set as needed. For example, for the 10-byte parameter value "admin12345", 6 bytes of random padding data can be generated, making the total data block length 16 bytes, which perfectly matches the preset group length.

[0048] After generating random padding bytes, these bytes are combined with data blocks to form an encrypted block. The combination can be done by appending the random padding bytes to the data blocks or by interleaving them. For example, assuming the generated 6-byte random padding data is "r4nd0m", the resulting encrypted block would be "admin12345r4nd0m".

[0049] Next, symmetric encryption is performed on each encrypted block using the data encryption key. The symmetric encryption algorithm can be AES, DES, or other well-established algorithms. Assuming AES-128 is used to encrypt the "admin12345r4nd0m" encrypted block, the resulting ciphertext can be represented as a hexadecimal string, such as "7b8f9d2e5a3c6b4d8e7f9a2b5c3d6e4f".

[0050] After encryption, a Message Authentication Code (MAC) is calculated for each encryption result. The MAC can be calculated using the HMAC algorithm, combined with the data encryption key and the encryption result. For the above encryption result, the calculated MAC value might be "8e7d6c5f4e3d2c1b".

[0051] The encrypted result is then combined with the corresponding message authentication code to generate an encrypted parameter item. This can be done by appending the MAC address to the end of the encrypted result to form a complete encrypted parameter item. In the example above, the encrypted parameter item is "7b8f9d2e5a3c6b4d8e7f9a2b5c3d6e4f8e7d6c5f4e3d2c1b".

[0052] Repeat the above steps for each parameter value in the parameter permission list to generate the corresponding encrypted parameter items. Assuming the encrypted parameter item corresponding to the parameter "access_level" is "6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e", the parameter "permission_details" will be divided into 4 encrypted parameter items after being encrypted in groups.

[0053] Combine all encrypted parameter items according to the order in which they appear in the permission list to form an encrypted parameter set. For example, the combined encrypted parameter set could be "7b8f9d2e5a3c6b4d8e7f9a2b5c3d6e4f8e7d6c5f4e3d2c1b6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e [4 encrypted parameter items from permission_details]".

[0054] To ensure the integrity of the entire set of encrypted parameters, a global message authentication code (MAC) is calculated for the set of encrypted parameters. The global MAC can be calculated using the same algorithm as a single encrypted result MAC, but with the entire set of encrypted parameters as input. Assume the calculated global MAC is "1a2b3c4d5e6f7g8h".

[0055] The global message authentication code is appended to the end of the encrypted parameter set to form the final encrypted data. In this way, all sensitive parameter values ​​in the entire parameter permission list are encrypted and can be securely stored or transmitted.

[0056] In subsequent use, the receiver can use the same data encryption key to decrypt the encrypted parameter set. During decryption, the correctness of the global MAC is first verified to confirm that the encrypted parameter set has not been tampered with; then, the MAC of each encrypted parameter item is verified and decrypted one by one according to the parameter order, and finally the original parameter values ​​are recovered.

[0057] Using the methods described above, even if encrypted data is intercepted, attackers cannot obtain the original parameter values ​​without the data encryption key, effectively ensuring the security of parameter permission data. Simultaneously, the application of message authentication codes ensures data integrity and prevents malicious tampering.

[0058] In one optional implementation, upon receiving a service access request carrying a token, the validity of the token is verified and the corresponding consumer information is obtained; based on the consumer information, verifying whether the consumer has permission to access the service includes: Extract the token string from the service access request; parse the token string to obtain the signature algorithm identifier and the consumer identity identifier; Construct a token plaintext containing all but the token signature; obtain the corresponding verification public key from the gateway database based on the signature algorithm identifier; verify the token plaintext and token signature using the verification public key; when the verification passes, write the consumer identity identifier into the request context; Based on the consumer identity identifier, query the consumer information database to obtain the consumer's authorization policy identifier; use the authorization policy identifier to obtain access control rules from the gateway's authorization policy library; extract the token authorization scope from the token plaintext; match the token authorization scope with the access control rules to verify whether the consumer has permission to access the service.

[0059] In this embodiment, a service access control method relates to a technical solution for API gateways to verify and control access permissions for service access requests carrying tokens. The method includes steps such as receiving a service access request carrying a token, verifying the token's validity, obtaining consumer information, and checking consumer permissions.

[0060] The API gateway receives service access requests from consumers, which carry access tokens. The gateway extracts the token string from the Authorization field of the HTTP request header; the token is typically in "Bearer token" format. After obtaining the token string, the gateway parses it. The token string is usually in JSON Web Token (JWT) format, consisting of three parts: header, payload, and signature, separated by periods. The gateway first performs Base64URL decoding on the token header to obtain the signature algorithm identifier "alg". In this example, the decoded result is {"alg":"RS256","typ":"JWT"}, indicating that the signature algorithm is RS256 (RSA SHA-256).

[0061] The gateway continues parsing the token payload, obtaining the consumer identifier "sub" through Base64URL decoding. In this example, the decoded result is {"sub":"user123","scope":"read write","exp":1591622400}, where "user123" is the consumer identifier, the "scope" field indicates that the token authorization scope is "read write", and the "exp" field indicates that the token expiration timestamp is 1591622400.

[0062] After completing token parsing, the gateway constructs the token plaintext, which consists of the original content of the token header and payload. In JWT format, the token plaintext is a Base64 URL-encoded value for both the header and payload, connected by a dot. For the example token, the plaintext is "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwic2NvcGUiOiJyZWFkIHdyaXRlIiwiZXhwIjoxNTkxNjIyNDAwfQ".

[0063] The gateway retrieves the corresponding verification public key from the gateway database based on the signature algorithm identifier "RS256". The gateway database maintains verification key information for different algorithms. For example, for the RS256 algorithm, the database stores the RSA public key, which can be in PEM-encoded format.

[0064] The gateway uses the obtained signature verification public key to verify both the token plaintext and the token signature. The verification process includes decrypting the token signature using the public key and comparing the result with the hash value of the token plaintext. If they match, the signature verification passes; otherwise, verification fails, indicating that the token may have been tampered with or an incorrect signature key was used.

[0065] In addition to signature verification, the gateway also checks if the token has expired. It compares the expiration timestamp "exp" in the token with the current system time. If the current time has exceeded the expiration time, the token verification fails. For example, if the current system timestamp is 1591622300, which is less than the token's expiration time of 1591622400, then the token has not expired.

[0066] When token verification is successful, the gateway writes the consumer identifier "user123" into the request context. The request context is a data structure used to pass critical information during request processing. After the consumer identifier is written into the context, subsequent processing can retrieve this information for functions such as access control and audit logging.

[0067] The gateway queries the consumer information database based on the consumer identifier "user123" to obtain the consumer's authorization policy identifier. The consumer information database stores the mapping between consumers and authorization policies. For example, the database may contain a record showing that the authorization policy identifier corresponding to user "user123" is "standard_api_access".

[0068] The gateway uses the authorization policy identifier "standard_api_access" to retrieve the corresponding access control rules from the gateway's authorization policy library. The authorization policy library stores various predefined access control rules. For example, the "standard_api_access" policy might define rules that allow access to specific API paths, such as allowing GET and POST operations on " / api / products" while prohibiting access to the " / api / admin" path.

[0069] The gateway extracts the token's authorization scope from the token's original text, specifically the value "read write" in the "scope" field. The authorization scope indicates the type of operation permissions granted to the token, typically represented by a space-separated string.

[0070] The gateway matches the token's authorization scope ("read, write") against access control rules obtained from the authorization policy library to verify whether the consumer has the necessary permissions to access the requested service. The matching process includes checking if the requested HTTP method and path are within the scope allowed by the access control rules, and whether the token's authorization scope includes the required permissions. For example, if a consumer requests access to the path " / api / products" and performs a POST operation, and this operation requires "write" permission, then because the token's authorization scope includes "write" and the access control rules allow POST operations on that path, the permission match is successful, and the consumer has the permission to access the service.

[0071] If the permission match fails, the gateway will return an HTTP 403 Forbidden response, indicating that the consumer does not have permission to access the requested service. If the permission match succeeds, the gateway will continue processing the request, forwarding it to the target service and including the consumer's identity information in the forwarded request so that the target service can perform further business processing.

[0072] In one optional implementation, the corresponding verification public key is obtained from the gateway database based on the signature algorithm identifier; verifying the token plaintext and token signature using the verification public key includes: The signature algorithm identifier is parsed to obtain the signature algorithm type and key length parameters; the key index is obtained by querying the gateway key configuration table based on the signature algorithm type; the signature verification public key ciphertext is obtained from the key management service using the key index; the key decryption key is read from the hardware security module; the signature verification public key ciphertext is decrypted using the key decryption key to obtain the signature verification public key plaintext; the key length of the signature verification public key plaintext is verified to match the key length parameter; if they match, the signature verification public key plaintext is loaded into the key cache area. Extract the signature verification field from the token plaintext; calculate the hash digest of the signature verification field; extract the digital signature value from the token string; decrypt the digital signature value using the signature verification public key plaintext to obtain the signature digest; compare the signature digest with the hash digest for consistency; when the comparison result is consistent, generate a signature verification pass identifier; write the signature verification pass identifier into the verification result record; clear the signature verification public key plaintext in the key cache area; write the verification result record into the request context.

[0073] In this embodiment, a complete signature verification mechanism ensures the security and validity of the token. When the system receives a request containing a token, it needs to verify the token. The key step in the verification process is to obtain the verification public key based on the signature algorithm identifier and use this public key to verify the token's original text and signature.

[0074] Upon receiving a token request, the system first parses the signature algorithm identifier to obtain the signature algorithm type and key length parameters. For example, the signature algorithm identifier might be "RS256-2048", where "RS256" indicates the RSA-SHA256 algorithm type and "2048" indicates a key length of 2048 bits. The system splits the algorithm identifier into the algorithm type and key length parts using a string splitting operation and stores them in the corresponding variables.

[0075] After obtaining the algorithm type and key length, the gateway key configuration table is queried based on the algorithm type, such as "RS256," to retrieve the corresponding key index. The gateway key configuration table is a key-value pair structure, where the key is the algorithm type and the value is the key index. For example, if the configuration table contains the mapping {"RS256": "key_001", "ES384": "key_002"}, then when the algorithm type is "RS256," the retrieved key index is "key_001".

[0076] The obtained key index is used to send a request to the key management service to retrieve the signature verification public key ciphertext. The key management service is an independent security component responsible for storing and managing various keys. When a request with the index "key_001" is received, the key management service returns the corresponding signature verification public key ciphertext, which is encrypted public key data, such as a Base64 encoded string "e4Rm9pKz3QlMvPaT+G7hJwD9XmY=".

[0077] To decrypt the public key ciphertext for signature verification, the decryption key needs to be read from the Hardware Security Module (HSM). The HSM is a dedicated security hardware device used to protect sensitive key materials. The decryption key is obtained using authentication information by calling the API provided by the HSM. This key is typically not directly exposed to the application but is used internally within the HSM.

[0078] The signature verification public key ciphertext and the decryption key are passed to the HSM, which internally performs the decryption operation to obtain the signature verification public key plaintext. The signature verification public key plaintext is a public key data in a standard format, such as RSA public key data in PEM format, which is a string that begins with "-----BEGIN PUBLIC KEY-----" and ends with "-----END PUBLIC KEY-----".

[0079] After decryption, the key length of the plaintext public key for signature verification is verified to match the previously parsed key length parameter. This is done by parsing the public key data structure and extracting the modulus bits. If the extracted bits are 2048, it matches the key length parameter "2048". If they do not match, the verification process is aborted and an error is logged; if they match, the plaintext public key for signature verification is loaded into the key cache area for later use. The key cache area is a protected memory space specifically used for temporarily storing sensitive key materials.

[0080] Once the signature verification public key is ready, the fields to be verified for the signature are extracted from the token plaintext. The token plaintext is usually a JSON data structure containing various claims. All content except the signature needs to be extracted as the fields to be verified for the signature. For example, for a JWT token, the system will extract the header and payload as the fields to be verified for the signature. These are typically two Base64URL-encoded strings connected by a period (.).

[0081] Calculate the hash digest for the field to be verified in the signature. Select the corresponding hash algorithm according to the signature algorithm type, for example, "RS256" uses the SHA-256 algorithm. Input the field to be verified into the SHA-256 hash function to obtain a 32-byte hash digest, represented as a hexadecimal string, such as "7b824d28b52676eb08382c1b037811b6a9b24ed593c7d48c45cbcb552992".

[0082] Simultaneously, the digital signature value is extracted from the token string. For JWT tokens, the digital signature value is located in the last part and is a Base64URL-encoded string. Decoding this string yields the original binary signature data.

[0083] The digital signature value is decrypted using the plaintext of the signature verification public key to obtain the signature digest. This step leverages the properties of asymmetric encryption, using the public key to decrypt data encrypted by the private key. The resulting signature digest should be the original hash value, also represented as a hexadecimal string.

[0084] The hash digest obtained from the calculation is compared with the signature digest obtained from the decryption. If they are exactly the same, the signature verification is successful; if there are any differences, the signature verification fails.

[0085] When the comparison results match, a signature verification pass flag is generated, such as the boolean value "true" or the string "SIGNATURE_VERIFIED", and this flag is written to the verification result record. The verification result record is a data structure that contains various information about the verification process, such as the verification time and verification result.

[0086] After verification is complete, the plaintext of the signature public key is cleared from the key cache area to ensure that sensitive key materials are not retained in memory for extended periods, thus reducing security risks. The clearing operation includes overwriting the memory area with zero or a random value and releasing the associated memory resources.

[0087] Finally, the verification result is recorded in the request context for reference by subsequent processing logic. The request context is a data container associated with the current request, storing various information during request processing. After the verification result is written to the context, other components can decide how to handle the request based on the verification result, such as allowing access to protected resources or denying the request.

[0088] The present invention provides a parameter value permission authentication system, comprising: The first unit is used to create an access control list configuration and bind it to the service when registering a service in the gateway; when a consumer requests access to the service, it establishes an association mapping between the consumer identifier and the service in the access control list configuration and sets the parameter permission list of the consumer. The second unit is used to encrypt the sensitive fields in the parameter permission list using advanced encryption standard algorithms, and store the encrypted configuration information in the gateway's database; at the same time, the encrypted configuration information is synchronized to the distributed cache, and the consistency of the configuration information in the database and the distributed cache is maintained through a combination of scheduled tasks and change notifications. The third unit is used to verify the validity of the token and obtain the corresponding consumer information when receiving a service access request carrying a token; based on the consumer information, it verifies whether the consumer has the permission to access the service. The fourth unit is used to obtain the parameter permission list of the consumer from the access control list configuration if it has access rights, and to perform permission verification on the parameter values ​​in the request. The fifth unit is used to return a response message indicating that access is not permitted if the parameter value is outside the permission range; otherwise, it performs service forwarding.

[0089] A third aspect of the present invention, An electronic device is provided, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0090] Fourth aspect of the present invention, A computer-readable storage medium is provided, having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0091] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0092] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for requesting parameter value permission authentication, characterized in that, include: When registering a service in the gateway, create an access control list configuration and bind it to the service; When a consumer requests access to the service, an association mapping between the consumer identifier and the service is established in the access control list configuration, and the parameter permission list of the consumer is set. The sensitive fields in the parameter permission list are encrypted using an advanced encryption standard algorithm, and the encrypted configuration information is stored in the gateway's database. At the same time, the encrypted configuration information is synchronized to the distributed cache, and the consistency of the configuration information in the database and the distributed cache is maintained through a combination of scheduled tasks and change notifications. When a service access request carrying a token is received, the validity of the token is verified and the corresponding consumer information is obtained; Based on the consumer information, verify whether the consumer has permission to access the service; If access permissions are granted, the parameter permission list of the consumer is obtained from the access control list configuration, and the parameter values ​​in the request are verified for permissions. If the parameter value is not within the permission range, a response message indicating that access is not permitted will be returned. If the parameter value is within the permission range, then service forwarding will be performed.

2. The method according to claim 1, characterized in that, When registering a service in the gateway, an access control list configuration is created and bound to the service; when a consumer requests access to the service, an association mapping between the consumer identifier and the service is established in the access control list configuration, and the consumer's parameter permission list is set, including: Receive a service registration request and parse the parameter permission verification identifier within it; determine whether to enable parameter permission verification based on the parameter permission verification identifier; when parameter permission verification is enabled, generate an access control list configuration template containing an input parameter configuration area and an output parameter configuration area, and assign a globally unique configuration identifier to the access control list configuration template; write the globally unique configuration identifier into the service's metadata to complete the binding of the access control list configuration with the service; The system receives parameter permission requests from consumers for the service; retrieves the globally unique configuration identifier from the service's metadata; locates the corresponding access control list (ACL) configuration template based on the globally unique configuration identifier; sets the consumer's input parameter access range in the input parameter configuration area of ​​the ACL configuration template, and sets the consumer's output parameter access range in the output parameter configuration area; generates a mapping record containing consumer identifiers and service identifiers; writes the mapping record into the mapping area of ​​the ACL configuration template, and sets the consumer's parameter permission list.

3. The method according to claim 1, characterized in that, Sensitive fields in the parameter permission list are encrypted using an Advanced Encryption Standard (AES) algorithm, and the encrypted configuration information is stored in the gateway's database. Simultaneously, the encrypted configuration information is synchronized to a distributed cache, and consistency between the database and the distributed cache is maintained through a combination of scheduled tasks and change notifications. Obtain the master key from the gateway's key manager; generate a data encryption key by executing a key derivation algorithm based on the master key; combine the data encryption key with the current timestamp to generate an encrypted session identifier; write the encrypted session identifier into the metadata area of ​​the parameter permission list; encrypt the parameter values ​​in the parameter permission list one by one according to the data encryption key to generate an encrypted parameter set; construct an encrypted configuration package containing the encrypted session identifier and the encrypted parameter set, and write the encrypted configuration package into the secure storage partition of the gateway database; A configuration synchronization task is constructed, which periodically accesses the gateway database carrying the encrypted session identifier; based on the encrypted session identifier, the encrypted configuration package in the gateway database is retrieved, the encrypted session identifier is extracted from the encrypted configuration package, and the corresponding data encryption key is requested from the key manager; The encrypted parameter set is decrypted using the acquired data encryption key to obtain the original parameter permission data; the original parameter permission data is written into the distributed cache system; a configuration change message containing the encrypted session identifier is generated; the configuration change message is broadcast to all gateway nodes through the message bus, triggering each node to update its local cache data based on the same encrypted session identifier.

4. The method according to claim 3, characterized in that, Based on the data encryption key, the parameter values ​​in the parameter permission list are encrypted one by one to generate an encrypted parameter set including: Read the parameter value to be encrypted from the parameter permission list; calculate the data length of the parameter value to be encrypted; when the data length is greater than the preset group length, group the parameter value to be encrypted into groups of fixed size; generate random padding bytes for each data group; The random padding bytes are combined with data blocks to form encrypted blocks; symmetric encryption operations are performed on each encrypted block using the data encryption key; a message authentication code is calculated for each encryption result; and the encryption result is combined with the corresponding message authentication code to generate an encryption parameter item. All encrypted parameter items are sequentially combined to form an encrypted parameter set; the global message authentication code of the encrypted parameter set is calculated; and the global message authentication code is appended to the end of the encrypted parameter set.

5. The method according to claim 1, characterized in that, When a service access request carrying a token is received, the validity of the token is verified and the corresponding consumer information is obtained; Based on the consumer information, verifying whether the consumer has permission to access the service includes: Extract the token string from the service access request; parse the token string to obtain the signature algorithm identifier and the consumer identity identifier; Construct a token plaintext containing all but the token signature; obtain the corresponding verification public key from the gateway database based on the signature algorithm identifier; verify the token plaintext and token signature using the verification public key; when the verification passes, write the consumer identity identifier into the request context; Based on the consumer identity identifier, query the consumer information database to obtain the consumer's authorization policy identifier; use the authorization policy identifier to obtain access control rules from the gateway's authorization policy library; extract the token authorization scope from the token plaintext; match the token authorization scope with the access control rules to verify whether the consumer has permission to access the service.

6. The method according to claim 5, characterized in that, Based on the signature algorithm identifier, obtain the corresponding signature verification public key from the gateway database; Verifying the token plaintext and token signature using the signature verification public key includes: The signature algorithm identifier is parsed to obtain the signature algorithm type and key length parameters; the key index is obtained by querying the gateway key configuration table based on the signature algorithm type; the signature verification public key ciphertext is obtained from the key management service using the key index; the key decryption key is read from the hardware security module; the signature verification public key ciphertext is decrypted using the key decryption key to obtain the signature verification public key plaintext; the key length of the signature verification public key plaintext is verified to match the key length parameter; if they match, the signature verification public key plaintext is loaded into the key cache area. Extract the signature verification field from the token plaintext; calculate the hash digest of the signature verification field; extract the digital signature value from the token string; decrypt the digital signature value using the signature verification public key plaintext to obtain the signature digest; compare the signature digest with the hash digest for consistency; when the comparison result is consistent, generate a signature verification pass identifier; write the signature verification pass identifier into the verification result record; clear the signature verification public key plaintext in the key cache area; write the verification result record into the request context.

7. A request parameter value authorization system, used to implement the method as described in any one of claims 1-6, characterized in that, include: The first unit is used to create an access control list configuration and bind it to the service when registering the service in the gateway; When a consumer requests access to the service, an association mapping between the consumer identifier and the service is established in the access control list configuration, and the parameter permission list of the consumer is set. The second unit is used to encrypt the sensitive fields in the parameter permission list using advanced encryption standard algorithms, and store the encrypted configuration information in the gateway's database; at the same time, the encrypted configuration information is synchronized to the distributed cache, and the consistency of the configuration information in the database and the distributed cache is maintained through a combination of scheduled tasks and change notifications. The third unit is used to verify the validity of the token and obtain the corresponding consumer information when receiving a service access request carrying a token; Based on the consumer information, verify whether the consumer has permission to access the service; The fourth unit is used to obtain the parameter permission list of the consumer from the access control list configuration if it has access rights, and to perform permission verification on the parameter values ​​in the request. The fifth unit is used to return a response message indicating that access is not permitted if the parameter value is not within the permission range. If the parameter value is within the permission range, then service forwarding will be performed.

8. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 6.

Images