http://blog.csdn.net/cutesource/article/details/5838693
http://blog.csdn.net/cutesource/article/details/5838693
Single sign-on SSO (Single Sign On) simply means that in a multi-system coexistence environment, after a user logs in in one place, he does not need to log in in other systems, that is, a user can get all other systems' information after one login. trust. Single sign-on is used very frequently in large websites, such as a website like Alibaba. Behind the website are hundreds or thousands of subsystems. One user operation or transaction may involve the cooperation of dozens of subsystems. All subsystems require user authentication. Not only will the user go crazy, but each subsystem will also go crazy for this logic of repeated authentication and authorization. In the final analysis, the realization of single sign-on is to solve how to generate and store that trust, and then how to verify the validity of this trust by other systems, so the main points are as follows:
- store trust
- Verify trust
As long as the above problems are solved and the effect mentioned at the beginning is achieved, it can be said to be SSO. The easiest way to implement SSO is to use cookies. The implementation process is as follows:
Otherwise, it is found that the above solution is to store the trust in the client's cookie. Although this method is convenient to implement, it will immediately make people question two questions:
- Cookies are not secure
- No cross-domain free login
The first problem is usually solved by encrypting cookies, and the second problem is flawed. In fact, the idea of this scheme is to store the trust relationship on the client side. To achieve this, you may not only use cookies. , It can also be solved by flash, and the Shared Object API of flash provides storage capability.
Generally speaking, large-scale systems will adopt the practice of storing trust relationships on the server side. The implementation process is as follows:
The above solution is to store the trust relationship in a separate SSO system (for the time being called it), which is simply moved from the client to the server, but several problems need to be solved:
- How to efficiently store a large amount of temporary trust data
- How to prevent the information transmission process from being tampered with
- How to make the SSO system trust the login system and the free-login system
For the first problem, a distributed cache solution similar to memcached can generally be used, which can provide a mechanism for scalable data volume and efficient access. For the second question, a digital signature method is generally adopted, either through a digital certificate signature or through a method like md5, which requires the SSO system to perform md5 encryption on the parameters to be verified when returning the login-free URL, and bring the token. Return together, and finally, when the login-free system is required to verify the trust relationship, the token needs to be passed to the SSO system, and the SSO system can identify whether the information has been changed by verifying the token. For the last problem, it can be handled through a whitelist. To put it simply, only the systems on the whitelist can request the production trust relationship. Similarly, only the systems on the whitelist can be exempted from login.
The above only provides some simple implementation technologies, but it should be emphasized that this is only a technical implementation, just to solve some of the problems mentioned above. SSO itself is not a high-tech, and it is more beneficial for us to have this understanding. Deep dive into SSO