CAS stands for Central Authentiction Service, a separate open instruction protocol. CAS is an open source project initiated by Yale University. Aimed at providing a reliable single sign-on method for Web applications,CAS was officially named a project of JA-SIG in December 2004.
CAS Client supports a large number of clients (here refers to each Web application in the single sign-on system), including Java.NET PHP and so on
The principle of the first login verification is as follows:
1. The first jump: the client accesses the application system, the application system determines that the Session is routing, returns 302, jumps to the SSO login page, and passes the service parameter to SSO. This service parameter has two functions:
2. Service generally delivers the URL address of the application system, which is used to jump back to the application system after the SSO authentication is passed;
3. Service parameter will also be recorded by CAS server as the unique mark of CAS client for later matching of corresponding authentication credentials;
4. The second jump: The browser displays the login page. After the user enters the account and password and logs in successfully, SSO will return 302 and jump back to the original application system page, and carry the ticket parameter as the authentication ticket. At the same time, TGT will be recorded to the browser through ST-Cookie (TGT will be reflected when the next application system needs to log in. Is the key to avoiding duplicate logins.)
5. A background verification: after the application system receives a request with a ticket, it makes an HTTP request directly to the SSO server from the background, using Service and Ticket as parameters to verify the validity of the ticket; If a ticket is valid, the SSO server returns the login user name corresponding to that ticket.
When the login verification is completed and the system is switched to another system, the principle is shown as follows:
1. When the user has logged in to an application system and accessed the second application system in the same browser, according to the requirements of single sign-on, the user should not log in again at this time, but directly entered the second system. But in fact, it still needs to go through two front-end jumps and one back-end verification, but at this time, the two jumps are continuous, there will be no login page in the middle, and the user will not feel it. The basis of judgment is that the TGT (Ticket Granted Cookie) is saved to the client through the set-cookie in the previous step 4.
2. Compared with the first visit, the previous step 3 is less (there is no need to appear the login page), because the previously saved TGT is carried in the jump of the second step at this time. CAS server can get the user information through TGT, so it directly generates a ticket and returns it to the application system. So there are two consecutive 302 jumps, and the user sees the effect of going straight to the second application.
CAS source code parsing – CAS related JAR packages
CAS source code – CAS configuration file
1. Spring-Configuration is the core configuration related to Spring, including the method to read configuration file, Spring bean registration configuration, ticket ticket configuration, Cookie configuration, etc.
2, View page directory: including JSP, JS, CSS and so on.
3, Cas.properties file: CAS service configuration file, can store database configuration, Redis configuration, etc.
4, deployerConfigContext. XML: used to connect to the database configuration.
1. When the system receives the request, it first passes through Web.xml, and finds Cas-Servlet.xml by mapping SafeDispatcherServlet in Web.xml.2. HandlerMappingC and FlowHandlerMaping. Find the corresponding service according to the two different mapping methods.
3. In the case of logout /logout, the logout page can be found through the SpringBean relationship. After successful logout, enter the /login login page.
The logging of CAS can be seen in the login-webflow.xml file, which has been implemented by Flowhandlermaping. On-start (start-state) process starts and end-state process ends the decision-state judgment, similar to if, view-state corresponds to a section of JSP page action-state corresponds to a section of the execution program.
