c/S Architecture program Single Sign-on between various types of servers

(i)

In the process of project development, often will appear this situation: Our products include many, to QQ example, such as landing, friend download, group download, network hard disk, QQ game, QQ music, etc., can not ask the user every time enter user name, password it, in order to solve this problem, master proposed a good cross-platform, A cross-app authentication solution, that is, single sign-on, which is referred to as SSO.
One, what is Single sign-on
Single Sign-on (Sso,single sign-on) is a user-friendly technology that allows users to access multiple systems at the time of login, allowing them to move freely between multiple systems without having to re-enter usernames and passwords to identify identities.
Second, how to achieve Single sign-on (SSO)
1. Overall design ideas
First of all, we need to identify the operating mode of single sign-on, that is, unified authentication, in the solution, generally through the authentication server (loginserver) to implement user authentication, verification will automatically randomly generate the authentication ticket, and the authentication ticket to the user, when the user access to other applications, Authentication tickets are only validated for legality.
2, the authentication Server (loginserver) realizes the function
In the solution, Loginserver provides features such as user name/password Authentication, authentication ticket generation, authentication ticket legitimacy verification of the three most basic functions, and other functions can be self-expanding according to the needs of users.
Because Loginserver is based on network traffic and uses TCP or UDP protocols, it is cross-platform by itself and can invoke the authentication platform for related operations as long as the development language used by each application in the development process supports authentication ticket validation.
3. Authentication ticket
The so-called authentication ticket is a user authentication pass, sent to the user to identify the authentication through the information. Authentication tickets can be encrypted to save the user's identity or a specific authentication information, such as the general use of symmetric encryption, easy to verify the legitimacy of the authentication ticket for the corresponding decryption. c/S structure of the program, note preservation is more convenient, as long as other applications can be taken.
4. Verification Notes
After the user gets the authentication ticket, when logging into the B system, the ticket to B system, B system to take this ticket system to loginserver for certification.

Two

In the above document, the introduction of the S-schema program to achieve single sign-on between various types of server process, but when the user is huge or a product repeated login frequently, this single sign-on (SSO) implementation has a bottleneck, as follows:
It is difficult to share data between multiple Loginserver servers, which can be difficult to deploy across the computer room only through shared memory or database sharing.
As the volume of business increases, the demand for loginserver services is also soaring, and the probability of problems is high, often resulting in a normal user certification failure.
In order to solve the above problems, it is recommended that the certificate of the instrument is completed by the subsystem, which reduces the probability of the problem and reduces the server pressure. The specific method is as follows:
1. Encrypt the authentication ticket
Loginserver servers use symmetric encryption algorithms to encrypt authentication tickets, such as RC6, AES, and Blowfish, which include information such as user name, authentication time, IP address, custom data, and so on. After the client logs in, Loginserver notifies the client of the encrypted secret string.
2. Verifying Identity Notes
Other systems and Loginserver servers share symmetric encryption algorithms and keys, get the client's secret string after the same algorithm and key decryption, and then compare the user name, authentication time, IP address, custom data, such as the same is allowed to log in.
3, security issues
We know that symmetric encryption algorithm crack is possible, in the case of the algorithm is known, the key, clear text, ciphertext, the three can be calculated by the other two; in the above method, the clear text added custom data, user name, authentication time for each user are different, so hackers generally can not get normal plaintext We only notify the client of ciphertext, so the client should not be able to get clear text + key through ciphertext exhaustive, so it cannot be cracked.
4. Source code Leakage
If the server source code is compromised, it is possible to disclose encryption algorithms, keys, plaintext, and so on, the remedy is to update the key in time, adjust the custom data, all products need to be updated at the same time, clear text and keys are changed, the risk of leaking code can be ignored.
If the server architecture is smart enough, you can periodically update the key and custom data, such as updates every month, the entire implementation system is very secure; Remember to do a good job of compatibility when updating keys, making sure that the identity tickets that users get before they are updated can be validated for a certain amount of time.
5. Scope of Use
There is no problem with this method for your company's servers, but if you are signing in to another partner's product, you will need to negotiate the encryption key and custom data separately.

c/S Architecture program multi-Class Server to achieve Single sign-on (GO)