Simple SSO framework written according to CAS protocol, cassso framework
Preface:Considering that distributed applications are an indispensable part of Single Sign-on, it is decided to spend some time learning. I wanted to go directly to the CAS framework. After a preliminary understanding, I thought it was too huge and difficult to customize, it is not that easy to use in full depth (although it may be easy to use ). As a result, I decided to implement one myself based on the CAS protocol (although I didn't like CAS very much, the CAS protocol is still a full SSO standard). After the beginning, I was interrupted and started to work, after working overtime, I took the time to solve my lifelong tasks. Now I have achieved the initial success. But now it is only implementation, there are still many parts to be optimized, because my work is still busy, so it will not be improved. I will put the code on github. If you are interested, you can submit your updates based on it. Of course, you can also leave a message to tell me where you need improvement. Here, we will go to the topic.Technology Stack:
- SpringMVC
- Filter
- Listener
- Cookie/Session
- Redis/Spring Data Redis
- HttpClient
Architecture & process:A: intercept request B: Jump to SSO-Server for login c: Return tokend: Verify tokene: Verification Successful, write cookief: Return to resource page
Project components:
- Bounter-sso (Project root directory)
- Sso-server (sso server, mainly responsible for logon, token verification, refresh token time, and logout)
- Sso-client (sso client, mainly responsible for intercepting requests and communicating with the sso server)
- Bounter-app1 (Virtual Application 1)
- Bounter-app2 (Virtual Application 2)
Project running:127.0.0.1 www. sso. com127.0.0.1 www. app1.com127.0.0.1 www.app2.com
- Start sso-client, bounter-app1, bounter-app2 in jetty
Main functions:
The implementation principle is almost completely in accordance with the CAS protocol, the following is the link of the CAS Protocol: https://apereo.github.io/cas/4.2.x/images/cas_flow_diagram.png
- Centralized storage and verification of Token
Originally, the token was stored in the session of the sso server. It was found that when the token is verified through HttpClient, the requests generated by HttpClient are different from those generated by the browser. Therefore, the token in the session of the original browser cannot be obtained during token verification. In the end, you can only use redis to save the tokens in a centralized manner. In this way, you can obtain the tokens saved to redis in your browser during HttpClient verification. This also solves the problem that the server session memory consumption is too large when too many requests exist.
Refer to the previous CAS source code implementation. The main principles are as follows:The url contains the sessionid of different apps. when an application sends a logout request, it first cancels the application's own session, then accesses the sso server, clears the token corresponding to the session on the server, and then cancels the server session, finally, listener 4 that triggers Server session cancellation. in the listener that handles cancellation, httpclient notifies all applications corresponding to the token to log out based on the sessionid parameter, and removes the session id saved in the app session container.
- Token expiration time refresh
Reset the redis expiration time on the sso server every time you create a new session, as shown below:
// Refresh the expiration time when the key is sso-token
StringRedisTemplate. expire (ssoToken, EXPIRE_TIME, TimeUnit. MINUTES );
Improvements:
- You can change cookie/session to JWT (Json Web Token) to achieve full stateless and mobile terminal support.
- Encryption and security of token and jsessionid
- Permission Control
Source Code address: (go back to upload the latest code at night. The above version is old for the time being. You are welcome to provide valuable suggestions for improvement)Https://github.com/13babybear/bounter-sso
