Single sign-on (SSO)
This is the fourth day of my participation in Gwen Challenge
This article is participating in “Java Theme Month – Java Development in Action”, see the activity link for details
Logging In to a Single System
Because HTTP is stateless, on a stand-alone system, we store user state through sessions and cookies.
Use cookies to save session state
After the user logs in to the system, the server can call addCookie(Cookie Cookie) in response to save the user identity. The browser will carry this Cookie in the Request Headers after receiving it. The server receives the request and parses the cookie to get the user id, so it can determine which user the current session belongs to.
Use session to save the session state
After a user logs in to the system, the server can use the setAttribute(String key, Object value) method to set the session and save the user information on the server. After the browser receives the response, In the response headers can be seen in a similar Set – cookies: JSESSIONID = A1D9FBF86E779B5DE28BB20EAD19F9B5; Path=/; The HttpOnly record is automatically generated by the server when we set the session. The next time we request the server, we will see the request Headers Cookie. JSESSIONID = 8260 f1e79ddbf2ea75d8c73e04bfee0f, because every time with the session id, server (here refers to the Tomcat or other containers) automatically to help us to distinguish the different session, So you can use getAttribute(String name) to get the session value, and ensure that John does not get The value of John.
Multi-system Login
When we have multiple systems, such as Taobao https://www.tmall.com/ and Tmall https://www.tmall.com/ are two systems, we hope to log in taobao, and then open Tmall is directly logged in state, one login, available everywhere this is single sign-on.
Single sign-on (SSO for short), also known as Single check-in, is an attribute that provides access control to many interconnected but independent software systems. With this property, users can gain access to all systems when they log in, rather than logging in to every single system
Since cookies cannot cross domains, Taobao and Tmall cannot share cookies. Session depends on Tomcat of the current system. Different containers will generate different sessions, and sessions cannot be shared. The two systems cannot share sessions.
However, if I introduce a third system, this system is only responsible for login. After taobao logs in to this system, a user information is saved. When Tmall logs in, it finds that this system already has user information. That’s the general idea of single sign-on.
The login process
This diagram should give you a clear view of the login process
- The user accesses system A and checks the cookie of system A. If the cookie does not exist, the user is not logged in. The sso system logs in to the SSO system with the URL of system A
http://hellosso.com:8089/login?returnUrl=http://client1.com:8088 - If the SSO system is not in the login state, enter the user name and password to log in to the SSO system
- After a successful login, create a user session to save user information. Create an SSO ticket that can be stored in the COOKIE of the SSO system to indicate that the SSO system is in the login state. Create a temporary note and send it to System A. System A then brings the temporary note to the SSO system to verify whether the temporary note is valid
- After the sso system verifies the temporary ticket successfully, it can send the user information to system A. System A records the user information in Cooke, indicating that system A is in the login state, and system A has completed the login
- When system B logs in, system B needs to bring the URL of system B to sso system. Since SSO system is already logged in, SSO system sends a temporary ticket to System B, and then system B brings the temporary ticket to SSO verification. After the success, SSO system sends the user information to System B, and System B records it in the cookie. Indicates that system B is logged in, and system B has logged in.
Log out
- To log out, system A redirects to the SSO system, deletes the cookies of the SSO system, deletes the user session, and deletes the local cookies of system A. Then system A logs out.
- When system B accesses the sso system again, the sso system does not have cookies or user sessions. Therefore, system B can log out
Example demonstrates
The source code has been uploaded to GitHub, github.com/Saul-Zhang/…
I used Redis to store user session and other information.
Information stored in Redis:
| key | value | |
|---|---|---|
| The user’s session | The user id | User Details |
| Sso paper | sso_ticket | The user id |
| Temporary paper | tmp_ticket | The md5 tmp_ticket |
Sample screenshots
reference
Apereo. Making. IO/cas / 4.2 x/I…