Request parameter value authority authentication method and system

Abstract

The application provides a request parameter value authority authentication method and system, relates to the network security technical field, and comprises the following steps: creating an access control list configuration and binding a service when registering the service in a gateway, establishing an associated mapping of a consumer and the service, and setting a parameter authority list; using an advanced encryption standard algorithm to encrypt sensitive fields and synchronizing to a distributed cache; verifying the validity of a token when receiving a service request, checking the authority of the consumer, and checking parameter values. The application can effectively prevent unauthorized access, improve system security, and improve authentication efficiency 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, micro-service 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:

[0006] 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;

[0007] 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;

[0008] 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;

[0009] If the access permission is available, the parameter permission list of the consumer is obtained from the access control list configuration, and the parameter values in the request are checked for permission;

[0010] If the parameter value is not within the authority range, a response information of no access authority is returned; if the parameter value is within the authority range, service forwarding is performed.

[0011] When registering a service in the gateway, an access control list configuration is created and bound to the service; when a consumer applies for access authority of the service, an association mapping between the consumer identity and the service is established in the access control list configuration, and a parameter authority list of the consumer is set, including:

[0012] Receiving a service registration request and parsing the parameter authority verification identifier therein; judging whether to start parameter authority verification based on the parameter authority verification identifier; when starting parameter authority verification, generating an access control list configuration template including an input parameter configuration area and an output parameter configuration area, and assigning a globally unique configuration identifier to the access control list configuration template; writing the globally unique configuration identifier into the metadata of the service to complete the binding of the access control list configuration and the service;

[0013] Receiving a parameter authority application of the consumer for the service; obtaining the globally unique configuration identifier from the metadata of the service; locating to the corresponding access control list configuration template based on the globally unique configuration identifier; setting the input parameter access range of the consumer in the input parameter configuration area of the access control list configuration template, and setting the output parameter access range of the consumer in the output parameter configuration area; generating a mapping relationship record including the consumer identity and the service identity; writing the mapping relationship record into the mapping area of the access control list configuration to set the parameter authority list of the consumer.

[0014] Encrypting sensitive fields in the parameter authority list using the advanced encryption standard algorithm, storing the encrypted configuration information in the database of the gateway, and synchronizing the encrypted configuration information to the distributed cache while maintaining the consistency of the configuration information in the database and the distributed cache through a combination of timing tasks and change notifications, including:

[0015] Obtaining a master key from the key manager of the gateway; generating a data encryption key based on the key derivation algorithm of the master key; combining the data encryption key with the current timestamp to generate an encryption session identifier; writing the encryption session identifier into the metadata area of the parameter authority list; encrypting the parameter values in the parameter authority list one by one according to the data encryption key to generate an encrypted parameter set; constructing an encrypted configuration package including the encryption session identifier and the encrypted parameter set, and writing the encrypted configuration package into the secure storage partition of the gateway database;

[0016] A configuration synchronization task is constructed, which carries the encrypted session identifier to periodically access the gateway database; based on the encrypted session identifier, an encrypted configuration package in the gateway database is retrieved, the encrypted session identifier is extracted from the encrypted configuration package, and a corresponding data encryption key is requested from the key manager;

[0017] The obtained data encryption key is used to decrypt the encrypted parameter set to obtain 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 the local cache data based on the same encrypted session identifier.

[0018] According to the data encryption key, the parameter values in the parameter permission list are encrypted one by one to generate an encrypted parameter set, including:

[0019] The parameter values to be encrypted are read from the parameter permission list; the data length of the parameter values to be encrypted is calculated; when the data length is greater than the preset grouping length, the parameter values to be encrypted are grouped according to a fixed size; random padding bytes are generated for each data group;

[0020] The random padding bytes and the data groups are combined to form an encrypted block; the data encryption key is used to perform symmetric encryption operation on each encrypted block; the message authentication code of each encrypted result is calculated; the encrypted result and the corresponding message authentication code are combined to generate an encrypted parameter item;

[0021] 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; the global message authentication code is appended to the end of the encrypted parameter set.

[0022] When 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, it is checked whether the consumer has the permission to access the service, including:

[0023] The token string is extracted from the service access request; the signature algorithm identifier and the consumer identity identifier are obtained by parsing the token string;

[0024] The token plaintext containing the token signature is constructed; based on the signature algorithm identifier, the corresponding signature verification public key is obtained from the gateway database; the token plaintext and the token signature are verified using the signature verification public key; when the verification is passed, the consumer identity identifier is written into the request context;

[0025] query a consumer information database based on the consumer identity, obtain an authorization policy identifier of the consumer, obtain an access control rule from an authorization policy library of the gateway by using the authorization policy identifier, extract a token authorization scope from the token original text, and perform permission matching on the token authorization scope and the access control rule to verify whether the consumer has the permission to access the service.

[0026] obtain a corresponding signature verification public key from a gateway database based on the signature algorithm identifier, and verify the token original text and the token signature by using the signature verification public key, including:

[0027] obtain a signature algorithm type and a key length parameter based on the signature algorithm identifier, query a gateway key configuration table based on the signature algorithm type to obtain a key index, obtain signature verification public key ciphertext from a key management service by using the key index, read a key decryption key from a hardware security module, decrypt the signature verification public key ciphertext by using the key decryption key to obtain signature verification public key plaintext, verify whether the key length of the signature verification public key plaintext matches the key length parameter, and if the key length matches, load the signature verification public key plaintext into a key cache area.

[0028] extract a signature field to be verified from the token original text, calculate a hash digest of the signature field to be verified, extract a digital signature value from the token string, decrypt the digital signature value by using the signature verification public key plaintext to obtain a signature digest, compare whether the signature digest and the hash digest are consistent, generate a signature verification pass identifier when the comparison result is consistent, write the signature verification pass identifier into a verification result record, clear the signature verification public key plaintext in the key cache area, and write the verification result record into a request context.

[0029] In a second aspect of the embodiment of the application, a request parameter value permission authentication system is provided, including:

[0030] A first unit is configured to create an access control list configuration and bind it to a service when the service is registered in a gateway, establish an association mapping between a consumer identifier and the service in the access control list configuration when a consumer applies for an access permission of the service, and set a parameter permission list of the consumer.

[0031] A second unit is configured to encrypt sensitive fields in the parameter permission list by using an advanced encryption standard algorithm, store the encrypted configuration information in a database of the gateway, synchronize the encrypted configuration information to a distributed cache, and maintain consistency of the configuration information in the database and the distributed cache by combining a timing task and a change notification.

[0032] The third unit is configured to verify validity of the token and obtain corresponding consumer information when receiving a service access request carrying the token, and check whether the consumer has access right to the service based on the consumer information.

[0033] The fourth unit is configured to obtain a parameter right list of the consumer from the access control list configuration if the consumer has the access right, and perform right check on a parameter value in the request.

[0034] The fifth unit is configured to return response information of no access right if the parameter value is not within the right range, and perform service forwarding if the parameter value is within the right range.

[0035] The third aspect of the embodiment of the application,

[0036] An electronic device is provided, comprising:

[0037] a processor;

[0038] a memory for storing processor-executable instructions;

[0039] The processor is configured to invoke the instructions stored in the memory to perform the method described above.

[0040] The fourth aspect of the embodiment of the application,

[0041] A computer-readable storage medium is provided, which stores computer program instructions, and the computer program instructions are executed by a processor to implement the method described above.

[0042] The application has the following beneficial effects:

[0043] By configuring an access control list in a gateway and establishing an association mapping between a consumer identifier and a service, and setting a parameter right list of the consumer, fine right control of service calling is realized, so that different consumers can access data within a specified range according to their business requirements, and unauthorized access of data is effectively prevented.

[0044] The sensitive fields are stored by using an advanced encryption standard algorithm, and configuration information is saved by using a distributed cache and a database in cooperation, so that the performance of right check is improved, the access pressure on the database is reduced, and high-concurrency service request scenarios are effectively coped with while data security is ensured.

[0045] The dual authentication mechanism based on combination of token verification and parameter value right check realizes more fine access control while keeping the original interface unchanged, which meets the differentiated requirements of different business scenarios on data access, and reduces the complexity and maintenance cost of the system. BRIEF DESCRIPTION OF DRAWINGS

[0046] Figure 1 A flowchart of a request parameter value authority authentication method of an embodiment of the present application is shown in FIG. 1.

[0047] Figure 2 A flowchart of a key generation and data encryption security processing of an embodiment of the present application is shown in FIG. 2. DETAILED DESCRIPTION

[0048] To make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described below in connection with the drawings of the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0049] The technical solutions of the present application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and some embodiments can not be described again for the same or similar concepts or processes.

[0050] Figure 1 A flowchart of a request parameter value authority authentication method of an embodiment of the present application is shown in FIG. 1. Figure 1 The method includes:

[0051] When a service is registered in a gateway, an access control list configuration is created and bound to the service; when a consumer applies for an access right of the service, an association mapping of a consumer identifier and the service is established in the access control list configuration, and a parameter authority list of the consumer is set;

[0052] Sensitive fields in the parameter authority list are encrypted by using an advanced encryption standard algorithm, and the encrypted configuration information is stored in a database of the gateway; at the same time, the encrypted configuration information is synchronized to a distributed cache, and the consistency of the configuration information in the database and the distributed cache is maintained by combining a timing task with a change notification;

[0053] When a service access request carrying a token is received, the validity of the token is verified and corresponding consumer information is obtained; based on the consumer information, it is checked whether the consumer has an access right of the service;

[0054] If the access right is available, the parameter authority list of the consumer is obtained from the access control list configuration, and the parameter value in the request is checked for authority;

[0055] If the parameter value is not within the authority range, response information of no access right is returned; if the parameter value is within the authority range, service forwarding is performed.

[0056] In an alternative embodiment, 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 to the service, an association mapping between the consumer identity and the service is established in the access control list configuration, and the parameter permission list of the consumer is set to include:

[0057] Receiving a service registration request and parsing the parameter permission check identifier therein; determining whether to enable parameter permission check based on the parameter permission check identifier; when parameter permission check is enabled, generating an access control list configuration template containing an input parameter configuration area and an output parameter configuration area, and assigning a globally unique configuration identifier to the access control list configuration template; writing the globally unique configuration identifier into the metadata of the service to complete the binding of the access control list configuration and the service;

[0058] Receiving a parameter permission application of a consumer for the service; obtaining the globally unique configuration identifier from the metadata of the service; locating the corresponding access control list configuration template based on the globally unique configuration identifier; setting the input parameter access range of the consumer in the input parameter configuration area of the access control list configuration template, and setting the output parameter access range of the consumer in the output parameter configuration area; generating a mapping relationship record containing the consumer identity and the service identity; writing the mapping relationship record into the mapping area of the access control list configuration to set the parameter permission list of the consumer.

[0059] Illustratively, in the gateway service registration stage, when a service provider registers a service with the gateway, the gateway receives the service registration request and parses the metadata information contained in the request, from which the parameter permission check identifier is extracted. This identifier can be a Boolean value, such as "parameterPermissionCheck=true" indicating that parameter permission check is enabled, and "parameterPermissionCheck=false" indicating that it is not enabled. The gateway determines whether to create a parameter-level access control list configuration for the service according to the identifier. If the parameter permission check identifier is "true", the gateway generates an access control list configuration template, which contains an input parameter configuration area and an output parameter configuration area.

[0060] When generating the access control list configuration template, the gateway system generates a globally unique configuration identifier for the configuration template using a UUID algorithm, such as "acl-config-7e9f8g7h-6j5k-4l3m-2n1o-0p9q8r7s6t5u". The input parameter configuration area is used to set the range of request parameters accessible by the consumer in the future, and its data structure is in the form of key-value pairs, with the key being the consumer identifier and the value being the list of parameter names allowed to access; the output parameter configuration area also uses the key-value pair structure to set the range of response parameters that the consumer can obtain. The configuration template also contains a mapping area for storing the association between the consumer identifier and the service identifier.

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

[0062] In the permission application phase, when the consumer needs to access a certain service, it submits a service access permission application to the gateway. The application contains the consumer identifier (such as "consumer-9s8d7f-6g5h-4j3k"), the target service identifier (such as "payment-service-v1"), and the parameter permission application information. The parameter permission application information lists in detail the input parameters that the consumer wants to access and the output parameters that the consumer wants to obtain. For example, the consumer may apply to access the "userId", "amount" input parameters of the payment service, and the "transactionId", "status" output parameters, but does not need to access sensitive parameters such as "cardDetails" or "userAddress".

[0063] The gateway receives the parameter permission application, and obtains a globally unique configuration identifier from the metadata of the target service. Using the identifier, the gateway searches for the corresponding access control list configuration template in the configuration database. After finding the template, the gateway sets the input parameter access range for the consumer in the input parameter configuration area of the configuration template according to the consumer's application 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 output parameter access range of the consumer.

[0064] After completing the parameter permission setting, the gateway generates a mapping relationship record containing the consumer identifier and the service identifier, such as "{consumerId: 'consumer-9s8d7f-6g5h-4j3k', serviceId: 'payment-service-v1'}". The gateway writes the mapping relationship record to the mapping area of the access control list configuration to establish the association between the consumer and the service. This mapping relationship enables the gateway to quickly confirm whether the request initiator has the right to access the target service when receiving a service request.

[0065] In the request processing phase, when the gateway receives a service call request initiated by the consumer, it first extracts the consumer identifier and the target service identifier from the request. The gateway checks the mapping area of the access control list configuration to verify whether the consumer has the right to access the service. If the verification is passed, the gateway further parses the input parameter list from the request and compares it with the input parameter access range of 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.

[0066] If the input parameter verification is passed, the gateway forwards the request to the backend service. When receiving the service response, the gateway filters the response data according to the output parameter access range of the consumer. For example, if the consumer only has the right to access "transactionId" and "status", but the response also contains "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 can ensure that the consumer can only obtain the data fields authorized by it.

[0067] This parameter-level fine-grained permission management mechanism enables service providers to accurately control the access permissions of different consumers to service parameters, effectively protecting sensitive data security, while meeting the differentiated access needs of different consumers.

[0068] 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.

[0069] 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;

[0070] 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;

[0071] 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.

[0072] like Figure 2 As shown, the method includes:

[0073] 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".

[0074] 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.

[0075] 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.

[0076] 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.

[0077] 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".

[0078] 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.

[0079] 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}.

[0080] 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.

[0081] 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.

[0082] 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:

[0083] 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;

[0084] 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.

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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".

[0093] 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".

[0094] 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".

[0095] 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".

[0096] 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.

[0097] 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]".

[0098] 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".

[0099] 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.

[0100] 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.

[0101] 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.

[0102] 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:

[0103] Extract the token string from the service access request; parse the token string to obtain the signature algorithm identifier and the consumer identity identifier;

[0104] 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;

[0105] 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.

[0106] 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.

[0107] 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).

[0108] 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.

[0109] 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".

[0110] 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.

[0111] 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.

[0112] 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.

[0113] 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.

[0114] 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".

[0115] 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.

[0116] 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.

[0117] 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.

[0118] 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.

[0119] 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:

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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.

[0124] 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".

[0125] 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=".

[0126] 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.

[0127] 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-----".

[0128] 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.

[0129] 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 (.).

[0130] 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".

[0131] 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.

[0132] 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.

[0133] 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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] The present invention provides a parameter value permission authentication system, comprising:

[0138] 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.

[0139] 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.

[0140] 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.

[0141] 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.

[0142] 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.

[0143] A third aspect of the embodiments of the present invention,

[0144] An electronic device is provided, comprising:

[0145] processor;

[0146] Memory used to store processor-executable instructions;

[0147] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0148] Fourth aspect of the present invention,

[0149] A computer-readable storage medium is provided, having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0150] 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.

[0151] 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 therein. Such 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 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 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 access control list 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 access control list configuration, and sets the consumer's parameter permission list. 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.

2. 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.

3. The method according to claim 2, 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.

4. 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.

5. The method according to claim 4, characterized in that, Based on the signature algorithm identifier, the corresponding signature verification public key is obtained 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.

6. A request parameter value authorization system, used to implement the method as described in any one of claims 1-5, 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.

7. 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 5.

8. 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 5.

Images