Single sign-on (SSO) is no stranger to us, once login, everywhere login. An enterprise has its own application systems. All application systems use the same level-1 domain name. Application systems are distinguished by different level-2 domain names. For example: Baidu, Baidu has many sub-systems – Baidu text library, Baidu know and so on. In our experience, the Baidu account was logged in, and other sub-applications were logged in as well. This time, let’s take a look at the implementation principle behind it — single sign-on in the same domain.
Single domain SSO principle design
-
The portal system sets the domain of the Cookie to the level 1 domain name authing.com, so that the portal Cookie can be shared with all systems that use this domain name (Authing.com).
-
Use techniques such as Spring Session to share sessions with all systems.
-
After the login of the portal system, either the jump application 1 or 2 can read the login information in the Session through the SessionId in the Cookie of the portal to achieve single sign-on.
Principle analysis of SSO in the same domain
The HTTP protocol is stateless, and the Session of a single system is maintained by the server Session. The Session maintains the Session by sending the set-cookie request header to the browser, and the browser writes the Cookie containing the Sessionid into the browser after receiving it. Each access will automatically carry the cookies under the site, and the server reads the Sessionid for authentication to achieve session persistence. By skillfully using the Cookie top domain feature and Session sharing, multiple system login authentication in the same domain can be realized, that is, single sign-on in the same domain.
The Session Cookie mechanism
The server authenticates the client through cookies.
After the user logs in for the first time, the server will return a Cookie to the client (the Cookie contains the Sessionid). After the user initiates a request, the Cookie will be added to the header, and the server can identify the specific client.
Spring – sharing Session
Resolve the problem of Session sharing in clusters in the same domain. When the server is a cluster rather than a single point, Session sharing between cluster servers is required to implement SSO in the same domain using the session-cookie mechanism.
Implementation: Block the request through the filter, obtain Session data and save it to the database (Session persistence), then the Session data will be uniformly obtained from the database.
SSO authentication in the same domain
How do different sites under the same domain name authenticate
According to the browser’s Cookie same-origin rule, two sites can share cookies, as long as they are under the same domain name (or secondary domain name).
For cookies in the same domain, the browser saves cookies and the domain to which they belong locally. The browser sends these cookies to the site system when it visits any subsites within the domain.
Assume: we have two sites www.authing.com/site1, www.authing.com/site2. The two sites share the same host address and are under the same domain name.
-
Log in to www.authing.com/site1 and your browser will have an authenticated Cookie from www.auhting.com/site1. These cookies are sent to Site1 when you click on any child page under site1.
-
These cookies are also sent along with the request to www.authing.com/site2 for any child pages below site2.
When the browser saves cookies in the domain www.authing.com, site1 and site2 belong to the same domain. So cookies in this domain are available to both sites. As long as their Session information is stored in the same place.
How do I authenticate different subdomains under the same domain name
Assume: our site is deployed according to the following domain name sub1.auhting.com, sub2.Authing.com, both sites share the same domain authing.com.
By default, the browser sends cookies to the host of the domain to which they belong. In other words, the default domain of the Cookie of sub1.auhting.com and sub2.authing.com is different, so we need to set the Cookie domain on the server to handle it.
-
Log in to sub1.authing.com.
-
After a successful login, set the Cookie information. We store the SessionId in the Cookie and must set the domain of the Cookie to the top-level domain.authing.com.
-
Access the sub2.Authing.com system, the browser will send the Cookie information SessionId along with the request to the sub2.Authing.com system. In this case, the system checks that the Session is logged in and permits the login.
Of course, the same goes for logging into sub2.Authing.com. After the above steps can realize the single sign-on of different secondary domain names.
Single sign-on for Baidu series applications
Below we through a specific example to experience the same domain under different applications of single sign-on and single sign-off, this time we chose Baidu know and Baidu network disk.
When we log in baidu web disk, Baidu will write the Cookie of the shared login state under the.baidu.com domain name. Then we refresh Baidu to know that the website becomes logged in state, and we can check the Cookie under the.baidu.com domain name in the first request. Baidu has also printed out the user name for the page we returned.
Next, we delete these two cookies: BDUSS and BDUSS_BFESS, then switch to Baidu web disk and refresh the page, and the system shows that it has quit. The server returns an HTTP response and deletes the two cookies under.baidu.com through set-cookie Header. After the browser deletes the cookies, other websites in the same domain will sso exit.
Single sign-on has become an integral part of enterprise identity and access management solutions. Single sign-on (SSO) in the same domain is a common solution of sso mechanism. Next time, we’ll talk about single sign-on across domains and more comprehensive identity and access management solutions. Stay tuned for Authing.