User Identity Verification Method, Device, and Computer Storage Medium

Abstract

The present invention discloses a method, apparatus, and computer storage medium for authenticating user identities. Among them, the method includes: receiving an access request and extracting information to be verified from the access request; if there is a preset built-in topic in the distributed stream processing platform currently, determining whether the data in the preset built-in topic has been updated; the preset built-in topic is used to store authenticated user information, and the data cleaning policy of the preset built-in topic is a compression policy; if the data in the preset built-in topic has not been updated, obtaining the authenticated user information from the local cache to verify the information to be verified based on the obtained authenticated user information. The technical solution provided by the present invention can perform dynamic management of user information without restarting Kafka, thereby improving the real-time performance and security of authentication.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing, and particularly relates to a method, device and computer storage medium for verifying user identity. Background Art

[0002] In the current distributed stream platform kafka, the identity of a user can be verified through the SASL / PLAIN (Simple Authentication and Security Layer) authentication mechanism.

[0003] Currently, the native SASL / PLAIN authentication mechanism stores the authenticated username and password in a local JAAS (Java Authentication and Authorization Service) file. By reading the username and password stored in the JAAS file, the access request of the user can be verified.

[0004] However, storing the username and password in a local JAAS file is not convenient for dynamic management of the username and password. When the content in the JAAS file is modified (such as adding, deleting, modifying the username and password, etc.), the modified content usually takes effect after restarting kafka. Obviously, in a normal online environment, kafka cannot be frequently restarted, which results in the effective username and password not being real-time, thus leading to low security of identity verification. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a method, device and computer storage medium for verifying user identity, which can perform dynamic management of user information without restarting kafka, thereby improving the real-time performance and security of verification.

[0006] On the one hand, the present invention provides a method for verifying user identity. The method is applied to a distributed stream processing platform, and the method includes: receiving an access request, and extracting information to be verified from the access request; if there is a preset built-in topic in the distributed stream processing platform currently, determining whether the data in the preset built-in topic has been updated; the preset built-in topic is used to store authenticated user information, and the data cleaning policy of the preset built-in topic is a compression policy; if the data in the preset built-in topic has not been updated, obtaining the authenticated user information from the local cache, and verifying the information to be verified based on the obtained authenticated user information.

[0007] In one embodiment, after extracting the information to be verified from the access request, the method further includes: determining whether the information to be verified is the username and password of a built-in superuser; if so, verifying the access request.

[0008] In one embodiment, the method further includes: if the information to be verified is not the username and password of a built-in superuser, invoking the instantiated client to determine whether a preset built-in theme exists currently through the instantiated client.

[0009] In one embodiment, the method further includes: if the preset built-in theme does not exist currently, determining that the access request verification fails and ending the verification process for the access request.

[0010] In one embodiment, determining whether the data in the preset built-in theme has been updated includes: comparing the first data offset of the authenticated user information in the cache with the second data offset of the authenticated user information in the preset built-in theme; if the first data offset is the same as the second data offset, determining that the data in the preset built-in theme has not been updated; if the first data offset is different from the second data offset, determining that the data in the preset built-in theme has been updated.

[0011] In one embodiment, the method further includes: if the data in the preset built-in theme has been updated, reading the authenticated user information from the preset built-in theme, verifying the information to be verified based on the read authenticated user information, and updating the read authenticated user information to the cache.

[0012] In one embodiment, the method further includes: receiving a new user request including the username and password to be newly created; writing the username and password to be newly created into the preset built-in theme through the instantiated client, where the instantiated client has the data read / write permission for the preset built-in theme.

[0013] In one embodiment, the method further includes: receiving a password modification request including the username and the modified password corresponding to the username; writing the username as the key and the modified password as the value into the preset built-in theme through the instantiated client; where if there are multiple passwords for the username in the preset built-in theme, only the latest password is retained and other historical passwords are deleted.

[0014] In one embodiment, the method further includes: receiving a user deletion request, where the user deletion request includes the username to be deleted and the empty password corresponding to the username to be deleted; writing, by an instantiated client, the username to be deleted as a key and the empty password as a value into the preset built-in topic; where, if in the preset built-in topic, the username to be deleted has multiple passwords, only the latest empty password is retained, and other historical passwords are deleted.

[0015] On the other hand, the present invention also provides a user identity verification device, which is located in a distributed stream processing platform. The device includes: an information extraction unit, configured to receive an access request and extract information to be verified from the access request; an update judgment unit, configured to judge whether the data in the preset built-in topic has been updated if there is a preset built-in topic in the distributed stream processing platform currently; the preset built-in topic is used to store authenticated user information, and the data cleaning policy of the preset built-in topic is a compression policy; a verification unit, configured to, if the data in the preset built-in topic has not been updated, obtain the authenticated user information from the local cache and verify the information to be verified based on the obtained authenticated user information.

[0016] In one embodiment, the update judgment unit includes: an offset comparison module, configured to compare a first data offset of the authenticated user information in the cache with a second data offset of the authenticated user information in the preset built-in topic; a determination module, configured to determine that the data in the preset built-in topic has not been updated if the first data offset is the same as the second data offset; and determine that the data in the preset built-in topic has been updated if the first data offset is different from the second data offset.

[0017] In one embodiment, the device further includes: a data update unit, configured to, if the data in the preset built-in topic has been updated, read the authenticated user information from the preset built-in topic to verify the information to be verified based on the read authenticated user information, and update the read authenticated user information to the cache.

[0018] In one embodiment, the device further includes: a new request receiving unit, configured to receive a new user request, where the new user request includes the username to be newly created and the password; a user creation unit, configured to write the username to be newly created and the password into the preset built-in topic by an instantiated client, where the instantiated client has the data read / write permission for the preset built-in topic.

[0019] In one embodiment, the device further comprises: a modification request receiving unit, configured to receive a password modification request, where the password modification request includes a user name and a modified password corresponding to the user name; a password modification unit, configured to write, by an instantiated client, the user name as a key and the modified password as a value into the preset built-in topic; wherein, if there are multiple passwords for the user name in the preset built-in topic, only the latest password is retained, and other historical passwords are deleted.

[0020] In one embodiment, the device further comprises: a deletion request receiving unit, configured to receive a user deletion request, where the user deletion request includes a user name to be deleted and an empty password corresponding to the user name to be deleted; a user deletion unit, configured to write, by an instantiated client, the user name to be deleted as a key and the empty password as a value into the preset built-in topic; wherein, if there are multiple passwords for the user name to be deleted in the preset built-in topic, only the latest empty password is retained, and other historical passwords are deleted.

[0021] On the other hand, the present invention also provides a user identity verification device, the device includes a memory and a processor, the memory is used to store a computer program, and when the computer program is executed by the processor, the above-mentioned user identity verification method is implemented.

[0022] On the other hand, the present invention also provides a computer storage medium, the computer storage medium is used to store a computer program, and when the computer program is executed by a processor, the above-mentioned user identity verification method is implemented.

[0023] The technical solution provided by this application can store the authenticated user information in a preset built-in topic (topic) instead of storing it locally through a JAAS file. The data in the preset built-in topic can be dynamically managed and can take effect without restarting kafka. In this way, when authenticating the user sending an access request, the information to be verified can be extracted from the access request. Then, in the presence of a preset built-in topic, it can be determined whether the data in the preset built-in topic has been updated, so as to determine whether the data in the current cache is consistent with the data in the preset built-in topic. If no update has occurred, the authenticated user information can be directly read from the cache, and authentication can be performed based on the read user information. If an update has occurred, the user information can be read from the preset built-in topic, and authentication can be performed based on the read user information. At the same time, the read user information can be written into the cache to ensure that the data in the cache is synchronized with the data in the preset built-in topic.

[0024] As can be seen above, by presetting built-in topics to store authenticated user information, a dynamic management process of user information can be achieved. Before verifying the user's identity, it is possible to determine whether the user information in the cache is consistent with that in the preset built-in topic, thus ensuring the accuracy of identity verification. The dynamically managed user information can take effect in real time, thereby improving the real-time performance and security of identity verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The features and advantages of the present invention will be more clearly understood by referring to the accompanying drawings. The drawings are schematic and should not be construed as imposing any limitation on the present invention. In the drawings:

[0026] Figure 1 A schematic diagram of data processing of a compression strategy in the prior art is shown;

[0027] Figure 2 A schematic diagram of the steps of a method for verifying user identity in an embodiment of the present invention is shown;

[0028] Figure 3 A flowchart of verifying user identity in an embodiment of the present invention is shown;

[0029] Figure 4 A schematic diagram of the functional modules of a device for verifying user identity in an embodiment of the present invention is shown;

[0030] Figure 5 A schematic diagram of the structure of a device for verifying user identity in another embodiment of the present invention is shown. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0031] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0032] In a traditional Kafka cluster, it is usually necessary to rely on ZooKeeper to store metadata and configuration information. To simplify the deployment architecture of the Kafka cluster, the improved Kafka cluster can be independent of the dependence on ZooKeeper and store content such as metadata and configuration information in the built-in topic of the Kafka cluster. For example, the built-in topic is topic(@metadata). Different from the conventional built-in topics, the built-in topic for storing metadata and configuration information is invisible to users, thus avoiding the random tampering of metadata and configuration information.

[0033] To solve the defect of storing user information through JAAS files, currently, the authenticated user information can be stored in an external medium through an external storage method. For example, the authenticated user information can be stored in MySQL or Zookeeper. Obviously, adding an external medium will increase the deployment complexity and maintenance difficulty of the Kafka cluster. In addition, the improved Kafka has been separated from Zookeeper, and it obviously doesn't make much sense to enable Zookeeper again for storing user information. Moreover, the data read and write performance of the external medium will be much lower than that of Kafka itself. Therefore, in the application scenario of big data with high concurrency, the read and write performance of Kafka will be limited by the read and write performance of the external medium.

[0034] In view of this, the user identity verification method provided in this application can create a preset built-in topic in Kafka for storing authenticated user information. In Kafka, the data in the topic can take effect in real time. Therefore, by managing user information through the preset built-in topic, the user information in Kafka can be dynamically updated.

[0035] In Kafka, to alleviate the redundancy of data in the topic, the topic can have corresponding data cleaning policies. There are usually two existing data cleaning policies: one is the delete policy, and the other is the compact policy. The data cleaning policy can be set through the configuration item log.cleanup.policy in Kafka.

[0036] Generally speaking, the default data cleaning policy of the topic is the delete policy. The delete policy means that if the data stored in the topic reaches the pre-set storage duration or the pre-set capacity threshold, the topic will automatically delete the inactive data directly to save the storage space in the topic. The compact policy means that if the data stored in the topic reaches the pre-set storage duration or the pre-set capacity threshold, the topic will deduplicate the multiple values (values) mapped to the same key (key), and for each key, only the latest value will be retained.

[0037] Please refer to Figure 1 , before adopting the compact policy, there are three pairs of key-value pair data with keys K1 and K2 in the topic, and two pairs of key-value pair data with key K5. After adopting the compact policy, only the latest value of each key will be retained. For example Figure 1 in, K1 corresponds to the latest V4, K2 corresponds to the latest V10, and K5 corresponds to the latest V9.

[0038] In this application, for the authenticated user information, it includes the username and password. Among them, the username can be used as the key, and the password can be used as the value. When using the preset built-in theme to store the authenticated user information, it is necessary to set the data cleaning policy of the preset built-in theme to the compression policy. The purpose of this processing is that for the authenticated user information, if the user does not modify the password, then after a period of time, this user information will be in an inactive state. And if the data cleaning policy is the deletion policy, this user information will be deleted. Obviously, this is unreasonable in the scenario of authentication. By setting the data cleaning policy to the compression policy, in the preset built-in theme, for the authenticated user, each username will at least have the latest password, so as to ensure that the authentication can proceed normally.

[0039] In practical applications, the above-mentioned preset built-in theme can be created by using the native script tool kafka-topics.sh of Kafka. After creating the preset built-in theme, the native script tool kafka-configs.sh can be used to set the data cleaning policy of this preset built-in theme to the compression policy.

[0040] In the existing SASL / PLAIN mechanism for authentication based on the JAAS file, the user information in the JAAS file can be read from the cache through the configure method, the information to be verified can be obtained through the handle method, and the information to be verified can be authenticated through the authenticate method. Since the implementation method of this application is to read the user information in the preset built-in theme from the cache, the above-mentioned various methods can be correspondingly improved, but the specific functions implemented are still similar, except that the data objects processed are different.

[0041] Please refer to Figure 2 , a method for authenticating user identity provided by an embodiment of this application. This method can be applied to a distributed stream processing platform such as Kafka. This method can include the following multiple steps.

[0042] S1: Receive an access request and extract the information to be verified from the access request.

[0043] In this embodiment, the access request sent by the user can carry the information to be verified by the user. This information to be verified can be the username and the corresponding password. In practical applications, the corresponding information to be verified can be extracted from the access request through the handle method.

[0044] S3: If there is a preset built-in topic in the distributed stream processing platform, determine whether the data in the preset built-in topic has been updated; the preset built-in topic is used to store authenticated user information, and the data cleaning policy for the preset built-in topic is the compression policy.

[0045] Please refer to Figure 3 , after extracting the information to be verified from the access request, it can be first determined whether the information to be verified is the username and password of the built-in superuser. Among them, the built-in superuser can be a user who does not need to perform identity verification. The username and password of the superuser are pre-set in the kafka cluster. If the information to be verified is the username and password of the superuser, then the access request can be directly verified and passed.

[0046] In this embodiment, if the information to be verified is not the username and password of the built-in superuser, the authenticate method can be called to authenticate the information to be verified.

[0047] In this application, in order to read the data in the built-in topic, a kafka client can be instantiated first through the configure method. The username and password of the kafka client can be set as the username and password of the superuser, so as to grant the kafka client the permission to read and write the data in the built-in topic.

[0048] In this embodiment, after the authenticate method is called, it can be determined whether there is a preset built-in topic through the instantiated kafka client. If not, it indicates that there is no authenticated user information at present. In this case, it can be directly determined that the access request verification fails, and the verification process for the access request ends.

[0049] In the case where there is a preset built-in theme, it indicates that there is authenticated user information in the current Kafka cluster. At this time, the Kafka client can continue to determine whether the data in the preset built-in theme has been updated. In practical applications, the data in the preset built-in theme can be loaded into the cache for quick reading. Since the data in the preset built-in theme may be updated dynamically and may not be synchronized to the cache in a timely manner after the update, the data in the cache and the data in the preset built-in theme are not necessarily consistent. To improve the accuracy of authentication, the Kafka client needs to first determine whether the data in the preset built-in theme has been updated. Specifically, in the preset built-in theme, the authenticated user information can be stored in the form of key-value pairs, and each group of key-value pair data will correspond to a unique data offset. In this way, when determining whether the data in the preset built-in theme has been updated, the first data offset of the authenticated user information in the cache can be compared with the second data offset of the authenticated user information in the preset built-in theme. If the first data offset is the same as the second data offset, it can be determined that the data in the preset built-in theme has not been updated. If the first data offset is different from the second data offset, it can be determined that the data in the preset built-in theme has been updated.

[0050] S5: If the data in the preset built-in theme has not been updated, obtain the authenticated user information from the local cache, and verify the information to be verified based on the obtained authenticated user information.

[0051] In this embodiment, if the data in the preset built-in theme has not been updated, it indicates that the authenticated user information in the local cache of the distributed stream processing platform is consistent with the authenticated user information in the preset built-in theme. At this time, the authenticated user information can be directly obtained from the cache. By matching the username and password in the information to be verified with the authenticated user information, the information to be verified can be authenticated.

[0052] Specifically, first, it can be determined whether the password corresponding to the username in the information to be verified is a null password in the obtained authenticated user information. If it is a null password, it indicates that the user has been deleted in the Kafka cluster. At this time, the access request can be rejected and the verification fails. If the corresponding password is not a null password and the username and password in the information to be verified exist in the authenticated user information, the access request can be verified and passed.

[0053] In one embodiment, if the data in the preset built-in topic is updated, it indicates that the data in the cache is not the latest. At this time, the kafka client can directly read the authenticated user information from the preset built-in topic and authenticate the information to be verified based on the read user information. At the same time, the kafka client can update the authenticated identity information read from the preset built-in topic to the cache so that the user information in the cache is consistent with the identity information in the preset built-in topic. Subsequently, if the authenticated user information in the preset built-in topic is not further updated, the corresponding user information can be quickly read from the cache.

[0054] In this embodiment, after the authentication of the information to be verified is completed, the above instantiated kafka client can be closed through the close method.

[0055] In this application, user information can be dynamically managed through the preset built-in topic. Specifically, user information can be added, the passwords of authenticated users can be modified, and the authenticated user information can be deleted in the preset built-in topic. In practical applications, the instantiated kafka client can be used to read and write data in the preset built-in topic.

[0056] In one embodiment, a user can send a new user request to the kafka client. In this new user request, the username to be created and the corresponding password can be included. For this new user request, the kafka client can write a new message to the preset built-in topic. In this new message, the above-mentioned username to be created and password can be included. In this way, in the preset built-in topic, the username to be created can be used as the key and the password can be used as the value for storage.

[0057] Of course, the username to be created must be an unauthenticated username in the preset built-in topic, and the username to be created needs to comply with the naming rules of usernames in the kafka cluster. This is common knowledge in this field and will not be elaborated here.

[0058] In one embodiment, the Kafka client can also be used to modify the password of an authenticated user. Specifically, the user can send a password modification request to the Kafka client. The password modification request may include the username for which the password is to be modified and the modified password corresponding to the username. The Kafka client can construct a password modification message that includes the username and the modified password. After writing this message to a preset built-in topic, in the preset built-in topic, a key-value pair data can be added, with the username as the key and the modified password as the value. Since the data cleaning policy of the preset built-in topic is the compression policy, when a certain username has multiple passwords (only the latest password is valid, and the rest are historical passwords), only the latest password can be retained, and other historical passwords can be deleted. In this way, through the compression policy of the preset built-in topic, the latest password can be automatically retained, thus ensuring the accuracy of identity authentication.

[0059] Of course, before modifying the password, Kafka can first verify the user's identity. Only after confirming that the user's identity is correct is the user allowed to modify their own password. This is common knowledge in the field and will not be elaborated here.

[0060] In one embodiment, the Kafka client can also be used to implement the function of deleting an authenticated user. Specifically, when it is necessary to cancel the information of a certain user in the Kafka client, a user deletion request can be sent to the Kafka client. In the user deletion request, it may include the username to be deleted and the null password corresponding to the username to be deleted, where the null password can be represented as null. In this way, the Kafka client can also construct a message that includes the username and the null password and write this message to the preset built-in topic. After writing this message to the preset built-in topic, in the preset built-in topic, a key-value pair data can be added, with the username as the key and the null password as the value. Since the data cleaning policy of the preset built-in topic is the compression policy, when a certain username has multiple passwords (only the latest null password is valid, and the rest are historical passwords), only the latest null password can be retained, and other historical passwords can be deleted. In this way, through the compression policy of the preset built-in topic, the password of the user to be deleted can be set to null. Subsequently, when the user sends an access request, it will be found that the user's password is null, and then the Kafka cluster can directly reject the user's access request.

[0061] The technical solution provided by this application can store the authenticated user information in a preset built-in topic (topic) instead of storing it locally through a JAAS file. The data in the preset built-in topic can be dynamically managed and can take effect without restarting Kafka. In this way, when authenticating a user who sends an access request, the information to be verified can be extracted from the access request. Then, in the presence of a preset built-in topic, it can be determined whether the data in the preset built-in topic has been updated, so as to determine whether the data in the current cache is consistent with the data in the preset built-in topic. If no update has occurred, the authenticated user information can be directly read from the cache, and then authentication can be performed based on the read user information. If an update has occurred, the user information can be read from the preset built-in topic, and authentication can be performed based on the read user information. At the same time, the read user information can be written into the cache to ensure that the data in the cache is synchronized with the data in the preset built-in topic.

[0062] As can be seen from the above, by storing the authenticated user information in a preset built-in topic, the dynamic management process of user information can be realized. Before authenticating the user identity, it can be determined whether the user information in the cache is consistent with the user information in the preset built-in topic, so as to ensure the accuracy of authentication. The dynamically managed user information can take effect in real time, thus improving the real-time performance and security of authentication.

[0063] Please refer to Figure 4 , an embodiment of this application also provides an apparatus for authenticating user identity. The apparatus is located in a distributed stream processing platform, and the apparatus includes:

[0064] An information extraction unit, configured to receive an access request and extract the information to be verified from the access request;

[0065] An update determination unit, configured to determine whether the data in the preset built-in topic has been updated if there is a preset built-in topic in the distributed stream processing platform currently; the preset built-in topic is used to store the authenticated user information, and the data cleaning policy of the preset built-in topic is a compression policy;

[0066] A verification unit, configured to, if the data in the preset built-in topic has not been updated, obtain the authenticated user information from the local cache and verify the information to be verified based on the obtained authenticated user information.

[0067] Please refer to Figure 5 , an embodiment of this application also provides an apparatus for authenticating user identity. The apparatus includes a memory and a processor. The memory is used to store a computer program. When the computer program is executed by the processor, the above-mentioned method for authenticating user identity is implemented.

[0068] One embodiment of the present application further provides a computer-readable storage medium for storing a computer program, which, when executed by a processor, implements the above-described user identity verification method.

[0069] Among them, the processor may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. chips, or a combination of the above types of chips.

[0070] As a non-transitory computer-readable storage medium, the memory can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as program instructions / modules corresponding to the methods in the embodiments of the present invention. The processor executes various functional applications and data processing of the processor by running the non-transitory software programs, instructions, and modules stored in the memory, that is, implements the methods in the above method embodiments.

[0071] The memory may include a program storage area and a data storage area. Among them, the program storage area can store an operating system and application programs required for at least one function; the data storage area can store data created by the processor, etc. In addition, the memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some embodiments, the memory may optionally include a memory remotely set relative to the processor, and these remote memories can be connected to the processor through a network. Examples of the above networks include, but are not limited to, the Internet, enterprise intranets, local area networks, mobile communication networks, and combinations thereof.

[0072] Those skilled in the art can understand that to implement all or part of the processes in the above-described implementation methods, it can be completed by instructing relevant hardware through a computer program. The program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the implementation methods of the above various methods. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD), etc.; the storage medium can also include a combination of the above types of memories.

[0073] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for authenticating a user identity, characterized in that, The method is applied to a distributed stream processing platform, and the method includes: Receiving an access request and extracting information to be verified from the access request, where the information to be verified is a username and a password; If there is a preset built-in topic in the distributed stream processing platform currently, determining whether the data in the preset built-in topic has been updated relative to the cache; the preset built-in topic is invisible to users, and the preset built-in topic is used to store authenticated user information, and the data cleaning policy of the preset built-in topic is a compression policy; If the data in the preset built-in topic has not been updated relative to the cache, obtaining authenticated user information from the local cache and verifying the information to be verified based on the obtained authenticated user information; If the data in the preset built-in topic has been updated relative to the cache, reading authenticated user information from the preset built-in topic, verifying the information to be verified based on the read authenticated user information, and updating the read authenticated user information to the cache.

2. The method according to claim 1, characterized in that After extracting the information to be verified from the access request, the method further includes: Determining whether the information to be verified is the username and password of a built-in superuser. If so, the access request is verified; if the information to be verified is not the username and password of a built-in superuser, an instantiated client is called to determine whether there is a preset built-in topic currently through the instantiated client.

3. The method according to claim 1 or 2, characterized in that, The method further includes: If the preset built-in topic does not exist currently, determining that the access request verification fails and ending the verification process for the access request.

4. The method according to claim 1, characterized in that, Determining whether the data in the preset built-in topic has been updated includes: Comparing a first data offset of the authenticated user information in the cache with a second data offset of the authenticated user information in the preset built-in topic; If the first data offset is the same as the second data offset, determining that the data in the preset built-in topic has not been updated; if the first data offset is different from the second data offset, determining that the data in the preset built-in topic has been updated.

5. The method according to claim 1, characterized in that The method further includes: Receiving a new user request, where the new user request includes a username and a password to be newly created; Writing the username and password to be newly created into the preset built-in topic through the instantiated client, where the instantiated client has data read and write permissions for the preset built-in topic.

6. The method according to claim 1, wherein The method further includes: Receiving a password modification request, where the password modification request includes a username and the modified password corresponding to the username; Writing the username as the key and the modified password as the value into the preset built-in topic through the instantiated client; where if there are multiple passwords for the username in the preset built-in topic, only the latest password is retained, and other historical passwords are deleted.

7. The method according to claim 1, wherein The method further includes: Receiving a user deletion request, where the user deletion request includes the username to be deleted and the empty password corresponding to the username to be deleted; The instantiated client writes the username to be deleted as the key and the empty password as the value into the preset built-in topic; wherein, if there are multiple passwords for the username to be deleted in the preset built-in topic, only the latest empty password is retained, and other historical passwords are deleted.

8. An authentication device for a user identity, characterized in that, The device is located in a distributed stream processing platform, and the device includes: An information extraction unit, configured to receive an access request and extract information to be verified from the access request, where the information to be verified is a username and a password; An update judgment unit, configured to judge whether the data in the preset built-in topic has been updated relative to the cache if a preset built-in topic currently exists in the distributed stream processing platform; the preset built-in topic is invisible to users and is used to store authenticated user information, and the data cleaning policy of the preset built-in topic is a compression policy; A verification unit, configured to, if the data in the preset built-in topic has not been updated relative to the cache, obtain the authenticated user information from the local cache and verify the information to be verified based on the obtained authenticated user information; if the data in the preset built-in topic has been updated relative to the cache, read the authenticated user information from the preset built-in topic, verify the information to be verified based on the read authenticated user information, and update the read authenticated user information to the cache.

9. A computer storage medium, characterized in that, The computer storage medium is used to store a computer program, and when the computer program is executed by a processor, the method described in any one of claims 1 to 7 is implemented.

Images