Personal public account “code nong notes”, welcome to pay attention to view more wonderful articles.

concept

Single Sign On, or SSO for short, is one of the more popular solutions for enterprise business integration. SSO is defined as one login in multiple applications that allows users to access all trusted applications.

background

In the early stage of enterprise development, there is not much system design. Perhaps only one system can meet business requirements, and users only need to log in with an account and password to complete authentication. However, with the iterative development of the business, the system architecture will be iterated along with the evolution of more and more subsystems. Users may need to log in once every time they enter a system to perform relevant operations. In order to solve this problem, single sign-on (SSO) comes into being. In an environment where multiple systems coexist, a user logs in at one place and is trusted by all other systems without logging in to other systems.

Single System Login

The following figure shows a series of processes that occur when accessing an application that requires login

The Cookie is set after login. The server will carry the Cookie with each subsequent access. Based on the Cookie, the server will find the corresponding session to determine whether the user is logged in. If no special configuration is made, the Cookie is named sessionID and the value is unique on the server. You can also set a token as the unique identifier of the user so that the background service can identify the current login user. If you log in to the system in the same domain after the Cookie expires, you can use this method to log in again.

Design and Implementation

The essence of single sign-on is to share login state across multiple applications.

If the user’s login status is recorded in the Session, to realize the shared login status, the Session must be shared first. For example, the Session can be serialized into Redis, so that multiple application systems can share the same Redis and directly read the Redis to obtain the Session. Of course, this is not enough, because different application systems have different domain names. Although sessions are shared, Session IDS are often stored in browser cookies, so there are scope limitations and cannot be transferred across domain names. That is to say, after users log in app1.com, The Session ID is carried automatically in the request header only when the browser accesses App1.com, and is not carried when the browser accesses App2.com. The key to single sign-on is how to share Session ids (or tokens) across multiple domains.

Cookie-based implementation

With the domain name

Generally, an enterprise has only one domain name. Secondary domain names are used to distinguish different systems. For example, we have a domain name named “a.com” and two business systems named “App1.a.com” and “App2.a.com”. We want to do single sign-on (SSO), need a login system, called: sso.a.com.

We just logged in at sso.a.com, app1.a.com and App2.a.com. Through the login authentication mechanism above, we can know that the login in sso.a.com is actually recorded in the session of the server side of sso.a.com, while the Cookie is written in the Browser side of sso.a.com. So how do we get App1.a.com and App2.a.com to log in?

Cookie cannot be cross-domain. The domain attribute of our Cookie is sso.a.com, which cannot be taken when sending requests to App1.a.com and App2.a.com. After sso login, you can set the Cookie domain to the top domain, that is. A.com, so that all sub-domain systems can access the cookies in the top domain.

When we set cookies, we can only set the top field and our own field, not other fields. For example, we cannot set cookies for the domain of Baidu.com in our own system.

Summary: This implementation is relatively simple, but does not support cross-master domain names.

Different domain name

The examples listed above are for the same domain name, but when the top-level domain name is not the same, such as Tmall and Taobao, how to achieve cookie sharing?

Nginx reverse proxy

Reverse Proxy (In Reverse Proxy mode, a Proxy server receives Internet connection requests and forwards the requests to servers on the Intranet. It returns the result from the server to the client requesting the connection on the Internet, and the proxy server acts as a server externally.

A reverse proxy server is like the original server to the client, and the client does not require any special setup. The client sends a normal request to the content in the namespaces of the reverse proxy, and the reverse proxy determines where to forward the request (the original server) and returns the obtained content to the client as if it were its own.

Nginx configuration is as follows:

upstream web1{
		server  127.0.0.1:8089  max_fails=0 weight=1;
}
upstream web2 {
 		server 127.0.0.1:8080    max_fails=0 weight=1;
}

location /web1 {
		proxy_pass http://web1;
  	proxy_set_header Host  127.0.0.1;
  	proxy_set_header   X-Real-IP        $remote_addr;
  	proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

  	proxy_set_header Cookie $http_cookie;
  	log_subrequest on;
}

location /web2 {
  	proxy_pass http://web2;
  	proxy_set_header Host  127.0.0.1;
  	proxy_set_header   X-Real-IP        $remote_addr;
  	proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
  	proxy_set_header Cookie $http_cookie;
  	log_subrequest on;
}
Copy the code

The other way

In addition to nginx reverse proxy, jSONP and other methods can realize cookie sharing, to achieve the purpose of single sign-on.

Certification center

Cookie based single sign-on (SSO) has security risks and cross-domain problems. In this case, you can deploy an authentication authority, which is an independent Web service that handles login requests.

Only the authentication center can accept security information such as user names and passwords. Other systems do not provide login portals and only accept indirect authorization from the authentication center. Indirect authorized by token, sso authentication center to verify the user’s user name password no problem, create the authorization token, in the process of the next jump, authorization token as parameters sent to each subsystem, subsystem get tokens, quick to authorize, to create a local session, local session login method with single system login the same way.

Below is a brief description of the figure above

  1. When a user accesses the protected resource of system 1, system 1 finds that the user does not log in, switches to the SSO authentication center, and takes its own address as a parameter
  2. The SSO authentication center detects that the user has not logged in and directs the user to the login page
  3. The user enters the user name and password to submit a login application
  4. The SSO authentication center verifies user information, creates a global session between the user and the SSO authentication center, and creates an authorization token
  5. Sso authentication authority redirects the original request address with the token (System 1)
  6. System 1 obtains the token and goes to the SSO authentication center to verify whether the token is valid
  7. The SSO authentication authority verifies the token, returns valid, and registers system 1
  8. System 1 uses this token to create a session with the user. The key is the user field and the value is token. This session is called a local session and returns protected resources
  9. Users access protected resources in system 2
  10. System 2 redirects the SSO authentication center when the user does not log in and uses its own address as a parameter
  11. When the SSO authentication center detects that the user has logged in, the sso authentication center switches back to the address of system 2 with the token attached
  12. System 2 obtains the token and goes to the SSO authentication center to verify whether the token is valid
  13. Sso authentication center validates token, return valid, register system 2
  14. System 2 uses this token to create a local session with the user and return the protected resource

After successful login, the user establishes sessions with the SSO authentication center and each subsystem. The sessions established between the user and the SSO authentication center are called global sessions, and those established between the user and each subsystem are called local sessions. After the local sessions are established, the user does not access the subsystem protected resources through the SSO authentication center. Global sessions and local sessions have the following constraints

  1. If a local session exists, a global session must exist
  2. Global sessions exist, but local sessions do not necessarily exist
  3. Global session destruction, local session must be destroyed

summary

Single sign-on is designed so that users are no longer bothered by multiple logins and do not need to remember multiple ids and passwords. In addition, there will be fewer cases of users forgetting passwords and resorting to support staff, as well as reducing the burden of managing user accounts.

Thanks for reading, add a concern, welcome to like and forward!!