SSO Cookie Login analysis and implementation _php instance in PHP

What is SSO?

Single sign-on SSO (Sign-On) is a part of identity management. A more popular definition of SSO is that SSO is the same user who accesses protected resources in different applications of the same server and only needs to log in once, that is, after security validation in one application and access to protected resources in other applications, no longer requires a login verification

Purpose of SSO:

The current enterprise application environment, often has a lot of application systems, Taobao, Cat, Love Taobao and so on products such as office automation (OA) system, financial management system, file management system, Information Inquiry system and so on. These application systems serve the information construction of enterprises and bring good benefits to enterprises. However, it is not convenient for users to use these application systems. Each time users use the system, must enter the user name and user password, authentication, and the application system, the user account is different, users must also remember multiple sets of user names and user passwords. Especially for the number of application systems, the number of users are also many enterprises, this problem is particularly prominent. The cause of the problem is not the system development error, but the lack of overall planning, the lack of a unified user login platform, the use of SSO technology can solve these problems

Benefits of SSO:

User-friendly: From the point of view of the actual use of users

When users use the application system, they can log in once and use it more than once. Users no longer need to enter user names and user passwords each time, nor do they need to remember multiple user names and user passwords. A single sign-on platform can improve the user experience with application systems.
Convenient for administrators: from the day-to-day maintenance management point of view

Now a lot of big internet companies will have a lot of applications, such as the following is a screenshot of Taobao:

Days of the cat and the good news are different applications, and some even use a completely different domain name, but all Taobao registered users are using a set of username and password, if in these systems directly switch to do not log the state of synchronization, experience is very poor. Another chestnut, many internal systems also have many, such as HR system, financial system, attendance system, etc., if the staff in a system landing, jump to another system still need to land, it will make people very unhappy ...

Based on this, SSO (single Sign on) arises. Of course, we come to the reality of this demand there are many ways, the use of cookies is a relatively simple way, the main problem to be solved is: Cookies can not be passed across the domain, how to notify a domain of cookies to other applications (not the same domain)?

So, if you are not familiar with the cookie mechanism, please go to Google and get a general idea of why cookies are designed to be a problem that does not span domains.

System administrator only need to maintain a set of unified user account, convenient and simple. By contrast, system administrators previously needed to manage many sets of user accounts. Each application system has a set of user account, not only bring inconvenience to the management, but also easy to appear management vulnerabilities.

Simplify application development: from Application extension perspective

When developing a new application system, it can simplify the development process by using the user authentication Service of single sign-on platform directly. Single sign-on platform to achieve single sign-on by providing a unified authentication platform. Therefore, the application system does not need to develop user authentication procedures.
How to achieve it?

SSO is implemented in the following ways

Share cookies

When our subsystems are in a parent domain, we can seed the cookie under the parent domain, so that the browser and the cookie under the domain can be shared so that the user can be sessionid through the cookie encryption algorithm to achieve SSO.

However, we found that there are several drawbacks to this approach:
A. All the same domain Name System can obtain SessionID, easy to be modified and unsafe;
B. Not available across domains.

Ticket Verify that we're currently taking that way

The SSO for this implementation has the following steps:

A. The user accesses a subsystem and discovers that if they are not logged in, the user is directed to the SSO login page;
B. To determine whether SSO is logged in;
C. If you have already logged in, jump directly to the callback address and return the certified ticket;
D. If not logged in, the user correctly input username/password, authentication by jumping to the callback address, and return to the certification ticket;
E. Subsystem obtains ticket, invokes SSO to obtain the user UID and so on, successfully lets the user log in.

As already mentioned, how to implement SSO with cookies is primarily about solving cross-domain problems. First, let's talk about the domain attribute in Set-cookie.

Cookie Domain

In order for the HTTP protocol to maintain the context to some extent, the server can add Set-cookie to the client in response to the header to write some data to the Set-cookie

The domain field is used to indicate the field where the cookie resides.

Chestnuts:

We visit www.cookieexm.com if the server adds Set-cookie to the header, if domain is not specified, The default domain for this cookie is www.cookieexm.com, which means that the client will return the cookie to the server only when the www.cookieexm.com is accessed.
If we specify domain as. cookieexm.com, then the client accesses the following domain name: www.cookieexm.com www1.cookieexm.com a.cookieexm.com ***.cookieexm.com is able to return the cookie.

So, we come to the conclusion that the client matches the domain of the cookie from the end, and on that basis, we can implement our SSO login.

What you need to be aware of in cookies

Set to Http-only

A login voucher (such as a ticket or user name) should be encrypted

Cookies cannot store privacy data

Specific programmes

Suppose we need to implement a single sign-on between the following subsystems **.a1.a2 **.b1.b2 **.C1.C2, first we need an authentication system (SSO.S1.S2) dedicated to single sign-on. Assuming the system is currently not logged in, visit www.a1.a2 for example:

Look at each step individually:

Request WWW.A1.A2

WWW.A1.A2 received a request to check whether to carry a signed cookie, not currently logged in, then redirect to the SSO Certification Center
SSO provides a login window where the user enters a username password. SSO system authenticates user name and password

This step is the key, if the login is successful, first put the SSO system cookies to the client, while, the user's authentication information delivery through redirection to the business side, note that this delivery is obviously not through cookies to pass (different domains), generally through the encryption of the QueryString.

The authentication system of the business side receives the SSO authentication information, then authenticates
After the business party certification is passed, the cookie of the authentication result is written to the. A1.a2, so that the SSO certification is complete
Redirected to the business system WWW.A1.A2, it is clear from the previous conclusion that all business systems ending with. A1.A2 can use this authenticated cookie

Response

Description
Business Certification systems do not necessarily exist, and some systems that are not too sensitive can be redirected directly from the SSO authorization to the business system and bring the authentication information of SSO to the past.

To undertake the above, at this point, if the user accesses the WWW.B1.B2 application, as shown in the following illustration:

Unlike the access www.a1.a2, we do not need to enter the user name when redirecting to SSO authorization, because SSO.S1.S2 already has cookies, which are validated directly with cookies.

Above, is a simple cookie based landing system.

Several of these issues need to be addressed with emphasis

How to efficiently store large amounts of temporary trust data
How to prevent the information passing process from being tampered with
How to get the SSO system to trust the login system and the logout system
For the first problem, a similar and memcached distributed caching scheme can be used to provide both a mechanism for scalable data volumes and an efficient access

For the second question, the method of digital signature is generally adopted, either by signing a digital certificate or by using a MD5-like approach, this requires the SSO system to MD5 encrypt the parameters that need to be validated when returning to the URL-free, and bring the token back together, which will eventually require the system to authenticate the trust relationship without a login. This token must be passed to the SSO system, and the SSO system can tell if the information has been altered by validating the token

For the last question, it can be handled by a whitelist, saying that only systems on the whitelist can request a production trust, and that only the system on the whitelist can be logged on.