1，
cas server value configuration database verification, encryption method, return data and other data information
The cas client is configured with requests such as authentication requests, verification requests, packaging requests, local sessions, and exit requests
cookie(TGT的id,TIcket的id) ----session
General client-side, server-side verification design:
tooken-session
Client: The first time it is passed to the server (token) generated by the server itself, the second time, the session value, (token) value (reversely written by the incoming server, except for the token) is passed in.
Server: The first time is to form a (token)-session (send session to a client) in the way of KV, store it in the cache, and the second time use the incoming token of the client as the key to obtain the session
Compared with the incoming session, if it is consistent, it will pass the verification. If it is inconsistent or empty, it will require login.
Client authentication for cas:
cookie--session
cas server: After successful login, write session to client server, keep TGT (ticket) in cache, browser write cookie (TgT id)
Client service: Get the cookie information of the browser. If the session of the client server is empty, the cas server can obtain the ticket (TGT) according to the cookie and release it, and generate a session at the same time.
The cookie requires login if the object cannot be obtained in cas
The client server session is not empty and directly released
That is to say, the matching implementation of KV is completed in the cas server, unlike the traditional completion in the web service, other such as the session is not empty, the release is still the same
The client needs to go through these filters to achieve login
To organize the entire login process (one login contains three requests):
The first request to the application server:
When the user accesses the URL of the application server for the first time, since there is no "_const_cas_assertion_" in the session and there is no ticket in the parameter (or the cookie has no value, the cookie has a value to generate a session), the AuthenticationFilter will jump to the login page of the CAS server.
Second request to the application server:
After the login page of the CAS server is successfully logged in, it will jump to the page before the login of the application server, but add a parameter ticket. This request has passed the AuthenticationFilter because of the ticket parameter, but the TicketValidationFilter will verify the ticket. After the verification is successful, it will add "_const_cas_assertion_" to the session, and then remove the ticket parameter to make a jump.
The third request to the application server:
At this time, because there is already "_const_cas_assertion_" in the session, it will pass the AuthenticationFilter, and because there is no ticket parameter, it also passes the TicketValidationFilter, that is, the page can be displayed normally. Requesting the application server in the future will be the same as this time. Since the session contains "_const_cas_assertion_", it can be accessed normally.
http://zhenkm0507.iteye.com/blog/546805