SSO SSO

1 To learn SSO, learn conversations first?

A session in a Web environment refers to the time interval between a browser and the interacting system, usually the time elapsed between registering and logging out of the system.

The session between the browser and the server is implemented through a local cookie.

1. When the browser accesses the Tomcat server for the first time, the Tomcat server creates a session object on the browser and stores it in the Map. Key is the SESSION ID. Value is the session itself. 2. When responding, the session ID is written to the browser of the client in the form of cookies. 3. The browser writes the session ID in the local directory to the local cookie. 4. In subsequent requests, the local cookie will be read first, and the corresponding cookie will be brought in the request.Copy the code

So how is the session on the server side and the cookie on the client side stored?

2 SSO SSO

Background of SSO SSO:

1. More and more systems are being used within companies. 2. Each system is a protected resource. Remember the corresponding account and password. Many employees set the same account and password for each system. 3. Assume that the user needs to log in to system A, SYSTEM B, and OA for three times. 4. If no, log out of each system.Copy the code

Single sign-on:

One login, access everywhere. At the heart of the single sign-on solution is the cookie, which carries the session ID to maintain the session state between the browser and the server. But cookies are limited. The limit is the domain of the cookie (usually the domain name of the website), and the browser automatically carries a cookie that matches the domain when sending an HTTP request, not all cookies.Copy the code

2.3 Login Mechanism

Let's assume that the first time the browser requests the server it needs to enter a user name and password to authenticate. The server takes the user name and password and compares it to the database. If it is correct, the user is valid and the session should be marked as "authorized" or "logged in", etc. HttpSession session = request.getSession(); HttpSession = request.getSession(); session.setAttribute("isLogin",true); When the user accesses it again, Tomcat checks the login status in the session object: HttpSession session = request.getSession (); session.getAttribute("isLogin"); Achieve login status in the browser request server model as shown below:! [](https://java-markdown.oss-cn-shenzhen.aliyuncs.com/java_img/20200519142352.png)Copy the code

Conclusion:

Each time a protected resource is requested, the login status in the session object is checked. Only the session with isLogin=true can access the protected resource. Therefore, the login mechanism is implemented.Copy the code

The picture above:

Why not unify the domain names of all subsystems of the Web application masses under a top-level domain, such as "*.baidu.com ", and set their cookie domain to" baidu.com"? This is theoretically possible. Even in the early days, many system logins used this method of sharing cookies with domain names. But what works is not good. There are many limitations to how cookies can be shared. First, the application group domain name must be unified; Secondly, the technology used by all systems in the application cluster (as long as the Web server) must be the same, otherwise the key value of the cookie (tomcat is jsessionID) is different, and the session cannot be maintained. Cookie sharing cannot be implemented across language technology platform login, such as Java, PHP,.NET systems; Third, cookies are inherently insecure. Therefore, we need a new login method to realize the multi-system application group login, which is single sign-on.Copy the code

3 How are cookies and sessions stored in the system?

Assume that there are two systems, A: www.a.com B: www.b.com

Both systems have their own area where sessions are stored. You can understand map to store session objects,

The map key stores the sessionid, that is, the sessionid. Value Stores the session object. There are three directories to store the cookies of corresponding domain names locally in the browser. Suppose you visit system A and look for the corresponding cookies in the directory of local a.com in the browser.

At request time, take the cookie request from this directory to the server (the browser does it, we don’t have to do it).

When the www.a.com server responds to the cookie, it writes it to the local a.com directory of the browser.

4. What about single sign-on, session and cookie?

Process:

  1. Suppose we visit www.a.com/index for the first time and first look for the corresponding cookie in the browser’s local a.com directory.

    If not, no session (partial session) has been established between the browser and server.

    In this case, you need to redirect to the unified Authentication Center. Check global sessions (if there are global sessions, other systems are logged in),

    You need to pass the requested address as a parameter (why pass it? Call back to this address.

  2. The browser calls the checkLogin method in the unified Authentication Authority to see if there is a global session,

    In this case, the requested address is www.sso.com/checklogin. The browser will find the correct cookie information in the local sso.com directory and bring it to the server at the time of the request. But in this case,

    The sso.com directory in the browser also does not contain cookie information.

    This means that the browser has not established a session with the unified authentication Authority. No session indicates that no login is performed and the login page of the unified Authentication Center needs to be forwarded.

    You also need to take the redirectURL from the address bar and place it in the request field.

    www.sso.comchecklongin?redirectURL=http://www.a.com/…

  3. The password is forwarded to the login page of the unified Authentication center, where the user enters the account and password. The certification center service does a few things:

    • After the token is created, it is indirectly authorized to subsequent subsystems.
    • After the global session is created, the token is stored in the global session.
    • The token information is stored in the token table in our DB (this table will be queried later to check the validity of the token)
    • Redirect back to the address of the previous request, redirectURL, and issue the token to the subsystem: www.a.com? Token =xxxx1;

  4. The unified Authentication Center responds the session ID (jessionID) to the cookie file in the sso.com directory on the client browser.

    Store as key/value (note: Key is a fixed jessiond and value is a string of server session ids).

    This jessionID will be used whenever you need to access www.sso.com later