1. What is sso
single sign-on (sso), referred to as sso, is one of the most popular solutions for enterprise business integration. SSO means that in multiple application systems, users only need to log in once to access all mutually trusted application systems.
For example, there are multiple subsystems, a.com, b.com, c.com...
requirement: After a user logs in successfully in any subsystem, they can access protected resources in other subsystems.
2. Authentication process
1) The user accesses the protected resources of Subsystem A through the browser, namely a.com/pageA.
2) There is no user session data in Subsystem A, Subsystem A thinks that the user has not logged in, so Subsystem A redirects the request to the authentication center sso.com, the redirection address is: sso.com?param=a.com /pageA.
3) After the request arrives at the authentication center, it is found that there is no session of the user in the authentication center, so the login page is responded to the browser with the address: login.html?param=a.com/pageA
4) The user enters the user name and password, and submits Send the form to the certification center; carry a.com/pageA at the same time.
5) After the certification center receives the user name and password, the verification is successful. At this time, the certification center creates a global session and generates a token ticket.
And redirect to a.com/pageA?ticket=xxx
6) When the response reaches the browser, you will receive the cookie: domain= sso.com set cookie: jsessionid=xxxx; and save it.
7) Send the a.com/pageA?ticket=xx request again from the browser. After the request arrives at Subsystem A, take out the ticket and verify that the ticket is valid to the certification center. If it is valid, it means that the user has logged in to the certification center. . The subsystem will establish a partial session with the user and save the user information in the partial session. After the request is responded to the browser, the browser receives the cookie, domain=a.com; set cooki: jsessionid=xxx;
8) When the user visits other protected pages of system A again, it will bring domain=a.com The cookie, which is jsessionid, the subsystem thinks that the user has already logged in and has the right to access the corresponding protected resource.
9) When a user accesses system B, namely b.com/pageA, because there is no local session established in system B, system B will redirect the request to the authentication center. But the browser already has the cookie of the authentication center, that is, the jsessionid of domain=sso.com, which will carry the jsessionid to access the authentication center.
10) After arriving at the certification center, because there is Jseesionid, the certification center thinks that the user has logged in, reissues the ticket, and redirects to b.com/pageA?ticket=xxx
11) After the response is poured into the browser, send to b.com/ System B with pageA?ticke=xxx sends a request. System B takes out the ticket and authenticates to the certification center. If the authentication is valid, subsystem B establishes a local session with the user. User information is stored in the local session. After the request is responded to the browser, the browser receives the cookie, domain=b.com;set cooki: jsessionid=xxx;
12) At this point, the user can access system A, system B, and system X after logging in once.
