Cookie+memcached for Single Sign-on

In 10, the first article in Iteye recorded how the single sign-on of our system was implemented. But at that time the article is not good, the thinking is very impetuous, it is difficult to understand, in CSDN's first technical blog intends to re-Wen Gu the idea of single-point landing at that time. Let's see what we call a single sign-on.

Single Sign-on, or SSO, is one of the most popular solutions for enterprise business integration at the moment. The definition of SSO is that in multiple application systems, users can access all trusted applications with only one login. It includes a mechanism that can map this major login to other apps for the same user's login. --Baidu Encyclopedia

Why do you want to achieve a single sign-on?

Since the new version of 10, we have cut some of the auxiliary functions vertically into separate applications, running in different application server clusters. Achieve single sign-on, to ensure the sharing of login status and user information between the various applications.

What are the problems with using cookies for single sign-on?

The first issue is the expiration time of the cookie problem, in order to achieve a single sign-on, there are many ways, we use to let all the applications under the root domain share cookie information, set the cookie expiration time, there are two cases: one is the expiration time is a value less than or equal to zero, so, The cookie information is kept in memory, the browser shuts down, and the cookie information becomes invalid. However, if the browser does not shut down, the cookie information will always be in memory, which will bring great hidden danger to the user's account security. The other is that the expiration time is a positive number, when set to a positive number, the cookie information will be saved on the user's hard disk, and when the cookie has not expired, even if the user closes the browser, as long as the browser to reopen access, the cookie information will be re-read, the login status recovery. In this way, there will be security implications. There is still a risk that you can only use cookies to achieve a single sign-on! Positive number is not good, 0 and negative numbers are not good, that set to what value? And what kind of way to solve it? In fact, there are two implementations of cookie+memcached that we use for reference.

1. The session maintenance mode is simulated, the user closes the browser, or the session time is inactive for a period of time, the session is disconnected. We set the expiration time of the cookie to a value less than or equal to 0 so that the session ends when the user closes the browser. The user information is saved to memcache, and if the user is inactive for 30 minutes, the value in memcached automatically expires and the user's session ends. Therefore, it is necessary to determine whether the user's session information is valid by two logic, one is to determine whether the cookie information is valid, one is to see whether there is user information in memcached. Two conditions are valid for a user's session. However, there is a problem with this usage: MEMCACHD is the cache, after the set expiration time is created, the expiration time, regardless of whether the user's cookie information persists, whether the user is still active, the memcached information will still be deleted. This causes the user to log on again after a period of inactivity. So user activity will reset the user information to the cache every time the login status is obtained. This solves the problem of the risk of the cookie information that we have mentioned above.

2, the use of memcached only to save user information, so as not too frequent access to user data through the interface, and in order to resolve the issue of cookie expiration, we also need to save the system time Long value in the cookie information. To record the time of the user's last activity, the logic determines whether the user's activity time exceeds the specified time period. This is a good understanding, I put your time in this activity in the cookie, when you next activity, and then the last saved time out, plus I specify the duration of the session expires, such as 20 minutes, whether before the current time, if so, the session expires, and need to log back in. In this way, each user activity is a cookie that needs to be refreshed, not memcached information, so that the memcached cache time can be set on its own.

The second issue is the security of cookies. Cookies are always stored in the user's browser and managed by the client, so it is very easy to find a tool that can modify cookie information, how to prevent the cookie information from being tampered with to ensure the security of single sign-on? We use the most common authentication signatures in the Internet, using a MD5 (private key + information character) algorithm for accessing cookie information, so that if our cookie information is deleted, the session is disconnected. If it is tampered with, the check does not pass and the session is disconnected.

Cookie+memcached Way to realize the whole process of single sign-on (the picture of the weak explosion, not caught dead)

As an example of how the cookie controls expiration, the Memcached control expires in 31. Generate cookie Information sso_login:memberid|time| when a user logs on MD5 (info) and set the cache, the user requests each time, first take out the cookie, verify the signature data, take out the generation time of the cookie and the current time to compare, verify whether expired; Again, if authentication passes, the user information in the cache is retrieved and the cookie is regenerated. The main is to refresh the cookie generation time, if the verification does not pass or expire, then enter the user login process. The key is in the format of that cookie, the format of the cookie is cookie.name=sso_login,value=memberid|time| MD5 (Info)

Cookie+memcached for Single Sign-on