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

Abstract

The invention provides a method for requesting access authority, a related device and a computer program product, the application generates verification auxiliary information for second equipment in response to receiving a verification auxiliary request for the second equipment sent by trusted equipment, and the first equipment has access authority to the second equipment; sending the verification auxiliary information to the trusted device; controlling the trusted device to combine the verification auxiliary information and the signature information of the trusted device locally in the trusted device to generate combined verification information; and controlling the trusted device to request the access permission from the second device based on the combined verification information. Therefore, on the basis of ensuring the access security, the providing difficulty of the verification information for requesting the access permission can be reduced, and the verification and granting efficiency of the access permission can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method and device 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. In 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 the communication between devices by setting and granting access rights.

[0003] Access rights refer to the mechanism of limiting access to certain information items or certain controls based on the user's identity and membership in various predefined groups. Access control is usually used by system administrators to control user access to network resources (such as servers, directories, and files), and is usually implemented by granting users and groups access to specific objects. For example, for a device, it only allows other devices that have been granted access rights to access it, thereby avoiding "strange devices" from accessing it and causing data risks.

[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 on the basis of 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, and includes: 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, and includes: 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 have local access rights.

[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 assistance information generation module, configured to generate verification assistance information for a 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; a verification assistance information sending module, configured to send the verification assistance information to the trusted device; a verification information generation control module, 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, 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 method for requesting access permission and / or the method for granting access permission provided above can be implemented.

[0013] In the solution provided by the 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] As a result, it is possible to reduce the difficulty of providing verification information for requesting access rights while ensuring access security, thereby improving the efficiency of verifying and granting access rights. 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 the description 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 paying any creative labor.

[0017] Other features, objects and advantages of the present application will become more apparent by 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 a device for requesting access rights provided in an embodiment of the present application;

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

[0023] Figure 6 The present invention 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] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work 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 (CPU), input / output interface, network interface and memory.

[0027] The 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. The memory is an example of a computer-readable medium.

[0028] Computer readable media include permanent and non-permanent, removable and non-removable media, and can be implemented by any method or technology to store information. Information can be computer program instructions, data structures, modules of programs 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, read-only compact disk (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission media 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 be granted 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, the 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 devices that are requested to grant access rights. 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 also provides a method for granting access rights, which is applied to a second device, wherein 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 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, the target device is authorized to access the local area.

[0034] As a result, it is possible to reduce the difficulty of providing verification information for requesting access rights while ensuring access security, thereby improving the efficiency of verifying and granting access rights.

[0035] In actual scenarios, the first device and the second device may be user devices, or devices formed by integrating user devices and network devices through a network, or may be applications running on the above devices. User devices include but are not limited to various terminal devices such as computers, mobile phones, tablet computers, smart watches, and bracelets. Network devices include but are not limited to network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets. Here, the cloud is composed of a large number of hosts or network servers based on cloud computing, where cloud computing is a type of distributed computing, a virtual computer composed of a group of loosely coupled computer sets.

[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 no specific limitation is made 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 illustration.

[0041] In an embodiment of the present application, the execution subject has access rights to the second device. Accordingly, a trusted device that is trusted by the execution subject can utilize and 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, that is, 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 part or all of the content in 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 the device is a trusted device. If the device is a trusted device, the trusted device can subsequently send a verification assistance request to the execution subject. The 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, the second device can reduce the verification steps and verification content of the device's signature information based on the verification assistance request to improve verification efficiency.

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

[0045] S102, sending the verification auxiliary information to a trusted device.

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

[0047] In some embodiments, in order to facilitate the communication between the trusted device and the execution subject, more efficiently indicate its expectation to request verification assistance information, and more efficiently communicate the verification assistance request to the execution subject, the execution subject may configure a target uniform resource locator (URL) corresponding to the second device in advance, that is, configure a target URL. Then, the trusted device can send a verification assistance request for the second device to the execution subject by accessing the target URL.

[0048] Accordingly, when determining that the target URL has been accessed, the execution subject 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 subject may choose to generate a Hyper Text Markup Language (HTML) file corresponding to the target uniform resource locator.

[0050] Next, the execution subject 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 subject provides the verification auxiliary information to the trusted device by sending the embedded hypertext markup language file to the trusted device. Therefore, for the user, he 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 device characteristic parameters of the trusted device (e.g., the name and model of the hardware device, etc.), 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 is used to "characterize the identity of the trusted device". Related information. 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 multiple functions in user identity management, personalized experience, and session management.

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

[0055] In some embodiments, the verification auxiliary information may also indicate that the signature information is processed according to specific rules (for example, the signature information is encrypted, and the signature rules are modified according to the modification method pre-agreed by 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 the signature information of the trusted device can be adjusted to avoid, for example, preventing the trusted device from being granted access rights by the second device simply because of an incorrect expression, 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 the above S103, the execution subject can control the trusted device to use the combined verification information to request access rights from the second device. For example, the execution subject can control the trusted device to send the combined verification information to the second device to request the second device to verify and determine whether to grant access rights to the trusted device and the scope of granting access rights 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 a trusted device can be selected to be partially used, or selected to be used only for "archiving" at the second device. For example, the second device can grant access rights to the device when it determines that the verification auxiliary information matches the signature information of the device, and the signature information corresponds to the verification auxiliary information (or in other words, the verification auxiliary information has not been tampered with or misappropriated by other devices), without verifying in detail whether the signature information is comprehensive, or whether the specific content included meets the requirements, etc. In short, the signature information is actually only used to generate authorization records and complete "archiving" in this process, rather than providing comprehensive parameters for verification.

[0060] As a result, even if the second device does not maintain part 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] Then, the method for requesting access rights provided by the present application generates auxiliary verification information for the second device in response to receiving an auxiliary verification request for the second device sent by a trusted device, wherein the first device has access rights to the second device; sends the auxiliary verification information to the trusted device; controls the trusted device to combine the auxiliary verification information and the signature information of the trusted device locally to generate combined verification information; controls the trusted device to request access rights from the second device based on the combined verification information. In this way, on the basis of ensuring access security, it is possible to reduce the difficulty of providing verification information for requesting access rights and improve 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 verification auxiliary information generated by the execution subject may include information items that the signature information should have for the second device at this time based on the difference of the second device. In the case where the verification auxiliary information indicates the information items that the signature information should have, the execution subject may choose to control the trusted device locally on the trusted device and determine the signature information of the trusted device based on the information items that should be indicated by the verification auxiliary 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, in order to reduce the operating cost of the second device, the execution subject can also share at least part of the verification work for the trusted device locally. For example, for a target device that can be accessed by the execution subject, when the target device requests to provide a verification assistance request, the execution subject can respond to this and generate a behavior model for the target device based on the communication and interaction records between the target device and the local.

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

[0067] Then, the execution subject can compare 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. Thus, 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 may also choose to communicate with the execution subject to request the execution subject to provide a corresponding behavior model for local analysis, thereby providing a device-specific reference for the second device, improving the verification quality, and reducing the computing resource consumption of the second device.

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

[0070] In some embodiments, the execution subject, 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 and share the trusted results of the first device for the device based on "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, the first device may be trusted by multiple second devices, so that it can be used to pre-check the feasibility of the device before the second device. If the first device believes that the device is trustworthy, it can use the verification auxiliary information to mark the trusted device and synchronize the result to the second device, so that the second device can trust the "trusted device" more efficiently and conveniently based on the verification auxiliary information, complete the verification, and grant access rights.

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

[0074] In some embodiments, the content of the verification auxiliary information may also be directly the signature information of the trusted device in encrypted form. Therefore, the second device can subsequently determine whether the verification auxiliary information has been "misappropriated" or "tampered with" based on whether the decrypted verification auxiliary information matches the content recorded in the signature information, so as to avoid improper use of the verification auxiliary information and affect data security.

[0075] Accordingly, when the execution subject performs S101, for example, it may alternatively or additionally select to obtain the signature information of the trusted device in response to receiving the verification assistance request for the second device sent by the trusted device. Then, the execution subject generates verification assistance information based on the encryption operation result of the signature information of the trusted device.

[0076] In some embodiments, the encryption operation result can be generated based on the encryption rules predetermined between the execution subject and the second device, so that the second device can 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 can be based on the encryption rules predetermined between the execution subject and the second device, and can be encrypted based on the Data Encryption Standard (DES), Triple Data Encryption Algorithm (3DES), Advanced Encryption Standard (AES), Hami encryption, etc.

[0077] Accordingly, in such a scenario, when subsequently generating combined verification information, the trusted device can simply "mount" 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 subject 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 subject. For example, the execution subject may randomly generate a string for the verification auxiliary request of a trusted device to be used 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 subject may synchronize the verification auxiliary information to the second device to indicate that the device that first holds the string to request 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 when the verification auxiliary information exceeds the constraint of the valid usage time interval, the verification auxiliary information is invalidated, thereby further improving security.

[0080] On the basis of any of the above embodiments, the execution subject 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 into the cookie of the trusted device. Thus, with the assistance of the execution subject in the first authorization request, if the trusted device can pass the verification and be granted access rights, the trusted device will subsequently continuously and continuously obtain the access rights of the second device based on its cookie. Thus, the execution subject can be used to assist the second device to quickly complete 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, please 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, receiving an access rights 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] The combined verification information, as discussed above, 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 authentication information being able to satisfy the local authentication requirement, authorizing 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 can determine whether the combined verification information can meet the local verification requirements. For example, the form and content included in the combined verification information (for example, whether the information items that should be included in the signature information are complete, whether the content indicated by the information items is in the "blacklist", etc.), whether it meets the access permission granting standards set by the predetermined second device, etc.

[0088] As discussed above, the authentication requirement is actually related to the "trust level" of the second device to the first device, and the form of the authentication 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, in the case where 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 they match, the second device determines that the target device can meet the local verification requirements.

[0091] For example, in the case where the verification auxiliary information is a randomly generated string, the second device can detect whether the string in the combined verification information is the same as the string previously communicated by the first device. If they are the same, and the target device is the first device to hold the string, the second device determines that the target device can meet the local verification requirements.

[0092] In some embodiments, as discussed above, the second device may at least refer to the access rights between the first device and the second device in the process of granting access rights to the target device. For example, the second device may use the range of access rights between the first device and the second device as the upper limit. For example, the second device may determine the interface to grant access rights to the target device only 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 access rights accordingly 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 can choose a simpler and more efficient way to implement verification compared to when no verification auxiliary information exists.

[0095] For example, the second device can choose to verify the authorized access only based on the validity and authenticity of the verification auxiliary information. If the verification auxiliary information is valid and the verification auxiliary information matches the signature information of the device, it can directly choose to grant access to the target device and "record" the signature information of the target device. In this way, the second device can use the "trust" of the first device with local access rights to assist the local verification process of granting access rights, thereby improving the completion efficiency of the verification process.

[0096] Then, the method for granting access rights provided by the present 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 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 authorized to access the local area. Thus, other devices that have been granted access rights can be used to provide auxiliary information and reference information, so as to more accurately and efficiently grant access rights to devices requesting access rights 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 is composed of the process of requesting access rights and the process of granting access rights, is shown.

[0098] In process 300, devices 310, 310 and 330 may be included. Device 310 is trusted for 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 expects to obtain access rights for device 330.

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

[0100] Accordingly, because 310 is a trusted device of device 320 , upon receiving the verification assistance request, device 320 executes S302 to generate 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 ) to combine the signature information 315 of the device 310 and the verification auxiliary information 325 to obtain the 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 the access right 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 the 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 generate access permission information 355 accordingly, 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 present application also provides a device for requesting access rights. The structure of the device is as follows: Figure 4 The device 400 shown can be applied to a first device. The device 400 includes: a verification auxiliary information generation module 410, configured to generate verification auxiliary information for a second device in response to receiving a verification auxiliary request for a second device sent by a trusted device, wherein the first device has access rights to the second device; a verification auxiliary information sending module 420, configured to send the verification auxiliary information to the trusted device; a verification information generation control module 430, 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 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 a 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 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 submodule, configured to generate a hypertext markup language file corresponding to the target uniform resource locator; a verification assistance information embedding submodule, 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 submodule, 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 a network cookie of the trusted device in response to the combined verification information satisfying a local verification requirement of the second device.

[0113] The present application also provides a device for granting access rights. The structure of the device is as follows: Figure 5 The device 500 shown can be applied to the second device. The device 500 includes: a grant request receiving module 510, which is 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 the first device and signature information of the target device, and the first device has access permission to the second device; an access permission granting module 520, which is configured to grant the target device permission to access the local area in response to the combined verification information being able to meet the 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 method. The electronic device provided in an embodiment of the present application includes: at least one processor; and a memory connected to the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the methods and / or technical solutions of the aforementioned multiple embodiments of the present application.

[0115] The electronic device may be a user device, or a device formed by integrating a user device and a network device through a network, or an application running on the above device. The user device includes but is not limited to various terminal devices such as computers, mobile phones, tablet computers, smart watches, and bracelets. The network device includes but is not limited to network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, which can be used to implement some processing functions when setting an alarm. Here, the cloud is composed of a large number of hosts or network servers based on cloud computing, where cloud computing is a type of distributed computing, a virtual computer composed of a group of loosely coupled computer sets.

[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, and the electronic device 600 includes a central processing unit (CPU, Central Processing Unit) 601, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM, Read Only Memory) 602 or the program loaded from the storage part 608 to the random access memory (RAM, Random Access Memory) 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 bus 604. Input / output (I / O, Input / Output) interface 605 is also connected to 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 a cathode ray tube (CRT), a liquid crystal display (LCD), an LED display, an OLED display, etc., and a speaker, etc.; 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 may 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 functions defined in the method of the present application are executed.

[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 devices including but not limited to electricity, magnetism, light, electromagnetic, infrared, or semiconductors, or any combination of the above. 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-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this document, computer-readable storage media can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it.

[0121] Computer readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer readable signal media may also be any computer readable medium other than a computer readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0122] The program code embodied on the 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] Computer program code for performing the operations of the present application may 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 may 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 the case of a remote computer, the remote computer may 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 may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0124] The flow chart or block diagram in the accompanying drawings shows the possible architecture, function and operation of the equipment, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square 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 square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated system for hardware that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0125] Those skilled in the art can 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 the present 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, 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] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0128] In addition, each functional module or unit in each embodiment of the present application may be integrated into one processing module or unit, or each module or unit may exist physically separately, or two or more units may be integrated into one module or unit. The above-mentioned integrated unit 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 function modules and units can be stored in a computer-readable storage medium. The above-mentioned software function modules and units are stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor (processor) to perform 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 (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), disk or optical disk and other media that can store program codes.

[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 it. 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] In addition, 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 stated in a device claim can also be implemented by one unit or device through software or hardware. The words first, second, etc. are used to indicate names, and do not indicate any particular order.

Claims

1. A method for requesting access rights, applied to a first device, characterized in that: include: In response to receiving an authentication assistance request for a second device sent by a trusted device, generating authentication assistance information for the second 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 authentication information.

2. The method according to claim 1, characterized in that: The step of generating, in response to receiving a verification assistance request for a second device sent by a trusted device, verification assistance information for the second device comprises: In response to receiving a verification assistance request for a second device sent by a trusted device, acquiring signature information of the trusted device; Based on the encryption operation result of the signature information of the trusted device, verification auxiliary information is generated.

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

4. 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 a communication record 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 as the trusted device.

5. The method according to claim 1, characterized in that 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 that first holds the character string to request access rights is credible.

6. 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: Generate 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.

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

8. 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, and the first device has access permission to the second device; In response to the combined authentication information being able to satisfy local authentication requirements, the target device is authorized to access the local area.

9. A device for requesting access rights, applied to a first device, characterized in that: include: an authentication assistance information generation module, configured to generate authentication assistance information for a second device in response to receiving an authentication assistance 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 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 the access permission from the second device based on the combined verification information.

10. 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, and the first device has access permission to the second device; 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.

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

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

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

Images