The implementation principle of SSO single sign-on

Single Sign-on in the current system architecture is widely available, he will be a number of subsystems to open the authentication system, to achieve a multi-point of access to use, and in the framework of single sign-on, you will encounter some small problems, in different application environments can be different single sign-on implementation to meet the needs. I will be in the application environment I have encountered and in which I have experienced the various stages of sharing with you, if there are shortcomings, I hope you are not hesitate to enlighten us.

One, sharing session

Sharing session is the most direct and simplest way to achieve single sign-on. The user authentication information is saved in the session, that is, the value stored in the session is user credentials, which is very normal and easy to implement in a single site, and in the user authentication, user information management and business application separation scenario will encounter single sign-on problem, in the application system is simple, In the rare case of subsystems, the session sharing method can be considered to deal with this problem.

This architecture I used a Redis-based session sharing scheme. Store the session on Redis and then set the entire system's global cookie domain to the top-level domain so that the SessionID can be shared across subsystems.

This solution has a serious extensibility problem, first of all, ASP. NET session storage must be a Sessionstateitemcollection object, and the stored structure is serialized and then stored encrypted. And when the user accesses the application, the first thing he does is to take all the contents of the storage container out and deserialize it into the Sessionstateitemcollection object. This determines that he has the following constraints:

1. The type involved in the session must be common in the subsystem (that is, the assembly and type need to be consistent), which leads to many restrictions on the use of the session;

2, the situation of cross-top domain is completely unable to deal with;

Second, OpenID-based single sign-on

This single sign-on to the user's identity information simplified to OpenID stored in the client, when the user login to a subsystem, the OpenID to the server, the service side based on the OpenID structure user authentication information, more for the C/s and B + system, the process is as follows

As you can see, this single sign-on relies on the delivery of OpenID, which is based on the storage and delivery of OpenID.

1, when the user first login, the user name password sent to the authentication service;

2. The authentication service returns the user identity OpenID to the client;

3, the client for storage;

4. When accessing the subsystem, the OpenID is sent to the subsystem;

5. The subsystem forwards OpenID to the authentication service;

6, the Authentication service returns the user authentication information to the subsystem;

7. After the subsystem constructs the user authentication information, the authorized content is returned to the client.

The main problem of this single sign-on authentication mechanism is that he stores the user's OpenID in the client based on the C/S architecture, sends OpenID between subsystems, and the B/S mode is difficult to do. In order to deal with this problem we will lead to the next way, this way will solve the B/s mode of OpenID storage, transfer problems.

Third, cookie-based OpenID storage solutions

We know that the role of cookies is to act as an information carrier on the server side and on the browser side for information transmission, while cookies are generally separated by domain names, for example A.xxx.com and b.xxx.com cookies are not accessible to each other, but subdomains are cookies that can access a parent domain name. That is, a.xxx.com and b.xxx.com can access cookies under xxx.com, so they can use cookies from the top-level domain as an OpenID carrier.

The validation step is very similar to the previous second method:

1, in the provision of authentication Service site login;

2. Write OpenID into the top-level domain cookie;

3. Access subsystem (cookies with OpenID)

4. Subsystem takes out OpenID and sends OpenID to authentication Service

5. Return user authentication information

6. Return the content after authorization

In both of these methods, we can see that through OpenID decoupling the session sharing the type of the problem, and the construction of user authentication information will be more flexible, subsystem verification is independent of each other, but in the third scenario, we are based on the assumption that all subsystems are the same top-level domain name, It is normal to have multiple domain names in the actual production environment, then we have to consider how to solve the cross-domain problem.

Four, b/s multi-domain environment of single-point login processing

In the case of multiple top-level domains, we will not be able to share the OpenID of each subsystem. To deal with cross-domain problems in B/s environment, we should first think of Jsonp's plan.

The verification steps are as follows:

1, the user through the login subsystem for user login;

2, the user login subsystem records the user's login status, OpenID and other information;

3, the user uses the business subsystem;

4, if the user is not logged into the business subsystem, users will be redirected to the user login subsystem;

5. The user's subsystem passes the user OpenID to the business subsystem through the JSONP interface;

6, the business subsystem through the OpenID invoke authentication service;

7, the authentication service returns the authentication information, the business subsystem constructs the user login credentials; (at this point the user client has already corresponded with the child business system's authentication information)

8, the user login results returned to the user login subsystem, if the successful login will users jump back to the business subsystem;

9, the content returned to the client after authorization;

V. Security issues

After the above steps, the cross-domain single sign-on problem can be solved. At the beginning of the entire development process, we used the user table to record an OpenID field to save the user OpenID, and there are obviously some security and extensibility issues in this mechanism. This extensibility problem is mainly reflected in one aspect: the security of OpenID and the contradiction of user experience.

The entire single sign-on mechanism determines that OpenID will appear on the client side, so OpenID needs to have an expiration mechanism, if the user is logged in a terminal can choose to refresh the OpenID each time the user logs on or on each exit, In the case of multi-terminal login, there will be a contradiction: when a terminal refreshed OpenID, the other terminal will not be properly authorized. In the end, I used a single-user multi-OpenID solution. Each time a user logs in via a username/password, an OpenID is saved in the Redis, and the expiration time is set so that multiple terminal logins will have multiple OpenID corresponding to it, and there will no longer be an OpenID failure for all terminal verification to fail.

The implementation principle of SSO single sign-on