Web applications use the browserserver architecture and http as the communication protocol. Http is a stateless protocol. the server processes each request of the browser independently and is not associated with previous or subsequent requests, no connection between three Request response pairs I. single-system logon mechanism 1. http stateless protocol
Web applications use the browser/server architecture and http as the communication protocol. Http is a stateless protocol. the server processes each request of the browser independently and is not associated with previous or subsequent requests, there is no connection between three request/response pairs
HttpSession session = request.getSession();session.setAttribute("isLogin", true);
When you access the service again, tomcat checks the logon status in the session object.
HttpSession session = request.getSession();session.getAttribute("isLogin");
The browser request server model that implements the logon status is described in
Public void doFilter (ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {HttpServletRequest req = (HttpServletRequest) request; res = (response) response; HttpSession session = req. getSession (); if (session. getAttribute ("isLogin") {chain. doFilter (request, response); return;} // jump to the sso authentication center res. sendRedirect ("sso-server-url-with-system-url ");}
2. sso-server intercepts unregistered requests
Blocks unlogged requests from sso-client to the sso authentication center and redirects to the logon page. this process is exactly the same as that of sso-client.
3. sso-server verifies user logon information
The user enters the user name and password on the logon page, and requests logon. The sso authentication center verifies the user information. the verification is successful and the session status is marked as "logged on"
@RequestMapping("/login")public String login(String username, String password, HttpServletRequest req) { this.checkLoginInfo(username, password); req.getSession().setAttribute("isLogin", true); return "success";}
4. create an authorization token for sso-server
The authorization token is a string of random characters. it does not matter how the token is generated in Chengdu, as long as it is not repeated or difficult to forge. The following is an example.
String token = UUID.randomUUID().toString();
5. sso-client obtains the token and verifies the token.
After logging on to the sso authentication center, jump back to the sub-system and attach the token. the sub-system (sso-client) obtains the token and then goes to the sso authentication center for verification, in the LoginFilter. add several lines in java doFilter ()
// The request comes with the token parameter String token = req. getParameter ("token"); if (token! = Null) {// go to the sso authentication center to verify the token boolean verifyResult = this. verify ("sso-server-verify-url", token); if (! VerifyResult) {res. sendRedirect ("sso-server-url"); return;} chain. doFilter (request, response );}
The verify () method is implemented using httpClient, which is briefly described here. For more information about how to use httpClient, see the official documentation.
HttpPost httpPost = new HttpPost("sso-server-verify-url-with-token");HttpResponse httpResponse = httpClient.execute(httpPost);
6. sso-server receives and processes verification token requests
After a user successfully logs on to the sso authentication center, the sso-server creates an authorization token and stores it. Therefore, the sso-server checks the token to check whether the token exists and whether it expires, after the token is verified successfully, the sso-server registers the system that sends the verification request to the sso authentication center (meaning it is stored)
The token and registration system address are usually stored in the key-value database (such as redis). redis can set the validity period for the key, that is, the token validity period. Redis runs in the memory, and the speed is very fast. The sso-server does not need to persist any data.
The token and registration system address can be stored in redis using the description structure. you may ask, why are the addresses of these systems stored? If it is not stored, it will be troublesome to log out. the user submits a cancellation request to the sso authentication center and the sso authentication center deregister the global session, however, I do not know which systems use this global session to establish their own local sessions, nor do I know which subsystems I want to send a logout request to log out of the local session.
if (verifyResult) { session.setAttribute("isLogin", true);}
Sso-client also needs to bind the current session id with the token, indicating that the login status of the session is related to the token. this relationship can be saved using the hashmap of java, the stored data is used to process the logout request sent from the sso authentication center.
8. cancellation process
The user sends a request (logout request) with the "logout" parameter to the subsystem. The sso-client interceptor intercepts the request and initiates a logout request to the sso authentication center.
String logout = req.getParameter("logout");if (logout != null) { this.ssoServer.logout(token);}
The sso authentication center also identifies the sso-client request as a logout request (with the "logout" parameter). The sso authentication center deregister a global session
@ RequestMapping ("/logout") public String logout (HttpServletRequest req) {HttpSession session = req. getSession (); if (session! = Null) {session. invalidate (); // trigger LogoutListener} return "redirect :/";}
The sso authentication center has a listener for global sessions. once a global session is canceled, all registration systems are notified to log out.
Public class LogoutListener implements HttpSessionListener {@ Override public void sessionCreated (HttpSessionEvent event) {}@ Override public void events (HttpSessionEvent event) {// send a logout request to all registration systems through httpClient }}
The above is a detailed description of the single sign-on principle and simple implementation. For more information, see other related articles in the first PHP community!