Method for requesting and granting access rights, related device and computer program product

Abstract

This application provides a method, related apparatus, and computer program product for requesting access rights. The application generates, in response to receiving a verification assistance request for a second device from a trusted device, verification assistance information for the second device, wherein the first device has access rights to the second device; sends the verification assistance information to the trusted device; controls the trusted device to locally combine the verification assistance information with the trusted device's signature information to generate combined verification information; and controls the trusted device to request access rights from the second device based on the combined verification information. This reduces the difficulty of providing verification information for requesting access rights and improves the efficiency of verifying and granting access rights, while ensuring access security.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method and apparatus for requesting and granting access rights, an electronic device, a computer-readable medium, and a computer program product. Background Art

[0002] As society develops, computer technology is also advancing. Within this context, access authorization and data security have become core issues in modern computer systems and networks. Device managers and users often manage and control communications between devices by setting and granting access rights.

[0003] Access rights are mechanisms that restrict access to certain information items or controls based on a user's identity and membership in various predefined groups. Access control is typically used by system administrators to control user access to network resources (such as servers, directories, and files) and is typically implemented by granting permissions to users and groups to access specific objects. For example, a device may only be accessible to devices that have been granted access rights, thereby preventing "unfamiliar devices" from accessing it and potentially posing a data risk.

[0004] In this context, how to improve the security performance of granting access rights, as well as how to improve the efficiency of granting access rights and facilitate users to complete the verification and authorization process more quickly are worthy of attention and urgent needs. Summary of the Invention

[0005] Multiple aspects of the present application provide a method, device, electronic device, computer-readable storage medium, and computer program product for requesting and granting access rights, which can reduce the difficulty of providing verification information for requesting access rights and improve the efficiency of verifying and granting access rights while ensuring access security.

[0006] In one aspect of the present application, a method for requesting access rights is provided, which is applied to a first device, comprising: in response to receiving a verification assistance request for a second device sent by a trusted device, generating verification assistance information for the second device, wherein the first device has access rights to the second device; sending the verification assistance information to the trusted device; controlling the trusted device to locally combine the verification assistance information and signature information of the trusted device to generate combined verification information; and controlling the trusted device to request access rights from the second device based on the combined verification information.

[0007] Another aspect of the present application provides a method for granting access rights, which is applied to a second device, including: receiving an access rights request sent by a target device based on combined verification information, wherein the combined verification information is generated by the target device based on verification auxiliary information generated by a first device and signature information of the target device, and the first device has access rights to the second device; in response to the combined verification information being able to meet local verification requirements, authorizing the target device to access the local area.

[0008] Another aspect of the present application provides an apparatus for requesting access rights, which is applied to a first device and includes: a verification auxiliary information generation module, configured to generate verification auxiliary information for the second device in response to receiving a verification auxiliary request for the second device sent by a trusted device, wherein the first device has access rights to the second device; a verification auxiliary information sending module, configured to send the verification auxiliary information to the trusted device; a verification information generation control module, configured to control the trusted device to locally combine the verification auxiliary information and the signature information of the trusted device to generate combined verification information; and an access rights request control module, configured to control the trusted device to request access rights from the second device based on the combined verification information.

[0009] Another aspect of the present application provides an apparatus for granting access rights, which is applied to a second device and includes: a grant request receiving module, configured to receive an access rights request sent by a target device based on combined verification information, wherein the combined verification information is generated by the target device based on verification auxiliary information generated by a first device and signature information of the target device, and the first device has access rights to the second device; an access rights granting module, configured to authorize the target device to access the local area in response to the combined verification information being able to meet local verification requirements.

[0010] Another aspect of the present application provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method for requesting access rights and / or the method for granting access rights as provided above.

[0011] In another aspect of the present application, a computer-readable storage medium is provided, on which computer program instructions are stored. The computer program instructions can be executed by a processor to implement the method for requesting access rights and / or the method for granting access rights as provided above.

[0012] In another aspect of the present application, a computer program product includes a computer program having computer program instructions stored thereon. When the computer program is executed by a processor, the computer program can implement the method for requesting access permission and / or the method for granting access permission as provided above.

[0013] In the solution provided by an embodiment of the present application, in response to receiving a verification assistance request for a second device sent by a trusted device, verification assistance information for the second device is generated, wherein the first device has access rights to the second device; the verification assistance information is sent to the trusted device; the trusted device is controlled to locally combine the verification assistance information and the signature information of the trusted device to generate combined verification information; and the trusted device is controlled to request access rights from the second device based on the combined verification information.

[0014] Correspondingly, the second device receives an access permission request sent by the target device based on the combined verification information, wherein the combined verification information is generated by the target device based on the verification auxiliary information generated by the first device and the signature information of the target device, and the first device has access permission to the second device; in response to the combined verification information being able to meet local verification requirements, the target device is authorized to access the local area.

[0015] In this way, while ensuring access security, the difficulty of providing verification information for requesting access rights can be reduced, and the efficiency of verifying and granting access rights can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present application, a brief introduction will be given below to the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0017] Other features, objects and advantages of the present application will become more apparent upon reading the detailed description of non-limiting embodiments made with reference to the following drawings:

[0018] Figure 1 A schematic diagram of a process for requesting access rights provided in an embodiment of the present application;

[0019] Figure 2 A schematic diagram of a process for granting access rights provided in an embodiment of the present application;

[0020] Figure 3 A schematic diagram of a complete process consisting of a process of requesting access rights and a process of granting access rights in an application scenario provided by another embodiment of the present application;

[0021] Figure 4 A schematic diagram of the structure of an apparatus for requesting access rights provided in an embodiment of the present application;

[0022] Figure 5 A schematic diagram of the structure of an apparatus for granting access rights provided in an embodiment of the present application;

[0023] Figure 6 The figure is a schematic diagram of the structure of an electronic device suitable for implementing the solution in the embodiment of the present application.

[0024] The same or similar reference numerals in the drawings represent the same or similar components. DETAILED DESCRIPTION

[0025] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0026] In a typical configuration of the present application, the terminal and the equipment of the service network each include one or more processors (CPUs), input / output interfaces, network interfaces and memories.

[0027] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0028] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology for information storage. The information can be computer program instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc-read only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission medium that can be used to store information that can be accessed by a computing device.

[0029] As discussed above, how to improve the security performance of granting access rights, as well as how to improve the efficiency of granting access rights and facilitate users to complete the verification and authorization process more quickly are worthy of attention and urgent needs.

[0030] In some solutions, the device requested to grant access rights will determine whether to grant access rights to the device requesting access rights based on the historical behavior of the device requesting access rights, device parameter information that can be provided, etc.

[0031] However, in this way, it may be necessary to determine a large amount of parameter information of the devices that can be authorized in the device to which access permission is requested. This not only has a high configuration cost, but may also lead to slow authorization and low quality due to reasons such as incomplete configured parameter information.

[0032] In this regard, an embodiment of the present application provides a method for requesting access rights, which is applied to a first device. The method generates verification assistance information for the second device in response to receiving a verification assistance request for a second device sent by a trusted device, wherein the first device has access rights to the second device; sends the verification assistance information to the trusted device; controls the trusted device to locally combine the verification assistance information and the signature information of the trusted device to generate combined verification information; and controls the trusted device to request access rights from the second device based on the combined verification information.

[0033] Correspondingly, an embodiment of the present application provides a method for granting access rights, which is applied to a second device, and the second device receives an access rights request sent by a target device based on combined verification information, wherein the combined verification information is generated by the target device based on the verification auxiliary information generated by the first device and the signature information of the target device, and the first device has access rights to the second device; in response to the combined verification information being able to meet local verification requirements, the target device is authorized to access the local area.

[0034] In this way, while ensuring access security, the difficulty of providing verification information for requesting access rights can be reduced, and the efficiency of verifying and granting access rights can be improved.

[0035] In actual scenarios, the first device and the second device can be user devices, or devices formed by integrating user devices and network devices via a network, or they can also be applications running on the above devices. User devices include but are not limited to computers, mobile phones, tablets, smart watches, wristbands and other terminal devices. Network devices include but are not limited to network hosts, single network servers, multiple network server sets, or cloud computing-based computer collections. Here, the cloud is composed of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, a virtual computer composed of a group of loosely coupled computers.

[0036] When the execution subject is software, it can be installed in the electronic devices listed above. It can be implemented as multiple software or software modules, or as a single software or software module, and is not specifically limited here.

[0037] It should be understood that in the technical solutions involved in this application, the acquisition, storage, use, processing, transportation, provision and disclosure of user personal information (such as the signature information of the device involved in this application later, etc.) are in compliance with the relevant laws and regulations and do not violate public order and good morals.

[0038] First, please refer to Figure 1 . Figure 1 A process 100 for requesting access rights provided by an embodiment of the present application is shown. The process 100 may be implemented by a first device. The process 100 includes at least the following processing steps:

[0039] (Step) S101: In response to receiving an authentication assistance request for a second device sent by a trusted device, authentication assistance information for the second device is generated.

[0040] For ease of understanding, the first device is described as an "execution subject" for explanation.

[0041] In an embodiment of the present application, the execution subject has access rights to the second device. Accordingly, a trusted device that is trustworthy to the execution subject can utilize or request the execution subject to generate verification auxiliary information for the second device to assist the trusted device in being verified at the second device and requesting access rights to the second device.

[0042] It should be understood that the execution subject, i.e., the first device, can communicate with the second device in advance to obtain the first device's access rights to the second device. Accordingly, the second device can grant the first device access rights to some or all of the content on the second device based on its "trust" in the first device.

[0043] Correspondingly, the first device can similarly communicate with the device to verify the device and determine whether it is a trusted device. If the device is a trusted device, the trusted device can subsequently send a verification assistance request to the execution entity. This verification assistance request can be used to help the second device more efficiently and accurately determine whether to grant access rights to the second device. For example, based on the verification assistance request, the second device can reduce the verification steps and verification content of the device's signature information to improve verification efficiency.

[0044] In some embodiments, the auxiliary verification information may be the status of the second device's access authorization for the first device (e.g., the scope of the access authorization, time validity, etc.), as well as the first device's "trust level" for the trusted device (or, in other words, the first device's access authorization for the trusted device, time validity, etc.). Accordingly, the second device may refer to and determine, based on the verification assistance request, whether to also provide access authorization for the "trusted device," and the scope of content to which the access authorization actually provided points (this scope may be the same as or different from the scope of the second device for the first device).

[0045] S102: Send the verification auxiliary information to the trusted device.

[0046] In an embodiment of the present application, after generating the verification auxiliary information based on the above S101, the execution subject may communicate it to the trusted device requesting the auxiliary information, so that the trusted device may use the verification auxiliary information to request access permission from the second device.

[0047] In some embodiments, to facilitate communication between the trusted device and the execution entity, more efficiently indicate its desire to request verification assistance information, and more efficiently communicate the verification assistance request to the execution entity, the execution entity may pre-configure a target Uniform Resource Locator (URL) corresponding to the second device, that is, configure a target URL. The trusted device can then send a verification assistance request for the second device to the execution entity by accessing the target URL.

[0048] Accordingly, when determining that the target URL has been accessed, the execution entity may determine that a verification assistance request for the second device sent by the trusted device has been received, and in response thereto, generate verification assistance information for the second device.

[0049] Then, the execution entity may choose to generate a Hyper Text Markup Language (HTML) file corresponding to the target uniform resource locator.

[0050] Next, the execution entity may embed the verification auxiliary information into the hypertext markup language file (for example, embed the verification auxiliary information into the hypertext markup language file in the form of an execution script) to obtain the embedded hypertext markup language file.

[0051] Finally, the execution entity provides the verification auxiliary information to the trusted device by sending the embedded HTML file to the trusted device. As a result, the user can conveniently and efficiently obtain the required verification auxiliary information by accessing the URL and receiving the HTML file.

[0052] S103, controlling the trusted device to locally combine the verification auxiliary information and the signature information of the trusted device to generate combined verification information.

[0053] In an embodiment of the present application, after providing verification auxiliary information to a trusted device, the execution subject can control the trusted device to combine the verification auxiliary information and the signature information of the trusted device locally on the trusted device. The signature information may include the device characteristic parameters of the trusted device (for example, the name and model of the hardware device, etc.), the information stored in the network cookies of the trusted device, the user agent (UA) information corresponding to the trusted device, the routing protocol used, etc., which can characterize and indicate the trusted device, and are used to "characterize the identity of the trusted device". Network cookies (also known as cookies) are small files used by web browsers to store and track user information. They are usually a basic component in network development and can implement various functions in user identity management, personalized experience, and session management.

[0054] The trusted device can combine the signature information and the auxiliary verification information locally based on the instructions and control of the execution subject to generate the combined verification information. For example, the trusted device can directly connect the signature information and the auxiliary verification information end to end according to a predetermined combination rule to complete the combination.

[0055] In some embodiments, the verification auxiliary information may also indicate that the signature information should be processed according to specific rules (for example, encrypting the signature information, modifying the signature rules according to a modification method pre-agreed between the first device and the second device). Thus, the verification auxiliary information can be used to "convey" the authorization verification standard of the second device to the trusted device, and adjust the signature information of the trusted device to avoid, for example, preventing the trusted device from being granted access rights by the second device simply due to an error in the expression format, thereby improving authorization efficiency.

[0056] S104: Control the trusted device to request access permission from the second device based on the combined verification information.

[0057] In an embodiment of the present application, after obtaining the combined verification information based on S103 above, the execution entity may control the trusted device to utilize the combined verification information to request access rights from the second device. For example, the execution entity may control the trusted device to send the combined verification information to the second device, requesting the second device to verify and determine whether to grant access rights to the trusted device, and the scope of the access rights to be granted, based on the combined verification information.

[0058] Therefore, the first device that has been verified by the second device and has access rights can be used to assist the device in requesting authorization from the second device. The first device can provide more reference information to the second device to help the second device authorize more accurately and efficiently, while reducing the maintenance cost of the parameters of the available devices in the second device.

[0059] For example, in such an implementation, the signature information of the trusted device can be selectively used partially, or selected to be used only for "archiving" at the second device. For example, the second device can grant access rights to the device after determining that the verification auxiliary information matches the device's signature information and that the signature information corresponds to the verification auxiliary information (or, in other words, that the verification auxiliary information has not been tampered with or misappropriated by other devices), without further verifying whether the signature information is comprehensive or whether the specific content included meets the requirements. In short, the signature information is actually only used to generate the authorization record and complete the "archiving" in this process, rather than providing comprehensive parameters for verification.

[0060] As a result, even if the second device does not maintain some or all of the device parameters of the device, it can still determine whether to grant access rights to it, thereby reducing the difficulty of authorization verification of the second device and improving the efficiency of authorization verification of the second device.

[0061] Subsequently, the method for requesting access rights provided in this application generates, in response to receiving a verification assistance request for a second device from a trusted device, verification assistance information for the second device, wherein the first device has access rights to the second device; sends the verification assistance information to the trusted device; controls the trusted device to locally combine the verification assistance information with the trusted device's signature information to generate combined verification information; and controls the trusted device to request access rights from the second device based on the combined verification information. This reduces the difficulty of providing verification information for requesting access rights while ensuring access security, thereby improving the efficiency of verifying and granting access rights.

[0062] In some embodiments, verification auxiliary information can also be optionally used to provide guidance to the trusted device so that the trusted device can provide signature information in the most concise way possible and in one go to meet the requirements of the second device, thereby avoiding the trusted device providing "useless information" that cannot be read or used by the second device.

[0063] Accordingly, the auxiliary verification information generated by the execution entity may include, based on the difference between the second devices, information items that the signature information should include for the second device. If the auxiliary verification information indicates the information items that the signature information should include, the execution entity may choose to control the trusted device locally on the trusted device to determine the signature information of the trusted device based on the information items that are indicated as required by the auxiliary verification information.

[0064] As discussed above, the required information items may include at least one of the following: device characteristic parameters of the trusted device, cookies of the trusted device, UA information corresponding to the trusted device, and the like.

[0065] In some embodiments, to reduce the operating costs of the second device, the execution entity can also offload at least part of the verification work for the trusted device locally. For example, if the target device to which the execution entity has access requests verification assistance, the execution entity can respond and generate a behavior model for the target device based on the communication and interaction records between the target device and the local device.

[0066] For example, the execution subject may read the access trace of the target device based on the local communication and interaction situation with the target device, and generate a behavior model for the target device.

[0067] Then, the execution subject compares the behavior with the trusted behavior model determined in advance based on the trusted behavior pattern and trusted access trajectory to obtain the corresponding comparison result. If the comparison result indicates that the similarity between the behavior model of the target device and the predetermined trusted behavior model is greater than or equal to the similarity threshold, the execution subject can respond to this and determine the target device as a trusted device. In this way, the execution subject can determine whether the device is trustworthy by locally verifying the historical access and communication behaviors of the device, and only "recommend" trusted devices that meet the trust requirements to the second device. Accordingly, the second device can refer to the verification assistance request to a greater extent, thereby reducing the verification consumption and verification configuration requirements on the second device side.

[0068] In some embodiments, the second device can also choose to communicate with the execution entity to request the execution entity to provide a corresponding behavior model for local analysis. This can provide the second device with a device-specific reference, improve verification quality, and reduce the computing resource consumption of the second device.

[0069] Similarly, the execution entity can also determine whether a device is trustworthy by analyzing and verifying the device's operating environment and other aspects. If the device is determined to be trustworthy, the execution entity can provide it with auxiliary verification information to assist it in verifying and requesting access rights from other devices to which the execution entity has access rights. For example, in some embodiments, the execution entity can also choose to verify the trustworthiness of a device based on the device's signature information.

[0070] In some embodiments, the execution entity, ie, the first device, may also be “specially” configured to audit the device to determine whether the device is trustworthy.

[0071] Then, other devices (eg, second devices) can communicate with each other and share the trusted results of the first device for the device based on their "trust" in the first device, so as to reduce the workload of each second device and improve the efficiency of granting permissions.

[0072] For example, in some scenarios, a first device may be trusted by multiple second devices, allowing it to pre-verify the device's feasibility before the second devices. If the first device deems the device trustworthy, it can use verification-assisted information to mark the device as trusted and synchronize this result with the second device. This allows the second device to more efficiently and easily trust the "trusted device" based on the verification-assisted information, complete verification, and grant access rights.

[0073] For example, the second device may only compare whether the verification auxiliary information corresponds to the device. If the two correspond and the verification auxiliary information has not been misappropriated or tampered with, the device access right is granted based on "trust" in the first device.

[0074] In some embodiments, the auxiliary verification information may also be directly encrypted signature information of a trusted device. This allows the second device to determine whether the auxiliary verification information has been misappropriated or tampered with based on whether the decrypted auxiliary verification information matches the signature information, thereby preventing improper use of the auxiliary verification information that could compromise data security.

[0075] Accordingly, during the execution of step S101, the execution subject may alternatively or additionally select, in response to receiving a verification assistance request for the second device from the trusted device, to obtain the signature information of the trusted device. The execution subject then generates verification assistance information based on the encryption result of the signature information of the trusted device.

[0076] In some embodiments, the encryption operation result may be generated based on an encryption rule predetermined between the execution subject and the second device, thereby enabling the second device to read and obtain the content included therein after receiving the verification auxiliary information in the form of the encryption operation result. For example, the encryption operation result may be based on an encryption rule predetermined between the execution subject and the second device, and may be encrypted using methods such as the Data Encryption Standard (DES), the Triple Data Encryption Algorithm (3DES), the Advanced Encryption Standard (AES), or Hami encryption.

[0077] Accordingly, in such a scenario, when a subsequent trusted device generates combined verification information, it can simply "attach" the decryption operation result after the signature information to complete the combination.

[0078] In some embodiments, in order to improve the security of the verification auxiliary information, the execution entity may also generate the verification auxiliary information in a random manner. In some embodiments, the verification auxiliary information is a string randomly generated by the execution entity. For example, the execution entity may randomly generate a string for the verification auxiliary request of a trusted device to serve as an auxiliary (for example, only used to indicate to the second device that the device has the access rights authorized by the first device). In such a case, the execution entity may synchronize the verification auxiliary information to the second device to indicate that the device that first holds the string requesting access rights is trustworthy. In this way, the verification auxiliary information can be prevented from being "misappropriated" and affecting data security.

[0079] In some embodiments, the verification auxiliary information may also be configured with a valid usage time interval, and if the verification auxiliary information exceeds the valid usage time interval, the verification auxiliary information will be invalidated, thereby further improving security.

[0080] Based on any of the above embodiments, the execution entity can also control the second device to grant access rights to the trusted device when the combined verification information meets the local verification requirements of the second device, and write the access rights to the cookie of the trusted device. Thus, with the assistance of the execution entity in providing the initial authorization request, if the trusted device is able to pass the verification and be granted access rights, the trusted device can subsequently continuously and continuously obtain access rights to the second device based on its cookie. In this way, the execution entity can be used to assist the second device in quickly completing the verification of granting access rights to the device.

[0081] In some embodiments, when the executing entity determines that the trusted device has been granted access rights by the second device, it can also control the trusted device to clear the verification auxiliary information used to reduce the local storage pressure of the trusted device while avoiding the verification auxiliary information from being erroneously leaked and affecting data security.

[0082] Further, you can refer to Figure 2 . Figure 2 A process 200 for granting access rights provided by an embodiment of the present application is shown. The process 200 may be implemented by a second device. The process 200 includes at least the following processing steps:

[0083] S201: Receive an access permission request sent by a target device based on combined verification information.

[0084] In an embodiment of the present application, as discussed above, when the target device (i.e., the "trusted device" for the first device discussed above) wishes to request access rights for the second device, it may send an access rights request to the second device based on the combined verification information.

[0085] As discussed above, the combined verification information may be generated locally by the target device based on verification auxiliary information generated by the first device having access rights to the second device and signature information of the target device.

[0086] S202 : In response to the combined verification information being able to meet the local verification requirement, authorize the target device to access the local area.

[0087] In an embodiment of the present application, after receiving the combined verification information, the second device may determine whether the combined verification information meets local verification requirements. For example, the format and content included in the combined verification information (for example, whether all information items required in the signature information are present, whether the content indicated by the information items is on the "blacklist", etc.) and whether they meet the predetermined access permission granting criteria set by the second device are met.

[0088] As discussed above, the verification requirement is actually related to the "trust level" of the second device in the first device, and the form of the verification auxiliary information.

[0089] For example, in a scenario where the second device is "completely trusted" to the first device, if the purpose of the verification auxiliary information is to prove the trusted device's access rights to the first device, and the device is trusted to the first device, if the first device expects the second device to directly grant access rights to the device, the second device can choose to confirm that the verification is successful and authorize access rights to the device accordingly when it is determined that the verification auxiliary information matches the signature information of the device and the signature information corresponds to the verification auxiliary information.

[0090] For another example, if the verification auxiliary information is obtained from the encrypted signature information of the target device, the second device may also decrypt the verification auxiliary information and determine whether the decrypted result matches the signature information of the target device. If so, the second device determines that the target device meets the local verification requirements.

[0091] For example, if the auxiliary authentication information is a randomly generated string, the second device can detect whether the string in the combined authentication information is the same as the string previously communicated by the first device. If so, and if the target device is the first device to possess the string, the second device determines that the target device meets local authentication requirements.

[0092] In some embodiments, as discussed above, the second device may at least refer to the access permissions between the first device and the second device when granting access permissions to the target device. For example, the second device may use the range of access permissions between the first device and the second device as an upper limit. For example, the second device may only determine the interfaces to grant access permissions to the target device within the range of interfaces that the first device is allowed to access.

[0093] Similarly, after the second device grants access rights to the target device, it can record the corresponding permission in the cookie of the target device to achieve continuous and long-term access authorization, which will not be repeated here.

[0094] In some embodiments, for the same signature information in the second device, when verification auxiliary information exists, the second device may choose a simpler and more efficient method to implement verification compared to when no verification auxiliary information exists.

[0095] For example, the second device can choose to verify authorized access based solely on the validity and authenticity of the auxiliary verification information. If the auxiliary verification information is valid and matches the device's signature information, the second device can directly grant access to the target device and "archive" the target device's signature information. In this way, the second device can use the "trustworthiness" of the first device with local access rights to assist the local access authorization verification process, improving the efficiency of the verification process.

[0096] Then, the method for granting access rights provided by this application receives an access rights request sent by a target device based on combined verification information, wherein the combined verification information is generated by the target device based on verification auxiliary information generated by a first device and the signature information of the target device, and the first device has access rights to a second device; in response to the combined verification information being able to meet local verification requirements, the target device is granted access rights to the local area. In this way, other devices that have been granted access rights can be used to provide auxiliary information and reference information, so that access rights can be granted to the device requesting access rights more accurately and efficiently using the auxiliary information and reference information.

[0097] To deepen understanding, this application also provides a specific implementation solution in combination with a specific application scenario, for which please refer to the figure. Figure 3 The complete process 300 provided by the embodiment of the present application, which consists of a process of requesting access rights and a process of granting access rights, is shown.

[0098] In process 300, devices 310, 310, and 330 may be involved. Device 310 is trusted by device 320, that is, device 310 is a trusted device for device 320. Device 320 has access rights corresponding to device 330. Process 300 is described exemplarily in the case where device 310 requests and desires to obtain access rights to device 330.

[0099] In the process 300 , the device 310 may execute S301 to send an authentication assistance request for the device 330 to the device 320 .

[0100] Accordingly, because 310 is a trusted device of device 320 , upon receiving the verification assistance request, device 320 executes S302 and generates verification assistance information 325 for device 330 .

[0101] Then, the device 320 executes S303 and sends the verification auxiliary information 325 to the device 310 .

[0102] Next, the device 310 may execute S304 locally (eg, controlled by the device 320 ), and combine the signature information 315 of the device 310 and the verification auxiliary information 325 to obtain combined verification information 345 .

[0103] Then, the device 310 may execute S305 to send the combined verification information 345 to the device 330 for verification and requesting access rights of the device 310 to the device 330 (eg, controlled by the device 320 ).

[0104] Accordingly, after receiving the combined verification information 345 , the device 330 may verify it to determine whether the combined verification information 345 can meet local verification requirements.

[0105] Exemplarily, if it is determined that the combined verification information 345 can meet the local verification requirements, the device 330 can correspondingly generate access permission information 355 and execute S306 to write the access permission information 355 into the cookie 317 of the device 310 to complete the process of granting access permission to the device 310.

[0106] The embodiment of the present application also provides a device for requesting access rights, the structure of which is as follows: Figure 4 The apparatus 400 shown can be applied to a first device. The apparatus 400 includes: a verification assistance information generation module 410, configured to generate verification assistance information for the second device in response to receiving a verification assistance request for the second device sent by a trusted device, wherein the first device has access rights to the second device; a verification assistance information sending module 420, configured to send the verification assistance information to the trusted device; a verification information generation control module 430, configured to control the trusted device to locally combine the verification assistance information and the signature information of the trusted device to generate combined verification information; and an access rights request control module 440, configured to control the trusted device to request access rights from the second device based on the combined verification information.

[0107] In some embodiments, the verification auxiliary information generation module includes: a signature information acquisition sub-module, configured to obtain the signature information of the trusted device in response to receiving a verification assistance request for the second device sent by the trusted device; and a verification auxiliary information generation sub-module, configured to generate verification auxiliary information based on the encryption operation result of the signature information of the trusted device.

[0108] In some embodiments, the verification auxiliary information indicates the information items that the signature information should have, and the device 400 also includes: a signature information determination control module, which is configured to control the trusted device to determine the signature information of the trusted device locally on the trusted device based on the information items that should be indicated by the verification auxiliary information, wherein the information items that should be included include at least one of the following: device characteristic parameters of the trusted device, network cookies of the trusted device, and user agent information corresponding to the trusted device.

[0109] In some embodiments, the apparatus 400 further includes: a behavior model generation module, configured to generate a behavior model for the target device based on the communication record between the target device and the local device in response to receiving a verification assistance request sent by the target device; and a trusted device determination module, configured to determine the target device as a trusted device in response to the similarity between the behavior model and a predetermined trusted behavior model being greater than or equal to a similarity threshold.

[0110] In some embodiments, the verification auxiliary information is a randomly generated string, and 400 further includes: a verification auxiliary information synchronization module configured to synchronize the verification auxiliary information to the second device to indicate that the second device is a trustworthy device that first holds the string to request access rights.

[0111] In some embodiments, the verification assistance request includes an access request for a target uniform resource locator, and the verification assistance information sending module includes: a return file generation sub-module, configured to generate a hypertext markup language file corresponding to the target uniform resource locator; a verification assistance information embedding sub-module, configured to embed the verification assistance information into the hypertext markup language file to obtain the embedded hypertext markup language file; and a verification assistance information sending sub-module, configured to send the embedded hypertext markup language file to a trusted device.

[0112] In some embodiments, the apparatus 400 further includes an authorization information writing control module configured to control the second device to write access permission information into the network cookie of the trusted device in response to the combined verification information satisfying the local verification requirements of the second device.

[0113] The embodiment of the present application also provides a device for granting access rights, the structure of which is as follows: Figure 5 The illustrated apparatus 500 can be applied to a second device. Apparatus 500 includes: a granting request receiving module 510 configured to receive an access permission request sent by a target device based on combined verification information, where the combined verification information is generated by the target device based on verification auxiliary information generated by a first device and signature information of the target device, indicating that the first device has access permission to the second device; and an access permission granting module 520 configured to grant the target device local access permission in response to the combined verification information satisfying local verification requirements.

[0114] Based on the same inventive concept, an electronic device, a readable storage medium, and a computer program product are also provided in an embodiment of the present application. The method corresponding to the electronic device may be the method for requesting access rights in the aforementioned embodiment, and its principle of solving the problem is similar to that of the aforementioned embodiment. The electronic device provided in an embodiment of the present application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the methods and / or technical solutions of the aforementioned multiple embodiments of the present application.

[0115] An electronic device can be a user device, or a device formed by integrating a user device and a network device via a network, or an application running on any of the above devices. User devices include, but are not limited to, computers, mobile phones, tablets, smart watches, wristbands, and other terminal devices. Network devices include, but are not limited to, network hosts, single network servers, multiple network server clusters, or cloud computing-based computer clusters, and can be used to implement some of the processing functions required for setting an alarm. Here, the cloud is composed of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computers.

[0116] Figure 6 The structure of an electronic device suitable for implementing the method and / or technical solution in the embodiment of the present application is shown. The electronic device 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 602 or the program loaded from the storage part 608 into the random access memory (RAM) 603. In RAM 603, various programs and data required for system operation are also stored. CPU 601, ROM 602 and RAM 603 are connected to each other through a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0117] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, a touch screen, a microphone, an infrared sensor, etc.; an output section 607 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), an LED display, an OLED display, etc., and a speaker; a storage section 608 including one or more computer-readable media such as a hard disk, an optical disk, a magnetic disk, a semiconductor memory, etc.; and a communication section 609 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet.

[0118] In particular, the methods and / or embodiments in the embodiments of the present application can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes program code for executing the method shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 601, the above-mentioned functions defined in the method of the present application are performed.

[0119] Another embodiment of the present application further provides a computer-readable storage medium and a computer program product, on which computer program instructions are stored. The computer program instructions can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of the present application.

[0120] Specifically, the present embodiment can adopt any combination of one or more computer-readable media.Computer-readable media can be computer-readable signal media or computer-readable storage media.Computer-readable storage media can be, for example, systems, devices or components including but not limited to electricity, magnetism, light, electromagnetic, infrared, or semiconductors, or any combination thereof.More specific examples (non-exhaustive list) of computer-readable storage media include: electrical connections with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROMs), optical storage devices, magnetic storage devices, or any suitable combination thereof.In this document, computer-readable storage media can be any tangible medium containing or storing a program that can be used by an instruction execution system, device or device or used in combination with it.

[0121] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0122] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0123] The computer program code for performing the operations of the present application can be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0124] The flow chart or block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the equipment, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code include one or more executable instructions for realizing the logical function of the specification. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented with a dedicated system for hardware that performs the function or operation of the specification, or can be implemented with a combination of dedicated hardware and computer instructions.

[0125] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0126] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of modules and units is only a logical function division. There may be other division methods in actual implementation. For example, with units as an example, for example, multiple units or page components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0127] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0128] In addition, the functional modules and units in the various embodiments of the present application may be integrated into a single processing module or unit, or each module or unit may exist physically separately, or two or more units may be integrated into a single module or unit. The aforementioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional modules or units.

[0129] The above-mentioned integrated modules and units implemented in the form of software functional modules and units can be stored in a computer-readable storage medium. The above-mentioned software functional modules and units are stored in a storage medium, including a number of instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) or a processor to execute some steps of the methods of each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc., various media that can store program code.

[0130] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

[0131] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device through software or hardware. Terms such as "first" and "second" are used to indicate names and do not imply any particular order.

Claims

1. A method for requesting access rights, applied to a first device, characterized in that: include: In response to receiving a verification assistance request for a second device sent by a trusted device, obtaining signature information of the trusted device; generating verification auxiliary information based on an encryption operation result of the signature information of the trusted device, wherein the first device has access rights to the second device; Sending the verification auxiliary information to the trusted device; Control the trusted device to combine the verification auxiliary information and the signature information of the trusted device locally on the trusted device to generate combined verification information; The trusted device is controlled to request access permission from the second device based on the combined verification information.

2. The method according to claim 1, characterized in that The verification auxiliary information indicates the information items that the signature information should have, and also includes: Control the trusted device locally on the trusted device to determine the signature information of the trusted device based on the information items that should be present as indicated by the verification auxiliary information, wherein the information items that should be present include at least one of the following: device characteristic parameters of the trusted device, network cookies of the trusted device, and user agent information corresponding to the trusted device.

3. The method according to claim 1, characterized in that Also includes: In response to receiving a verification assistance request sent by a target device, generating a behavior model for the target device based on communication records between the target device and a local device; In response to the similarity between the behavior model and a predetermined trusted behavior model being greater than or equal to a similarity threshold, the target device is determined to be the trusted device.

4. The method according to claim 1, wherein The verification auxiliary information is a randomly generated string and also includes: The verification auxiliary information is synchronized to the second device to indicate that the second device is a trustworthy device that first holds the character string to request access rights.

5. The method according to claim 1, characterized in that The verification assistance request includes an access request for a target uniform resource locator, and the sending of the verification assistance information to the trusted device includes: generating a hypertext markup language document corresponding to the target uniform resource locator; Embedding the verification auxiliary information into the hypertext markup language file to obtain an embedded hypertext markup language file; The embedded hypertext markup language file is sent to the trusted device.

6. The method according to any one of claims 1 to 5, characterized in that Also includes: The second device is controlled to write access permission information into the network cookie of the trusted device in response to the combined verification information satisfying a local verification requirement of the second device.

7. A method for granting access rights, applied to a second device, characterized in that: include: receiving an access permission request sent by a target device based on combined verification information, wherein the combined verification information is generated by the target device based on verification auxiliary information generated by a first device and signature information of the target device, the first device having access permission to the second device, and when the target device is a trusted device, the first device acquiring the signature information in response to receiving the verification auxiliary request sent by the target device for the second device; generating the verification auxiliary information based on the encryption operation result of the signature information; In response to the combined authentication information being able to satisfy the local authentication requirement, the target device is authorized to access the local area.

8. A device for requesting access rights, applied to a first device, characterized in that: include: a verification assistance information generation module, configured to obtain signature information of the trusted device in response to receiving a verification assistance request for a second device sent by the trusted device; generating verification auxiliary information based on an encryption operation result of the signature information of the trusted device, wherein the first device has access rights to the second device; a verification auxiliary information sending module, configured to send the verification auxiliary information to the trusted device; A verification information generation control module is configured to control the trusted device to combine the verification auxiliary information and the signature information of the trusted device locally on the trusted device to generate combined verification information; The access permission request control module is configured to control the trusted device to request access permission from the second device based on the combined verification information.

9. A device for granting access rights, applied to a second device, characterized in that: include: a grant request receiving module configured to receive an access permission request sent by a target device based on combined verification information, wherein the combined verification information is generated by the target device based on verification auxiliary information generated by a first device and signature information of the target device, the first device having access permission to the second device, and when the target device is a trusted device, the first device, in response to receiving the verification auxiliary request sent by the target device for the second device, obtains the signature information; and generates the verification auxiliary information based on a cryptographic operation result of the signature information; The access permission granting module is configured to authorize the target device to access the local area in response to the combined verification information being able to meet the local verification requirement.

10. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 7.

11. A computer-readable medium, characterized in that Computer program instructions are stored thereon, and the computer program instructions can be executed by a processor to implement the method according to any one of claims 1 to 7.

12. A computer program product, characterized in that The invention comprises a computer program which, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images