Intranet and extranet synchronous security login authorization method

Abstract

The application discloses an internal and external network synchronous security login authorization method. Compared with the prior art, the application has the following advantages: a model is provided, and the model is characterized in that a "zero trust" idea is adopted to construct a security login authentication system, that is, in the default condition, no one, device, system and application inside and outside the network is trusted, and on the basis of identity authentication and authorization access control, data and requests of a trusted node are received, the security of the internal and external network synchronous login can be further improved, compared with a traditional mode, mutual authentication and checking operations between system nodes are added, the operations can enable the system to know whether a received request is from a trusted site, the possibility that an attacker cheats the system by forging a request is further reduced, even if the attacker obtains the external network system, it is difficult for the attacker to further sniff an open interface and a port of the internal network system, and therefore, the application has good applicability and is convenient to popularize.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of secure communication, in particular to a method for synchronously logging in and authorizing internal and external networks. BACKGROUND

[0002] In the current era of rapid technological development, the security of login is undoubtedly the focus of people's attention, and the number of attacks based on login security is countless every year. Therefore, protecting user login security and data is crucial. The login interface is the first line of defense for most products. Once it cannot resist the attack of hackers, a series of unimaginable consequences will occur, resulting in significant losses.

[0003] Therefore, how to improve the security of login and protect the data privacy of information systems and users is a problem to be solved by technical personnel.

[0004] The existing internal and external network synchronous secure login technology is currently a popular method that uses a single sign-on-like internal and external network authorization technology. The general process of this technology is as follows:

[0005] 1) The user accesses the internal system, and the user has not logged in to the internal system, so the request is sent to jump to the external system;

[0006] 2) The external system verifies the username and password filled by the user, and writes the login status into the session of the external system after successful authentication. The browser writes a cookie under the domain of the external system;

[0007] 3) After the external system login is completed, a ticket is generated, and then the ticket is requested to the internal system as a parameter;

[0008] 4) The internal system obtains the ticket and inquires the external system whether the ticket is valid;

[0009] 5) After the external system verifies successfully, the internal system returns a successful identification back to the internal system, and the internal system writes the login status into the session and writes a cookie under the internal system domain. SUMMARY

[0010] The technical problem to be solved by the present application is that there are many security risks in the current common internal and external network authorization technology, because the source of the request is not verified and reviewed, which may cause exposure of system information and leakage of key data. For example, in the scenario introduced in the background art, once the external system is hacked by a hacker, the hacker forges a fake ticket in the above-mentioned third step, and requests the internal system with the fake ticket as a parameter. Because the internal system is uncertain about the source of the request, the internal system asks the external system with the fake ticket forged by the hacker in the fourth step. When the hacker intercepts the fourth step, the hacker tampers with the returned data content to make the internal system believe that the fake ticket is true. In this way, the hacker can easily obtain the data of the internal system without logging in.

[0011] To solve the above technical problems, the technical solution provided by the present application is as follows: a method for synchronous security login authorization of internal and external networks, comprising the following steps:

[0012] Step 1: the user logs in on the external system, and inputs the username and password;

[0013] Step 2: the external system checks the username and password, and obtains the authorization of the internal system after the checking is successful;

[0014] Step 3: the external system stores the login information of the user into a session, and then sends a request to the front-end system with the encrypted login information of the user and the session ID as parameters, wherein the session ID is a unique value corresponding to the session of the user this time, and has randomness and temporality, and will be invalid after a certain time limit;

[0015] Step 4: the front-end system receives the request, and forwards the received data packet to the internal system;

[0016] Step 5: after receiving the request of the front-end system, the internal system is uncertain about the source of the request, so it needs to verify who initiates the request, and then inquires the front-end system with the obtained data packet;

[0017] Step 6: the front-end system forwards the inquiry request of the internal system to the observer;

[0018] Step 7: the observer receives the data packet of the internal system, and verifies the external system through the obtained data packet;

[0019] Step 8: the external system receives the data packet, and verifies the data packet;

[0020] Step 9: the external system returns the verification result to the observer;

[0021] Step 10: the observer receives the verification result returned by the external system, and returns the verification result to the front-end system;

[0022] Step 11: the verification result is returned to the intranet system from the pre-system again;

[0023] Step 12: the intranet system obtains the verification result, if the result shows that the information source verification fails, the authorization operation is stopped, if the result shows that the information source verification succeeds, the next step of verification of user information is performed;

[0024] Step 13: the intranet system user information verification succeeds, and the intranet system issues a token to the pre-system;

[0025] Step 14: the pre-system receives the token and forwards the token to the extranet system;

[0026] Step 15: when the user accesses the intranet data subsequently, the token is carried and the transmitted content is encrypted;

[0027] Step 16: the pre-system receives the data transmitted by the extranet system and forwards the data to the intranet system;

[0028] Step 17: the intranet system checks the token;

[0029] Step 18: after the checking, the intranet system returns the request to the pre-system;

[0030] Step 19: the pre-system forwards the request to the extranet system.

[0031] Compared with the prior art, the application has the advantages that the application proposes a model, characterized in that a "zero trust" idea is adopted to construct a secure login authentication system, that is, under the default condition, no one, device, system and application inside and outside the network is trusted, and on the basis of identity authentication and authorization access control, data and requests of trusted nodes are received, the security of the synchronous login of the intranet and the extranet can be further improved, compared with the traditional mode, an operation of verifying the message source is added, the system can know whether the request is sent from a trusted site, the probability that a hacker successfully cheats the system by forging a request is further reduced, the intranet and the extranet are isolated, even if the attacker obtains the extranet system, it is difficult to further sniff the open interface and port of the intranet system, and the security risk of illegally obtaining the intranet data by the hacker is reduced.

[0032] Further, in step six, the observer is located in the external third-party network and serves as a third party between the intranet system and the extranet system, in the "zero trust" idea, the intranet application does not trust any external system and is in a checking and being checked process all the time, in the process of inquiring the detailed source in the intranet, the intranet system does not directly inquire the extranet system, but first inquires the trusted observer, the observer inquires the extranet system, and finally the observer informs the intranet system of the inquiry result.

[0033] Further, in step fifteen, the token will be destroyed after the user logs out.

[0034] Further, step 8 is used to verify the data packet by the external network system, and the specific steps include

[0035] Step 8-1: Take the data in the request and perform non-empty verification on the parameters;

[0036] Step 8-2: Read the key from the configuration center, respectively decrypt the user's login information and session ID, and if the decryption fails, return the information of verification failure;

[0037] Step 8-3: After successful decryption, read the data corresponding to the session ID from the cache, and verify whether the data is consistent with the user's login information;

[0038] Step 8-4: If the result is consistent, return verification success, otherwise, return verification failure.

[0039] Further, step 12 is used to verify the user information by the internal network system, and the specific steps include:

[0040] Step 12-1: Take the data in the request and perform non-empty verification on the parameters;

[0041] Step 12-2: Read the key from the configuration center, respectively decrypt the user's login information and session ID, and if the decryption fails, return the information of verification failure;

[0042] Step 12-3: After successful decryption, take the user's login information and verify whether the user exists;

[0043] Step 12-4: If the user exists, return verification success, otherwise, return verification failure.

[0044] Further, step 17 is used to verify the token by the internal network system, and the specific steps include

[0045] Step 17-1: Judge whether the token is empty, if empty, directly intercept the request;

[0046] Step 17-2: Use the token as the key to read the issuance time corresponding to the token from the cache;

[0047] Step 17-3: Judge whether the issuance time is empty, if empty, directly intercept the request;

[0048] Step 17-4: Subtract the issuance time from the current time, if it exceeds a time limit, update the issuance time corresponding to the token in the cache to the current time, and finally let the request pass. BRIEF DESCRIPTION OF DRAWINGS

[0049] Fig. 1 It is a schematic diagram of the architecture flow of an internal and external network synchronous secure login authorization method of the present invention.

[0050] Fig. 2 It is a flow chart of step 8 of a method for synchronous secure login authorization for an intranet and an extranet of the present invention.

[0051] Fig. 3 It is a flow chart of step 12 of a method for authorizing synchronous secure login to an intranet and an extranet of the present invention. DETAILED DESCRIPTION

[0052] The present invention will be described in further detail below with reference to the accompanying drawings.

[0053] When the present invention is specifically implemented, Figs. 1-3 In the illustrated embodiment, the external network system, the internal network system, and the observer are all on separate networks. Requests from the internal network system to the observer, and from the observer to the external network system, are restricted using iptables, opening only the corresponding servers and ports. The external and internal network systems can be distributed, allowing user session information and login information to be stored in a distributed cache system, such as Redis. User login information primarily consists of data that verifies the user's uniqueness, such as their user ID or identification number. The front-end system serves as both an information dispatching bridge between the external and internal network systems and an exchange-centric platform, acting as a firewall between the internal and external networks. This conceals the internal network and ensures its security to a certain extent. Step 3 describes the process of encrypting user login information and session IDs. The key used in this process originates from the internal network's configuration center. When the external network system restarts, it first requests the front-end system, which then reads the data from the internal network's configuration center and sends it to the external network system for attribute configuration. This allows the internal and external network systems to share a common set of keys.

[0054] In one embodiment of the present invention, Figs. 1-3 As shown, the process of synchronous secure login authorization for internal and external networks provided in the embodiment of the present invention adds operations of mutual authentication and verification between system nodes compared to traditional methods. These operations can allow the system to know whether the received request comes from a trusted site, further reducing the security risk of hackers forging requests and sending fake tickets to deceive the internal network system. The process of verifying the message passes through the observer. Because the observer limits iptables, the interaction with the internal and external networks is point-to-point, so it plays a role in isolating the internal and external networks. Even if the attacker takes over the external network system, it is difficult to further sniff the open interfaces and ports of the internal network system.

[0055] In an embodiment of the present application, as shown in Figs. 1-3 In an embodiment of the present application, as shown in

[0056] In an embodiment of the present application, as shown in Figs. 1-3 In an embodiment of the present application, as shown in

[0057] In an embodiment of the present application, as shown in Figs. 1-3 In an embodiment of the present application, as shown in

[0058] In an embodiment of the present application, as shown in Figs. 1-3 In an embodiment of the present application, as shown in

[0059] In an embodiment of the present application, as shown in Figs. 1-3 In an embodiment of the present application, as shown in

[0060] In one embodiment of the present application, as shown in Figs. 1-3 The present application forms a trust chain with the observer, the pre-system, the external network system and the internal network system, and the internal network system entrusts the pre-system with its trust before inquiring the observer, and the external network system entrusts the pre-system with its trust before accessing the internal network system, so that the trust chain is linked with each other, and if one link is wrong, the final authorization result will be affected, thereby improving the security of information interaction.

[0061] In one embodiment of the present application, as shown in Figs. 1-3 Figs. 1-3 The safe login authorization method provided by the present application can be applied to different users and application scenarios as long as the interaction and authorization authentication between the internal and external network data are involved, and the internal and external network synchronization safe login authorization method provided by the present application can be used.

[0062] The basic principle and main features of the present application and the advantages of the present application are shown and described above, and those skilled in the art should understand that the present application is not limited to the above embodiments, and the above embodiments and the description in the specification are only to illustrate the principle of the present application, and various changes and improvements can be made without departing from the spirit and scope of the present application, and these changes and improvements all fall within the scope of the present application. The scope of protection of the present application is defined by the appended claims and their equivalents.

Claims

1. A method for synchronous secure login authorization of internal and external networks, characterized in that The following steps are involved: Step 1: The user logs in to the external network system and enters the user name and password; Step 2: The external network system verifies the username and password. After successful verification, it obtains authorization from the internal network system. Step 3: The external network system stores the user's login information in the session, and then sends a request to the front-end system with the encrypted login information and session ID as parameters. The session ID is a unique value corresponding to the user's session, which is random and temporary and will expire after a certain period of time. Step 4: The front-end system receives the request and forwards the received data packet to the intranet system; Step 5: After the intranet system receives the request from the front-end system, it needs to verify who initiated the request because it is not sure of the source of the request. It then queries the front-end system with the received data packet. Step 6: The front-end system forwards the query request from the intranet system to the observer; Step 7: The observer receives the data packet from the intranet system and verifies it through the extranet system. Step 8: The external network system receives the data packet and verifies the data packet; Step 9: The external network system returns the verification result to the observer; Step 10: The observer receives the verification result from the external network system and returns the verification result to the front-end system; Step 11: The front-end system then returns the verification result to the intranet system; Step 12: The intranet system obtains the verification result. If the result shows that the information source verification fails, the authorization operation is stopped. If the result shows that the information source verification succeeds, the next step is to verify the user information. Step 13: If the verification of the intranet system user information is successful, the intranet will issue a token to the front-end system; Step 14: After receiving the token, the front-end system forwards the token to the external network system; Step 15: When this user subsequently accesses intranet data, he or she will carry this token and encrypt the transmitted content; Step 16: The front-end system receives the data transmitted by the external network system and forwards it to the internal network system; Step 17: The intranet system verifies the token; Step 18: After verification, the intranet system returns the request to the front-end system; Step 19: The front-end system forwards the request to the external network system.

2. The method for synchronous secure login authorization for an intranet and an extranet according to claim 1, characterized in that: In step six, the observer is located in an external third-party network, serving as a third party between the intranet system and the extranet system. In the concept of "zero trust", the intranet application will not trust any external system and will be in a process of verification and being verified from beginning to end. When the intranet inquires about the detailed source, the intranet system will not directly inquire about the extranet system, but will first inquire about the observer it trusts, and the observer will inquire about the extranet system. Finally, the observer will inform the intranet system of the result of the inquiry.

3. The method for synchronous secure login authorization for an internal and external network according to claim 1, characterized in that: In step 15, the token will be destroyed after the user logs out.

4. The method for synchronous secure login authorization in an intranet and an extranet according to claim 1, characterized in that: The step 8 is used to verify the data packet in the external network system. The specific steps include: Step 8-1: Get the data in the request and verify that the parameters are not empty; Step 8-2: Read the key from the configuration center and decrypt the user's login information and session ID respectively. If the decryption fails, the verification failure message is returned; Step 8-3: After successful decryption, read the data corresponding to the session ID from the cache and verify whether the data is consistent with the user login information; Step 8-4: If the results are consistent, the verification is successful, otherwise it is returned as verification failure.

5. The method for synchronous secure login authorization in an internal and external network according to claim 1, characterized in that: Step 12 is used by the intranet system to verify user information, and the specific steps include: Step 12-1: Get the data in the request and verify that the parameters are not empty; Step 12-2: Read the key from the configuration center and decrypt the user's login information and session ID respectively. If the decryption fails, the verification failure message is returned; Step 12-3: After successful decryption, obtain the user's login information and verify whether the user exists; Step 12-4: If the user exists, the verification is successful, otherwise it returns a verification failure.

6. The method for synchronous secure login authorization in an intranet and an extranet according to claim 1, characterized in that: The step 17 is used for the verification of the token by the intranet system, and the specific steps include: Step 17-1: Determine whether the token is empty. If it is empty, intercept the request directly; Step 17-2: Use the token as the key and read the issuance time corresponding to the token from the cache; Step 17-3: Determine whether the issuance time is empty. If it is empty, directly intercept the request; Step 17-4: Subtract the issuance time from the current time. If it exceeds a time limit, update the issuance time corresponding to the token in the cache to the current time, and finally allow the request to pass.

Images