CN111651747B - Login bill synchronization system and method and related equipment - Google Patents

Login bill synchronization system and method and related equipment Download PDF

Info

Publication number
CN111651747B
CN111651747B CN202010393683.7A CN202010393683A CN111651747B CN 111651747 B CN111651747 B CN 111651747B CN 202010393683 A CN202010393683 A CN 202010393683A CN 111651747 B CN111651747 B CN 111651747B
Authority
CN
China
Prior art keywords
login
target object
bill
authentication service
ticket
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010393683.7A
Other languages
Chinese (zh)
Other versions
CN111651747A (en
Inventor
帅涛
叶崇波
张栋
任启盈
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202010393683.7A priority Critical patent/CN111651747B/en
Publication of CN111651747A publication Critical patent/CN111651747A/en
Application granted granted Critical
Publication of CN111651747B publication Critical patent/CN111651747B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/41User authentication where a single sign-on provides access to a plurality of computers
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44Program or device authentication

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

The disclosure provides a login bill synchronization system and method and related equipment. The system comprises: the first authentication service node comprises a first bill service module and a first local queue, wherein the first bill service module is used for receiving a first login request of a target object, responding to the first login request, generating a login bill of the target object and pushing the login bill of the target object to the first local queue; the queue cluster is used for receiving the login bill of the target object pushed by the first local queue; the second authentication service node comprises a second local cache and a second queue consumer, wherein the second queue consumer is used for receiving the login bill of the target object distributed by the queue cluster and pushing the login bill of the target object to the second local cache. The scheme provided by the disclosure can be used for realizing the consistency of login bills among multiple authentication service nodes. The present disclosure relates to cloud security technology.

Description

Login bill synchronization system and method and related equipment
Technical Field
The disclosure relates to the technical field of communication, in particular to a login bill synchronization system and method, a computer readable storage medium and electronic equipment.
Background
Logging is generally a necessary function of each technical product, and the reliability and stability of logging directly influence the use of the product by a user. With the development of information technology, more and more network application systems are built in enterprises, and some of the application systems are only provided for the personnel inside the enterprises to use.
Within an enterprise, single sign On (SINGLE SIGN On, SSO) is currently commonly implemented by internal web applications. SSO is one of the more popular solutions for enterprise business integration today. SSO is defined as the ability of a user to access all mutually trusted applications by logging in only once in multiple applications. In this case, the reliability of the login is particularly important. Upon failure of the login, all OA (Office Automation ) sites will be rendered unavailable.
Among them, ticket (ticket) is a credential generated when a user logs in, and is the key of the login process. In the related art, the authentication service is single-point deployment, i.e., deployment in one machine room. In this case the ticket is stored only on one place, but this solution is unreliable and once the authentication service fails, user login will be blocked and the service site will not be available.
Thus, there is a need for a new login ticket synchronization system and method, computer readable storage medium, electronic device.
It should be noted that the information disclosed in the foregoing background section is only for enhancing understanding of the background of the present disclosure.
Disclosure of Invention
The embodiment of the disclosure provides a login bill synchronization system and method, a computer-readable storage medium and electronic equipment, which can solve the technical problem of how to maintain the consistency of multi-point bills under the condition of distributed deployment of authentication services.
Other features and advantages of the present disclosure will be apparent from the following detailed description, or may be learned in part by the practice of the disclosure.
An embodiment of the present disclosure provides a login ticket synchronization system, the system including: the first authentication service node comprises a first bill service module and a first local queue, wherein the first bill service module is used for receiving a first login request of a target object, responding to the first login request, generating a login bill of the target object and pushing the login bill of the target object to the first local queue; the queue cluster is used for receiving the login bill of the target object pushed by the first local queue; the second authentication service node comprises a second local cache and a second queue consumer, wherein the second queue consumer is used for receiving the login bill of the target object distributed by the queue cluster and pushing the login bill of the target object to the second local cache.
The embodiment of the disclosure provides a login bill synchronization method which is applied to a first authentication service node, wherein the first authentication service node comprises a first local queue; wherein the method comprises the following steps: receiving a first login request of a target object; generating a login ticket of the target object in response to the first login request; pushing the login bill of the target object to the first local queue; pushing the login ticket of the target object to a queue cluster through the first local queue, so that the queue cluster distributes the login ticket of the target object to a second authentication service node.
The embodiment of the disclosure provides a login bill synchronization method which is applied to a second authentication service node, wherein the second authentication service node comprises a second local cache; wherein the method comprises the following steps: receiving a login bill of a target object distributed by a queue cluster, wherein the login bill of the target object is generated by a first authentication service node; pushing the login bill of the target object to the second local cache; receiving a second login request of the target object; responding to the second login request to acquire a login bill of the target object from the second local cache; and verifying the second login request according to the login bill of the target object.
The disclosed embodiments provide a computer readable storage medium having stored thereon a computer program which when executed by a processor implements the login ticket synchronization method as described in the above embodiments.
The embodiment of the disclosure provides an electronic device, comprising: one or more processors; and a storage configured to store one or more programs that, when executed by the one or more processors, cause the one or more processors to implement the login ticket synchronization method as described in the above embodiments.
In the technical solutions provided in some embodiments of the present disclosure, on one hand, by deploying a plurality of authentication service nodes through a distributed deployment authentication service node , (including at least a first authentication service node and a second authentication service node), that is, multiple points or multiple places or multiple machines, it can be ensured that when a certain authentication service node fails, it can be quickly switched to other authentication service nodes that work normally, so that the user login process is not affected, and high availability of service sites is ensured; on the other hand, the login ticket of the target object generated by the first ticket service module of the first authentication service node can be pushed into the queue cluster through the first local queue in each authentication service node, such as the first authentication service node, so that the queue cluster can further push the login ticket of the target object to other authentication service nodes except the first authentication service node, such as the second authentication service node, and the second authentication service node can receive the login ticket of the target object through the second queue consumer and store the login ticket of the target object into the second local cache, and consistency of the login ticket between the first authentication service node and the second authentication service node can be achieved. When the target object logs in again at other authentication service nodes, the login bill of the target object can be directly obtained from the local cache of the target object, and the SSO function can be realized without regenerating the login bill.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description, serve to explain the principles of the disclosure. It will be apparent to those of ordinary skill in the art that the drawings in the following description are merely examples of the disclosure and that other drawings may be derived from them without undue effort. In the drawings:
FIG. 1 illustrates a schematic diagram of an exemplary system architecture to which a login ticket synchronization method or login ticket synchronization system of embodiments of the present disclosure may be applied;
FIG. 2 illustrates a schematic diagram of a computer system suitable for use in implementing embodiments of the present disclosure;
FIG. 3 shows a schematic diagram of a login model in the related art;
FIG. 4 schematically illustrates a block diagram of a logon ticket synchronization system according to an embodiment of the present disclosure;
FIG. 5 schematically illustrates a block diagram of a logon ticket synchronization system according to an embodiment of the present disclosure;
FIG. 6 schematically illustrates a block diagram of a logon ticket synchronization system according to an embodiment of the present disclosure;
FIG. 7 schematically illustrates a schematic diagram of ticket tracing in accordance with an embodiment of the present disclosure;
FIG. 8 schematically illustrates a flow diagram of a login ticket synchronization method according to an embodiment of the present disclosure;
FIG. 9 schematically illustrates a flow diagram of a login ticket synchronization method according to an embodiment of the present disclosure;
Fig. 10 schematically illustrates a flowchart of a login ticket synchronization method according to an embodiment of the present disclosure.
Detailed Description
Example embodiments will now be described more fully with reference to the accompanying drawings. However, the exemplary embodiments can be embodied in many forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the example embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and thus a repetitive description thereof will be omitted.
The described features, structures, or characteristics of the disclosure may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the present disclosure. However, those skilled in the art will recognize that the aspects of the present disclosure may be practiced with one or more of the specific details, or with other methods, components, devices, steps, etc. In other instances, well-known methods, devices, implementations, or operations are not shown or described in detail to avoid obscuring aspects of the disclosure.
The drawings are merely schematic illustrations of the present disclosure, in which like reference numerals denote like or similar parts, and thus a repetitive description thereof will be omitted. Some of the block diagrams shown in the figures do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in software or in one or more hardware modules or integrated circuits or in different networks and/or processor devices and/or microcontroller devices.
The flow diagrams depicted in the figures are exemplary only, and not necessarily all of the elements or steps are included or performed in the order described. For example, some steps may be decomposed, and some steps may be combined or partially combined, so that the order of actual execution may be changed according to actual situations.
In the present specification, the terms "a," "an," "the," "said" and "at least one" are used to indicate the presence of one or more elements/components/etc.; the terms "comprising," "including," and "having" are intended to be inclusive and mean that there may be additional elements/components/etc., in addition to the listed elements/components/etc.; the terms "first," "second," and "third," etc. are used merely as labels, and do not limit the number of their objects.
The following describes example embodiments of the present disclosure in detail with reference to the accompanying drawings.
Fig. 1 shows a schematic diagram of an exemplary system architecture of a login ticket synchronization method or login ticket synchronization system that may be applied to embodiments of the present disclosure.
As shown in fig. 1, a system architecture 100 may include terminal devices 101, 102, 103, a network 104, and a server 105. The network 104 is used as a medium to provide communication links between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.
The server 105 may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or may be a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs (Content Delivery Network, content delivery networks), basic cloud computing services such as big data and artificial intelligence platforms, and the like. The terminal devices 101, 102, 103 may be, but are not limited to, smartphones, tablet computers, notebook computers, desktop computers, smart speakers, smart watches, etc. The terminal devices 101, 102, 103 and the server 105 may be directly or indirectly connected through wired or wireless communication, and the present application is not limited herein.
The server 105 may, for example, receive a first login request of a target object sent by the terminal device 101 (may also be the terminal devices 102, 103); in response to the first login request, the first authentication service node of the server 105 is utilized to generate a login ticket of the target object, the login ticket of the target object is pushed to a first local queue of the first authentication service node, the login ticket of the target object is pushed to a queue cluster of the server 105 through the first local queue, and the queue cluster distributes the login ticket of the target object to a second authentication service node of the server 105. The second authentication service node receives the login ticket of the target object distributed by the queue cluster and pushes the login ticket of the target object to a second local cache of the second authentication service node.
It should be understood that the number of terminal devices, networks and servers in fig. 1 is merely illustrative, and that the server 105 may be a server of one entity, or may be composed of a plurality of servers, and may have any number of terminal devices, networks and servers according to actual needs.
Referring now to FIG. 2, a schematic diagram of a computer system 200 suitable for use in implementing an embodiment of the present application is shown. The terminal device shown in fig. 2 is only an example, and should not impose any limitation on the functions and the scope of use of the embodiment of the present application.
As shown in fig. 2, the computer system 200 includes a Central Processing Unit (CPU) 201, which can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 202 or a program loaded from a storage section 208 into a Random Access Memory (RAM) 203. In the RAM 203, various programs and data required for the operation of the system 200 are also stored. The CPU 201, ROM 202, and RAM 203 are connected to each other through a bus 204. An input/output (I/O) interface 205 is also connected to bus 204.
The following components are connected to the I/O interface 205: an input section 206 including a keyboard, a mouse, and the like; an output portion 207 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker, and the like; a storage section 208 including a hard disk or the like; and a communication section 209 including a network interface card such as a LAN card, a modem, and the like. The communication section 209 performs communication processing via a network such as the internet. The drive 210 is also connected to the I/O interface 205 as needed. A removable medium 211 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is installed on the drive 210 as needed, so that a computer program read therefrom is installed into the storage section 208 as needed.
In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable storage medium, the computer program comprising program code for performing the method shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from a network via the communication portion 209, and/or installed from the removable medium 211. The above-described functions defined in the system of the present application are performed when the computer program is executed by a Central Processing Unit (CPU) 201.
The computer readable storage medium shown in the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable storage medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable storage medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The units involved in the embodiments of the present application may be implemented in software or in hardware. The described units may also be provided in a processor, for example, described as: a processor includes a transmitting unit, an acquiring unit, a determining unit, and a first processing unit. Wherein the names of the units do not constitute a limitation of the units themselves in some cases.
As another aspect, the present application also provides a computer-readable storage medium that may be contained in the apparatus described in the above embodiments; or may be present alone without being fitted into the device. The computer-readable storage medium carries one or more programs which, when executed by a device, cause the device to perform functions including: receiving a first login request of a target object; generating a login ticket of the target object in response to the first login request; pushing the login bill of the target object to a first local queue of a first authentication service node; pushing the login ticket of the target object to a queue cluster through the first local queue, so that the queue cluster distributes the login ticket of the target object to a second authentication service node; or receiving a login bill of a target object distributed by a queue cluster, wherein the login bill of the target object is generated by a first authentication service node; pushing the login bill of the target object to a second local cache of a second authentication service node.
It should be understood that any number of elements in the drawings of the present disclosure are for illustration and not limitation, and that any naming is used for distinction only and not for limitation.
First, some terms involved in the embodiments of the present disclosure will be defined.
Admission gateway/API (Application Programming Interface) gateway: the service of API host is provided for business application, and authority management, flow monitoring and the like can be supported. In the embodiment of the disclosure, the access layer may be understood as an access layer, and when a user accesses a target site, the user will first pass through an access gateway; when an application calls an interface, the application passes through the API gateway.
Outlook (being one of the components of the office software suite)/AD (Active Directories, active directory): a login mode is characterized in that an account number and an Outlook password are used for login. When the user logs in this way, the user firstly passes through the authentication service, and then requests verification from the authentication service to the Outlook/AD service. The Outlook/AD service itself is a dependent service for authentication services.
Token (Token): a login mode is represented by using an account number and a token to log in. When the user logs in this way, the user firstly passes through the authentication service, and then requests verification from the authentication service to the Token service. Token service itself is a dependent service for authentication services.
Scanning codes and logging: a login mode is changed to use an instant messaging application program to scan a two-dimensional code on a login page for login. When the user logs in the mode, the user firstly passes through the authentication service, and then requests verification from the authentication service to the code scanning service. The code scanning service itself is a dependent service for authentication services.
Unified login/unified login page/SSO: the login site of the SSO in the enterprise is referred, all the login of the OA intranet is performed on the page, the login is completed through the authentication service, and the login state is returned to the target site.
Authentication service: refers to a service that completes the login process.
Ticket (ticket) service: is part of an authentication service for generating notes, checking notes, verifying notes, etc.
Bill: the user login credentials generated by the login process may also be referred to as login tickets in the following embodiments.
SQL Sever: a relational database management system.
Service node: the authentication service node is specifically referred to in the embodiments of the present disclosure, and may be understood as a cluster of authentication services.
HRC: and the file service for storing employee information, relationships between employees and the organization architecture and the like is used for storing employee and organization architecture data.
Cloud technology (Cloud technology) refers to a hosting technology for integrating hardware, software, network and other series resources in a wide area network or a local area network to realize calculation, storage, processing and sharing of data.
The cloud technology is based on the general names of network technology, information technology, integration technology, management platform technology, application technology and the like applied by the cloud computing business mode, can form a resource pool, and is flexible and convenient as required. Cloud computing technology will become an important support. Background services of technical networking systems require a large amount of computing, storage resources, such as video websites, picture-like websites, and more portals. Along with the high development and application of the internet industry, each article possibly has an own identification mark in the future, the identification mark needs to be transmitted to a background system for logic processing, data with different levels can be processed separately, and various industry data needs strong system rear shield support and can be realized only through cloud computing.
Cloud Security (Cloud Security) refers to a generic term for Security software, hardware, users, institutions, secure Cloud platforms based on Cloud computing business model applications. Cloud security fuses emerging technologies and concepts such as parallel processing, grid computing, unknown virus behavior judgment and the like, acquires the latest information of Trojan horse and malicious programs in the Internet through abnormal monitoring of a large number of network clients on software behaviors, sends the latest information to a server for automatic analysis and processing, and distributes solutions of viruses and Trojan horse to each client.
The main research directions of cloud security include: 1. cloud computing security, namely, how to guarantee security of cloud and various applications on the cloud, including cloud computer system security, security storage and isolation of user data, user access authentication, information transmission security, network attack protection, compliance audit and the like; 2. clouding of a safety infrastructure, mainly researching how to build and integrate safety infrastructure resources by adopting cloud computing, and optimizing a safety protection mechanism, wherein the cloud computing technology is used for constructing a super-large-scale safety event and an information acquisition and processing platform, realizing acquisition and association analysis of mass information, and improving the control capability and risk control capability of the whole-network safety event; 3. cloud security services, mainly research on various security services provided for users based on cloud computing platforms, such as anti-virus services and the like.
Fig. 3 shows a schematic diagram of a login model in the related art.
As shown in fig. 3, is a login model common in the related art. When a user logs in, a login ticket is generated at the authentication service and stored in a SQL SERVER database. Under this model, authentication services are typically single-point, i.e.: deployed in one machine room. When a fault is encountered, a server can be continuously added in the single-point authentication service, so that a certain degree of capacity expansion can be realized.
There is no "ticket reconciliation" problem in the scheme of fig. 3. The reason is that the scheme is single-point, the login bill only exists on one place, and the problem of inconsistency does not occur.
But the solution of figure 3 is unreliable. Once the authentication service fails, user login will be blocked and the service site will not be available.
Based on the technical problems in the related art, the embodiments of the present disclosure provide a login ticket synchronization system for at least partially solving the above problems. Fig. 4 schematically illustrates a block diagram of a login ticket synchronization system according to an embodiment of the present disclosure.
As shown in fig. 4, a login ticket synchronization system 400 provided by an embodiment of the present disclosure may include a first authentication service node 410, a queue cluster 420, and a second authentication service node 420.
The first authentication service node 410 may further include a first ticket service module 411 and a first local queue 412. The first ticket service module 411 may be configured to receive a first login request of a target object, generate a login ticket of the target object in response to the first login request, and push (push) the login ticket of the target object to the first local queue 412.
In the embodiment of the present disclosure, the target object may be, for example, a staff member in the enterprise, the first login request of the target object may carry object information of the target object and related information (such as URL (Uniform Resource Locator, resource locator) of the target service site to be logged in currently, etc.), where the object information of the target object may be, for example, staff member information of the staff member, such as any one or more of a staff member's work number, name, identification card number, mobile phone number, etc., but the present disclosure is not limited thereto, the target object may be any user, and the object information of the target object may change along with the change of the target object.
In the embodiment of the present disclosure, taking an intra-enterprise network system as an example, it is assumed that the intra-enterprise network system may include a plurality of service sites (or application systems), and the plurality of service sites are incorporated into a single sign-on inter-trust internal network system, that is, a company to be visited by a user or an intra-enterprise service site all implement SSO, that is, single sign-on, but the sign-on/authentication services pointed by different service sites may be different authentication service nodes (or centers), which is not limited to this, and the scheme provided in the embodiment of the present disclosure may also be applied to any network system.
In the disclosed embodiment, the queue is a special linear table, and is characterized in that it only allows deletion operations at the front end (front) of the table, and insertion operations at the back end (rear) of the table, and the queue is a linear table with limited operations, like a stack. The end performing the insert operation is called the tail end, and the end performing the delete operation is called the head end. In the embodiment of the present disclosure, the queue of each authentication service node is referred to as a local queue. The first authentication service node 410 may be any one of a plurality of authentication service nodes (assuming N, N being a positive integer greater than or equal to 2) deployed in a distributed manner.
In the embodiment of the present disclosure, the first local queue 412 or the local queues of the respective authentication service nodes may use FIFO (FIRST IN FIRST Out ) queues, that is, when accessing the elements (here, login tickets) in the queues, the processing order of the elements is the order in which they are added to the queues.
The queue cluster 420 may be configured to receive the login ticket for the target object pushed by the first local queue 412.
In the disclosed embodiment, queue cluster 420 may also be referred to as a distributed queue service cluster, i.e., it is a queue that serves one distributed queue, and may be implemented in a clustered fashion. The distributed queue service herein means that the authentication service is distributed, and since each authentication service node has its own local queue, the local queue of the authentication service is also distributed.
In the embodiment of the present disclosure, login tickets of any object generated by a plurality of authentication service nodes (including the first authentication service node 410 and the second authentication service node 420) may be pushed to the queue cluster 420 through its own local queue, and is not limited to the first authentication service node 410 illustrated herein.
In the embodiment of the disclosure, the authentication service is deployed in multiple places or multiple centers and is in a 'multiple-active' state, i.e. the multiple authentication service nodes are all working normally at the same time, and the data among the multiple authentication service nodes are synchronous and consistent. Therefore, when any authentication service node fails, the authentication service node can be quickly switched to any other authentication service node, and the consistency of data before and after switching can be ensured.
The second authentication service node 420 may include a second local cache 432 and a second queue consumer 431. The second queue consumer 431 is configured to receive the login ticket of the target object distributed by the queue cluster 420, and push the login ticket of the target object to the second local cache 432.
In an exemplary embodiment, the second queue consumer 431 may also be configured to return a response message (ack) to the queue cluster 420 acknowledging receipt of the login ticket for the target object. That is, after receiving the login ticket of the target object distributed by the queue cluster 420, the second queue consumer 431 may return a response message to the queue cluster 420 to inform the queue cluster 420 that the login ticket of the target object has been received, and if the queue cluster 420 waits for a preset time period (which may be set according to an actual scene, and not limited in this disclosure) after pushing the login ticket of the target object, and does not receive the response message returned by the second authentication service node 430, the queue cluster 420 may consider that data loss occurs, and the queue cluster 420 may resend the login ticket of the target object.
Similarly, when the first local queue 412 pushes the login ticket of the target object to the queue cluster 420, the response message of the login ticket of the target object may be received by waiting for confirmation returned by the queue cluster 420, otherwise, the first local queue 412 may resend the login ticket of the target object.
In the embodiment of the present disclosure, the second authentication service node 420 may be any one of the plurality of authentication service nodes. The second local cache 432 may employ, for example, dis (Remote Dictionary Server, remote dictionary service), but the present disclosure is not limited thereto, and other similar products may be employed as long as the cache function can be implemented.
According to the login bill synchronization system provided by the embodiment of the disclosure, on one hand, by distributing the authentication service nodes (at least comprising the first authentication service node and the second authentication service node), namely, deploying a plurality of authentication service nodes in multiple points or multiple places or multiple rooms, the login bill synchronization system can ensure that when one authentication service node fails, the login bill synchronization system can be quickly switched to other authentication service nodes which normally work, so that the user login process is not influenced, and the high availability of service sites is ensured; on the other hand, the login ticket of the target object generated by the first ticket service module of the first authentication service node can be pushed into the queue cluster through the first local queue in each authentication service node, such as the first authentication service node, so that the queue cluster can further push the login ticket of the target object to other authentication service nodes except the first authentication service node, such as the second authentication service node, and the second authentication service node can receive the login ticket of the target object through the second queue consumer and store the login ticket of the target object into the second local cache, and consistency of the login ticket between the first authentication service node and the second authentication service node can be achieved. When the target object logs in again at other authentication service nodes, the login bill of the target object can be directly obtained from the local cache of the target object, and the SSO function can be realized without regenerating the login bill.
Fig. 5 schematically illustrates a block diagram of a login ticket synchronization system according to an embodiment of the present disclosure. The fig. 5 embodiment differs from the fig. 4 embodiment in that the second authentication service node 430 may further comprise a second ticket service module 433. The second ticket service module 433 may be configured to receive a second login request of the target object, obtain, in response to the second login request, a login ticket of the target object from the second local cache 432, and verify the second login request according to the login ticket of the target object.
For example, assuming that the user a logs in the service site of the service a on the first authentication service node 410 for the first time, a login ticket of the user a is generated, and then pushed to the queue cluster 420 through the first local queue 412, and then the queue cluster 420 is redistributed to the second queue consumer 431 of the second authentication service node 430, and the second queue consumer 431 stores the login ticket of the user a in the second local cache 432 again, thereby implementing consistency of the login ticket of the user a between the first authentication service node 410 and the second authentication service node 430, at this time, if the user a logs in the service site of the service B on the second authentication service node 430, the login ticket does not need to be regenerated, but the login ticket of the user a can be obtained directly from the second local cache 432, that is, the login ticket does not need to be regenerated for the second login or other logins except for the first login, and the second authentication service node 430 can normally and sequentially pass verification of the login ticket of the user a, thereby implementing the SSO function.
With continued reference to fig. 5, the first authentication service node 410 may further include a first local cache 413, where the first local cache 413 may be configured to cache login tickets for the target object pushed by the first ticket service module 411. When the first ticket service module 411 generates the login ticket of the target object, the login ticket of the target object may be first stored in the first local cache 413 and then pushed to the first local queue 412.
In the fig. 5 embodiment, second authentication service node 430 may also further include a second local queue 434 and first authentication service node 410 may further include a first queue consumer 414. For example, when user b logs in at the second authentication service node 430 for the first time, a user b login ticket may be generated by the second ticket service module 433, and similarly, the second ticket service module 433 may store the user b login ticket in the second local buffer 432, and then push the user b login ticket to the second local queue 434, the second local queue 434 may push the user b login ticket to the queue cluster 420, the queue cluster 420 may distribute the user b login ticket to other authentication service nodes, such as the first authentication service node 410, and the first queue consumer 414 of the first authentication service node 410 may store the user b login ticket in the first local buffer 413. Thus, when the user b logs in again at the first authentication service node 410, the login ticket of the user b may be directly obtained from the first local cache 413.
Fig. 6 schematically illustrates a block diagram of a login ticket synchronization system according to an embodiment of the present disclosure.
As shown in fig. 6, for the scenario of multi-center login ticket synchronization, after the SSO takes the user's login ticket, the authentication service is called through the admission gateway/API gateway to decrypt the login ticket. Assume in the fig. 6 embodiment that a user first logs in to the first authentication service center 410 and generates a login ticket. The first ticket service module 411 of the first authentication service center 410 will buffer the login ticket to the first local cache 413 and push it to the first local queue 412, pushing it to the queue cluster 420 of the data layer via the first local queue 412.
The second queue consumer 431 of the second authentication service node 430 obtains the login ticket pushed by the queue cluster 420, returns a response message to the queue cluster 420 confirming that the login ticket is received, and pushes the response message to the second local cache 432 of the second authentication service node 430.
When the user logs in the second authentication service node 430, the second authentication service node 430 may obtain, in the second local cache 432, a login ticket that has been generated by the user in the first authentication service node 410, and perform verification, so as to implement user login.
The scheme provided by the embodiment of the disclosure can keep consistency of login notes generated by the multi-center authentication service nodes, so that distributed deployment of authentication services is possible. In deployment, the authentication service can be deployed in a multi-place multi-center mode, for example, multi-point deployment is performed in Shenzhen 3 (only used for illustration) machine rooms, tianjin 1 machine rooms, virtual centers on cloud and the like, so that disaster recovery capacity is greatly improved, and service reliability is ensured to be more than 99.99%.
It should be noted that, the access layer in the embodiments of the present disclosure may use the access layer of the authentication service itself instead of the gateway.
With continued reference to fig. 6, the login ticket synchronization system 400 may also include a Mongo cluster 440.Mongo is a database based on distributed file storage, and Mongo clusters implement Mongo databases with multiple servers. In the embodiment of fig. 6, each authentication service node may receive a short message verification request sent by a user, and after receiving the short message verification request, the ticket service module of each authentication service node may send a short message verification code to the outside, and may record relevant information of the short message verification code to a log, and may store the log to the Mongo cluster 440. It will be appreciated that Mongo clusters are optional.
In the embodiment of fig. 6, the login ticket synchronization system 400 may further include a cache cluster 450, where the cache cluster is implemented by one or more servers, for example, a Redis cache may also be used, but the disclosure is not limited thereto, so long as a cache function can be implemented. Cache cluster 450 may be used as persistent data, cache cluster 450 may include an authentication service center cache, the local caches of the respective authentication service nodes may include an authentication service local cache and a rights verification local cache, and second local cache 432 may further include a second authentication service local cache and a second rights verification local cache, as exemplified herein by a second local cache of a second authentication service node. The login ticket generated by each authentication service node can be cached in the authentication service center cache of the own authentication service local cache and the cache cluster 450, the authentication service center cache of the cache cluster 450 can distribute the received login ticket to other authentication service nodes, and after the other authentication service nodes receive the login ticket distributed by the authentication service center cache of the cache cluster 450, the received login ticket can be cached in the authentication service center cache of the corresponding authentication service node.
In the embodiment of fig. 6, the authentication service center cache may also be used to cache object information of each object, for example, enterprise employees, where the object information is employee information. The authentication service center cache may synchronize employee information in the HRC at regular time (a specific timing duration may be configured in the configuration service, which is not limited by the present disclosure), and then the authentication service center cache distributes the employee information to the authentication service local caches of the respective authentication service nodes.
For example, the second ticket service module 433 may cache the generated login ticket to a second authentication service local cache and an authentication service center cache, which in turn distributes the login ticket and its object information to a first authentication service local cache in the first local cache 413 of the first authentication service node 410. Thus, when the first authentication service node 410 receives the login request of the target object, the first ticket service module 411 may directly obtain the login ticket of the target object and the object information thereof from the local cache of the first authentication service itself, and decrypt the login ticket by using the object information of the target object without relying on external services (such as account number/password login service, token service, code scanning service, HRC and other external dependent services), that is, the first authentication service node 410 may implement the high-availability SSO login function by itself, and if the external dependent services fail, the authentication login process of the authentication service node will not be affected.
In the login ticket synchronization system provided by the embodiment of the present disclosure, the cache cluster 450 may be further used to cache employee information, and may synchronize the employee information from the HRC at regular time, and then asynchronously store the employee information to the local caches of the authentication service nodes, so that when the employee information needs to be used to decrypt the login ticket, the authentication service nodes may directly obtain the employee information from their own local caches, without relying on external employees and organization architecture services, and thus, even if the employee and organization architecture services fail, the user login process will not be affected.
In the embodiment of fig. 6, the cache cluster 450 may further include a rights verification center cache, and the local caches of the corresponding authentication service nodes may further include a rights verification local cache, where the rights verification local cache may be used to cache the rights verification information. The newly configured authority verification information can be uploaded to the authority verification local cache of any authentication service node, then the authority verification local cache of the authentication service node caches the newly configured authority verification information to the authority verification center cache, the authority verification center cache distributes the newly configured authority verification information to other authentication service nodes, and other authentication service nodes cache the newly configured authority verification information to the authority verification local cache of the authentication service node.
Taking the second local cache of the second authentication service node as an example for illustration, the second local cache 432 may further include a second rights verification local cache, provided that the rights verification information stored in the second rights verification local cache is a Passport ACL blacklist, i.e. an object on the blacklist does not have a right to access the target site. That is, the second bill service module 433 may determine whether the target object is in the blacklist and determine whether the target object is restricted from accessing the target site, and if the target object is in the blacklist and restricted from accessing the target site, the second bill service module 433 returns a verification result of verification failure to the target object; if the target object is not in the blacklist or is not limited to access to the target site although the target object is in the blacklist, the second ticket service module 433 returns a verification result of successful verification or passing verification to the target object, and at this time, a page of the target site may be displayed on a client or browser of the target object.
For example, the second ticket service module 433 may be configured to decrypt a login ticket for the target object based on object information for the target object obtained from a second authentication service local cache. And then, the second ticket service module 433 can acquire the authority verification information from the second authority verification local cache, and verify the decrypted login ticket of the target object according to the authority verification information, so as to acquire a verification result that verification fails or passes.
It can be understood that the local cache of the authority verification of each authentication service node is not limited to the above-mentioned report ACL blacklist, but other authority verification methods may be adopted, for example, a whitelist may also be cached, that is, a mapping relationship between an object with access authority and a target site is stored, and an object on the whitelist has authority to access the target site, which is not limited by the present disclosure.
According to the login bill synchronization system provided by the embodiment of the disclosure, the authority check local cache of the login bill synchronization system is arranged in the authentication service node, and the authority check information is stored in the authority check local cache, so that on one hand, the security of a login authentication process can be further improved; on the other hand, the authentication service node can realize the permission verification by itself without depending on external Passport ACL service, thereby improving the availability of the authentication service node.
The login bill synchronization system provided by the embodiment of the disclosure optimizes the scheme of the related technology, creatively designs a high-availability scheme which can complete login only by relying on the authentication service node, and can reach the following fault tolerance and disaster tolerance standards: by adopting a distributed mode and a cache technology, the strong coupling between the authentication service node and the database is released, so that when the database fails, the login service is still available. The staff information is read through the local cache of the authentication service node, so that the authentication service node can not depend on staff and organization architecture services, when the staff and organization architecture services fail, login services are still available, and the influence on users and the loss on enterprises are reduced.
In an exemplary embodiment, the second authentication service node may further include a second ticket service module, where the second ticket service module may be configured to receive a second login request of the target object, and send error code information if a login ticket of the target object is not acquired from the second local cache in response to the second login request.
In an exemplary embodiment, the login ticket of the target object carries a first authentication service node identifier; wherein the system may further comprise: and the access layer is used for receiving the error code information returned by the second bill service module, and acquiring a login bill of the target object from the first authentication service node according to the first authentication service node identifier so as to verify the second login request.
In an actual application scenario, there may be a delay in synchronizing login tickets between authentication service nodes of different centers, that is, when a user performs login authentication on another authentication service node that is not logged in for the first time, the login ticket generated by the authentication service node that the user logs in for the first time may not be synchronized to the other authentication service node, and for the scenario of synchronization delay of the login ticket, the embodiment of the present disclosure provides a solution as shown in fig. 7.
As shown in fig. 7, the following steps may be included:
1) The user sends a first login request and enters the SSO site through the admission gateway. The SSO site enters a service site to be logged in currently by the user, and the service site calls authentication service through an API gateway.
2) It is assumed here that the user first logs in at a first authentication service node and generates a login ticket, which the first authentication service node caches in its first local cache.
3) The first authentication service node pushes the login ticket to the queue cluster, and the login ticket is not synchronized to the second authentication service node.
4) The user issues a second login request and enters the SSO site through the admission gateway. The SSO site enters a service site to be logged in currently by the user, and the service site calls authentication service through an API gateway.
5) The user logs in at a second authentication service node.
6) At this time, since the second authentication service node has not synchronized the login ticket of the user, the second authentication service node cannot verify the login ticket, and then the second authentication service node returns an explicit error code (error code) to the API gateway.
7) After receiving the error code returned by the second authentication service node, the API gateway searches the first authentication service node generating the login bill according to the first authentication service node identification in the login bill, and forwards the login bill to the first authentication service node issuing the login bill for verification.
According to the login bill synchronization system provided by the embodiment of the disclosure, through the login bill tracing, login authentication can be successfully completed under the scene of login bill synchronization delay, normal login of a user is not influenced, and the usability of the system is further improved.
Fig. 8 schematically illustrates a flowchart of a login ticket synchronization method according to an embodiment of the present disclosure. The method provided by the embodiment of fig. 8 may be applied to a first authentication service node comprising a first local queue. As shown in fig. 8, the method provided by the embodiment of the present disclosure may include the following steps.
In step S810, a first login request for a target object is received.
In step S820, a login ticket for the target object is generated in response to the first login request.
In step S830, the login ticket of the target object is pushed to the first local queue.
In step S840, the login ticket of the target object is pushed to a queue cluster through the first local queue, so that the queue cluster distributes the login ticket of the target object to a second authentication service node.
In an exemplary embodiment, the first authentication service node may further include a first local cache. Wherein the method may further comprise: and caching the login bill of the target object to the first local cache.
In an exemplary embodiment, the method may further include: receiving a second login request; acquiring a login bill of the target object from the first local cache; and verifying the second login request according to the login bill of the target object.
Other contents of the login ticket synchronization method of the embodiment of the present disclosure may refer to the above-described embodiments.
Fig. 9 schematically illustrates a flowchart of a login ticket synchronization method according to an embodiment of the present disclosure. The method provided by the embodiment of fig. 9 may be applied to a second authentication service node, which may include a second local cache. As shown in fig. 9, the method provided by the embodiment of the present disclosure may include the following steps.
In step S910, a login ticket of a target object distributed by the queue cluster is received, where the login ticket of the target object is generated by the first authentication service node.
In step S920, the login ticket of the target object is pushed to the second local cache.
In an exemplary embodiment, the method may further include: receiving a second login request of the target object; responding to the second login request to acquire a login bill of the target object from the second local cache; and verifying the second login request according to the login bill of the target object.
In an exemplary embodiment, the login ticket of the target object carries the first authentication service node identifier. Wherein the method may further comprise: receiving a second login request of the target object; and if the second login request does not acquire the login ticket of the target object from the second local cache, transmitting error code information to an access layer so that the access layer acquires the login ticket of the target object from the first authentication service node according to the first authentication service node identifier, and verifying the second login request.
Other contents of the login ticket synchronization method of the embodiment of the present disclosure may refer to the above-described embodiments.
Fig. 10 schematically illustrates a flowchart of a login ticket synchronization method according to an embodiment of the present disclosure. The method provided by the embodiment of fig. 10 may be applied to a queue cluster. As shown in fig. 10, the method provided by the embodiment of the present disclosure may include the following steps.
In step S1010, a login ticket of a target object pushed by the first queue service node is received.
In step S1020, the login ticket of the target object is pushed to the second queue service node.
Other contents of the login ticket synchronization method of the embodiment of the present disclosure may refer to the above-described embodiments.
It should be noted that although in the above detailed description several units of the apparatus for action execution are mentioned, such a division is not mandatory. Indeed, the features and functions of two or more of the units described above may be embodied in one unit in accordance with embodiments of the present disclosure. Conversely, the features and functions of one unit described above may be further divided into a plurality of units to be embodied.
From the above description of embodiments, those skilled in the art will readily appreciate that the example embodiments described herein may be implemented in software, or may be implemented in software in combination with the necessary hardware. Thus, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-ROM, a U-disk, a mobile hard disk, etc.) or on a network, and includes several instructions to cause a computing device (may be a personal computer, a server, a touch terminal, or a network device, etc.) to perform the method according to the embodiments of the present disclosure.
Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any adaptations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.
It is to be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims (12)

1. A logon ticket synchronization system comprising:
the first authentication service node comprises a first bill service module and a first local queue, wherein the first bill service module is used for receiving a first login request of a target object, responding to the first login request, generating a login bill of the target object and pushing the login bill of the target object to the first local queue;
The queue cluster is used for receiving the login bill of the target object pushed by the first local queue;
The second authentication service node comprises a second local cache and a second queue consumer, wherein the second queue consumer is used for receiving the login bill of the target object distributed by the queue cluster and pushing the login bill of the target object to the second local cache;
The second authentication service node further comprises a second bill service module, wherein the second bill service module is used for receiving a second login request of the target object, responding to the second login request, acquiring a login bill of the target object from the second local cache, and verifying the second login request according to the login bill of the target object.
2. The login ticket synchronization system of claim 1, wherein the first authentication service node further comprises a first local cache for caching login tickets for the target object pushed by the first ticket service module.
3. The login ticket synchronization system of claim 2, wherein the second authentication service node further comprises a second ticket service module for receiving a second login request for the target object, and transmitting error code information if a login ticket for the target object is not acquired from the second local cache in response to the second login request.
4. The login ticket synchronization system according to claim 3, wherein a login ticket of the target object carries a first authentication service node identifier; wherein the system further comprises:
And the access layer is used for receiving the error code information returned by the second bill service module, and acquiring a login bill of the target object from the first authentication service node according to the first authentication service node identifier so as to verify the second login request.
5. The login ticket synchronization system of claim 1, wherein the second queue consumer is further configured to return a response message to the queue cluster acknowledging receipt of the login ticket for the target object.
6. The login bill synchronization method is characterized by being applied to a first authentication service node, wherein the first authentication service node comprises a first local queue; wherein the method comprises the following steps:
Receiving a first login request of a target object;
Generating a login ticket of the target object in response to the first login request;
Pushing the login bill of the target object to the first local queue;
Pushing the login ticket of the target object to a queue cluster through the first local queue, so that the queue cluster distributes the login ticket of the target object to a second authentication service node;
The second authentication service node comprises a second local cache, a second queue consumer and a second bill service module, wherein the second queue consumer is used for receiving the login bill of the target object distributed by the queue cluster and pushing the login bill of the target object to the second local cache; the second bill service module is used for receiving a second login request of the target object, responding to the second login request, acquiring a login bill of the target object from the second local cache, and verifying the second login request according to the login bill of the target object.
7. The login ticket synchronization method according to claim 6, wherein said first authentication service node further comprises a first local cache; wherein the method further comprises:
And caching the login bill of the target object to the first local cache.
8. The login ticket synchronization method according to claim 7, further comprising:
Receiving a second login request;
acquiring a login bill of the target object from the first local cache;
And verifying the second login request according to the login bill of the target object.
9. The login bill synchronization method is characterized by being applied to a second authentication service node, wherein the second authentication service node comprises a second local cache, a second queue consumer and a second bill service module; wherein the method comprises the following steps:
The second queue consumer receives a login bill of a target object distributed by a queue cluster, wherein the login bill of the target object is generated by a first authentication service node;
the second queue consumer pushes the login bill of the target object to the second local cache;
The second bill service module receives a second login request of the target object;
The second bill service module responds to the second login request to acquire a login bill of the target object from the second local cache;
And the second bill service module verifies the second login request according to the login bill of the target object.
10. The login ticket synchronization method according to claim 9, wherein a login ticket of the target object carries a first authentication service node identifier; wherein the method further comprises:
receiving a second login request of the target object;
And if the second login request does not acquire the login ticket of the target object from the second local cache, transmitting error code information to an access layer so that the access layer acquires the login ticket of the target object from the first authentication service node according to the first authentication service node identifier, and verifying the second login request.
11. A computer readable storage medium, characterized in that a computer program is stored thereon, which program, when being executed by a processor, implements the method according to any of claims 6 to 10.
12. An electronic device, comprising:
One or more processors;
storage means configured to store one or more programs which, when executed by the one or more processors, cause the one or more processors to implement the method of any of claims 6 to 10.
CN202010393683.7A 2020-05-11 2020-05-11 Login bill synchronization system and method and related equipment Active CN111651747B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010393683.7A CN111651747B (en) 2020-05-11 2020-05-11 Login bill synchronization system and method and related equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010393683.7A CN111651747B (en) 2020-05-11 2020-05-11 Login bill synchronization system and method and related equipment

Publications (2)

Publication Number Publication Date
CN111651747A CN111651747A (en) 2020-09-11
CN111651747B true CN111651747B (en) 2024-05-24

Family

ID=72346887

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010393683.7A Active CN111651747B (en) 2020-05-11 2020-05-11 Login bill synchronization system and method and related equipment

Country Status (1)

Country Link
CN (1) CN111651747B (en)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112231667B (en) * 2020-11-09 2022-02-18 腾讯科技(深圳)有限公司 Identity verification method, device, storage medium, system and equipment
CN112613010A (en) * 2020-12-28 2021-04-06 北京世纪互联宽带数据中心有限公司 Authentication service method, device, server and authentication service system
CN113157812A (en) * 2021-05-21 2021-07-23 湖南快乐阳光互动娱乐传媒有限公司 Method and system for synchronizing distributed multi-cluster state class data
CN114285699B (en) * 2021-12-20 2023-06-06 徐工汉云技术股份有限公司 Method and device for realizing uniqueness of terminal in distributed gateway session

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101296245A (en) * 2008-06-26 2008-10-29 腾讯科技(深圳)有限公司 Login method and system of service server
CN103716292A (en) * 2012-09-29 2014-04-09 西门子公司 Cross-domain single-point login method and device thereof
CN104301418A (en) * 2014-10-23 2015-01-21 西安未来国际信息股份有限公司 Cross-domain single point login system and method based on SAML
CN109587147A (en) * 2018-12-11 2019-04-05 咪咕文化科技有限公司 Single sign-on system, method, server and storage medium
CN110083662A (en) * 2019-05-15 2019-08-02 国网江西省电力有限公司信息通信分公司 A kind of dual-active architecture construction method based on plateform system

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8196150B2 (en) * 2005-10-07 2012-06-05 Oracle International Corporation Event locality using queue services
US10237254B2 (en) * 2014-11-13 2019-03-19 Mcafee, Llc Conditional login promotion
US10454917B2 (en) * 2015-11-05 2019-10-22 Red Hat, Inc. Enabling single sign-on authentication for accessing protected network services
US10749854B2 (en) * 2015-11-12 2020-08-18 Microsoft Technology Licensing, Llc Single sign-on identity management between local and remote systems
US10122701B2 (en) * 2015-11-24 2018-11-06 Red Hat, Inc. Cross-domain single login

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101296245A (en) * 2008-06-26 2008-10-29 腾讯科技(深圳)有限公司 Login method and system of service server
CN103716292A (en) * 2012-09-29 2014-04-09 西门子公司 Cross-domain single-point login method and device thereof
CN104301418A (en) * 2014-10-23 2015-01-21 西安未来国际信息股份有限公司 Cross-domain single point login system and method based on SAML
CN109587147A (en) * 2018-12-11 2019-04-05 咪咕文化科技有限公司 Single sign-on system, method, server and storage medium
CN110083662A (en) * 2019-05-15 2019-08-02 国网江西省电力有限公司信息通信分公司 A kind of dual-active architecture construction method based on plateform system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
跨域单点登录解决方案研究;伍孟轩;李伟;易叔海;程蒙;刘川;;网络安全技术与应用;20180215(第02期);第52-54页 *

Also Published As

Publication number Publication date
CN111651747A (en) 2020-09-11

Similar Documents

Publication Publication Date Title
US11652685B2 (en) Data replication conflict detection and resolution for a multi-tenant identity cloud service
CN111651747B (en) Login bill synchronization system and method and related equipment
US11023555B2 (en) Cookie based state propagation for a multi-tenant identity cloud service
CN111801923B (en) Replication of resource types and schema metadata for multi-tenant identity cloud services
US11258786B2 (en) Generating derived credentials for a multi-tenant identity cloud service
US11321343B2 (en) Tenant replication bootstrap for a multi-tenant identity cloud service
US11088903B2 (en) Hybrid cloud network configuration management
US11669321B2 (en) Automated database upgrade for a multi-tenant identity cloud service
CN111651739B (en) Login authentication service system and method, authentication service node and electronic equipment
US11687378B2 (en) Multi-tenant identity cloud service with on-premise authentication integration and bridge high availability
CN111552676A (en) Block chain based evidence storing method, device, equipment and medium
CN112154639A (en) Multi-factor authentication without user footprint
CN112261172B (en) Service addressing access method, device, system, equipment and medium
CN112149105A (en) Data processing system, method, related device and storage medium
US11943260B2 (en) Synthetic request injection to retrieve metadata for cloud policy enforcement
US9264414B2 (en) Retry and snapshot enabled cross-platform synchronized communication queue
CN113742676B (en) Login management method, login management device, login management server, login management system and storage medium
CN113271296B (en) Login authority management method and device
US9930063B2 (en) Random identifier generation for offline database
CN113271311A (en) Digital identity management method and system in cross-link network
CN112511316A (en) Single sign-on access method and device, computer equipment and readable storage medium
CN112511565A (en) Request response method and device, computer readable storage medium and electronic equipment
CN112291244A (en) Multi-tenant method for industrial production data real-time processing platform system
CN113055186B (en) Cross-system service processing method, device and system
CN113765876B (en) Report processing software access method and device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant