First, what is single sign-on. Single Sign On (SSO) is one of the most popular solutions for enterprise business integration. SSO is defined in multiple application systems. Users only need to log on once to access all mutually trusted application systems.
The CAS logon system has two roles. One is a Web application that provides the logon service, logon page, and client verification.
One is the CAS client, which uses a filter. When the client accesses the application, it first checks whether the system is logged on. If there is no logon, it is directly redirected to the CAS Server service.
In cas, MVC control is mainly implemented using spring MVC. However, in the login process, because it is a bit similar to the nature of the workflow, a lightweight workflow framework is adopted, that is, spring weflow. Next, we will analyze how CAS uses webflow to control the logon process.
For more information about how webflow works, see the official webflow2.21 reference.
--------------------------------- CAS client process ----------------------------------------
CAS client uses a filter. Every time the browser accesses the CAS celient application, it will first walk in the casfilter configured in Web. xml. They will determine whether the user has logged on.
If (the user has logged on ){
Dofilter;
}
If (the user is not logged on, and the request parameters do not contain the ticket parameter ){
Then, the browser will be redirected to the CAS server for login.
} If (the user has not logged on and the request carries the ticket parameter) {then the CAS client sends a server validate request to the CAS server in the background. Verify the validity of the ticket. If (Verification Successful) {create session, Cookie and think this customer is logged on .} If (Verification Failed) {bar browser is redirected to CAS server to allow the browser to log on .}} This is the process of logging on to the CAS client and logging out of the CAS. All CAS clients that have logged on will receive a loginoutrequest from the CAS server, and the client will destroy the session or something to log out. To log out.
------------------------------------- CAS server logon process ------------------------------------ the CAS server receives the login request redirected by CasClient. Will perform a series of account and password verification work. If (LOGIN successful) {write cookie, the server parameter carried by the browser, that is, the address of the CAS client application, is obtained and saved to map (to prepare for future logout ). Redirects the user to the CAS client and carries the ticket parameter .} Otherwise {No doubt .. Log On again .} PS: Only one logon operation is performed. ------------------------------------- CAS server verification process ------------------------------------ receives the verification request sent by the CAS client and returns the results in the past XML format. Success or failure. PS: Each CAS client performs this operation once.
------------------------------------- User logon process ------------------------------------ at this point, all the processes are roughly described. What is the actual logon process? I often say with a joke that such logon is the process of playing the ball, and users will be kicked by CAS server and CAS client. When a user (browser) accesses http: // client/clientappclientapp and finds that the user has not logged on, the user is redirected to casserver, so the URL on the user's browser becomes the user (browser) to access HTTP: // casserver: 8443/casserver? Server = http: // client/clientapp user (browser) enter the user password and click to submit the casserver verification result, the user is redirected to the client defined in the server and a ticket user (browser) is provided to access http: // client/clientapp? Ticket = xxxxxxxcasclient detects that a user is not logged on and has the ticket parameter. The server validate request is sent to casserver in the background. Casserver receives the CAS client authentication request. Return success or failure CasClient receives the user return value from casserver. If (successful) {do filter} Otherwise {redirect the user to the casserver login page}
When a user (browser) accesses http: // client/clientappbcasclient, it detects that the user is not logged on and redirects to casservercasserver with the cookie parameter that has been logged on, casserver will get ticket and redirect to CasClient users (browsers) to access http: // client/clientappb? Ticket = xxxxxxxcasclient detects that a user is not logged on and has the ticket parameter. The server validate request is sent to casserver in the background. Casserver receives the CAS client authentication request. If the return value is successful or fails, CasClient receives the user return value from casserver. If (successful) {do filter} Otherwise {redirects the user to the casserver login page}, but for the user login APPB process, it is only a process in which users (browsers) are redirected. That is to say, it is transparent to users. Therefore, the Single Sign-On process is implemented.
The user (browser) accesses http: // client/clientappcasclient and detects that the user has logged on. Allow.
Login User logout process ---------------------------------- the user (browser) accesses http: // client/clientapp/loginoutcasclient to detect the request and send a loginout request to casservercasserver to receive the request, iterates the map of the line in the red font of this article and retrieves the URL addresses of all clients iteratively. Casserver iteratively requests these URL addresses with a requestcode... If you forget the name, it is a parameter indicating the logout operation. CasClient receives this parameter, destroys the session, and completes the logout operation. casclientb receives this parameter, destroys the session, and the user (browser) who completes the logout operation is redirected to casserver to the login page, logout is complete.
