http://www.imooc.com/article/3720
Main principle: When a user accesses a client web application served by CAS for the first time (access URL: http://192.168.1.90:8081/web1 ), the cas AuthenticationFilter deployed in the client web application will intercept the request and generate service parameters , and then redirect to the login interface of the CAS service, the url is https://cas:8443/cas/login?service=http%3A%2F%2F192.168.1.90%3A8081%2Fweb1%2F , after the authentication is successful, the CAS server An authentication cookie will be generated, written to the browser, and the cookie will be cached locally on the server. The CAS server will also generate a ticket based on the service parameters. The ticket will be saved to the server and added to the url, and then the request will be redirected back to the client web application. The url is http://192.168.1.90:8081/web1/?ticket=ST-5-Sx6eyvj7cPPCfn0pMZuMwnbMvxpCBcNAIi6-20 . At this time, the AuthenticationFilter of the client will skip the ticket parameter after seeing it, and it will be processed by the TicketValidationFilter behind it. The TicketValidationFilter will use the httpclient tool to access the /serviceValidate interface of the cas service, and pass both the ticket and service to this interface, so that the interface verifies the ticket If the TicketValidationFilter gets a successful verification message, it will write the user information into the session of the web application. So far, the SSO session has been established. When the user accesses this web application in the same browser in the future, the AuthenticationFilter will read the user information in the session, so it will not go to CAS for authentication. In the web application, the AuthenticationFilter cannot read the user information in the session, and will go to the CAS login interface for authentication, but at this time CAS will read the cookie sent by the browser, so CAS will not require the user to log in to the login page. It just generates a ticket based on the service parameter, and then interacts with the web application to verify the ticket. When the cas client accesses the cas server, the server will obtain the information in the cookie. If there is information in the cookie, the login page will not appear.
In the last article "Encounter", as a novice, we had a preliminary understanding of CAS, installed it and had a simple experience. This article we further in-depth understanding of CAS.
The principle of CAS is basically the same as that of Nebula we developed by ourselves. All system applications will be directed to the CAS Server authentication center to log in. After successful login, the authentication center will generate a ticket called TGT (Ticket Granting Ticket). TGT represents the direct global session between the user and the authentication center. The existence of the TGT indicates that the user is logged in.
The TGT is not placed in the Session, that is to say, the implementation of the CAS global session does not directly use the Session mechanism, but uses the Cookie to implement itself. This Cookie is called TGC (Ticket Granting Cookie), which stores the id of the TGT, The authentication center server implements TGT.
We use the CAS installed in the previous article, log in to the authentication center, and see the changes in cookies before and after login. Obviously, after logging in, there is an extra cookie called CASTGC, which maintains the global session.
Before login: 
After login: 
If it is an application system login, in the same way, it will be guided to the authentication center to log in, and after successful login, it will be redirected back to the application system. At this time, a login token will be brought to inform the system that the application login is successful.
This token, called ST (Service Ticket) service ticket in CAS, is similar to Nebula's token. Of course, like Nebula, after the application system receives the ST, it will directly verify with the CAS Server. After the verification is passed, the application system can establish a local session and return the restricted resources accessed by the user. 
Let's take a look at the first login from the application system using the environment we built earlier. First visit www.ssoclient.com:81/index.do, the system redirects to www.cas.com authentication center, after entering the username and password, redirect back to www.ssoclient.com:81/index.do with ST The following is Three important HTTP trends. 
The first one, we can see that after the login is successful, the system will set the CASTGC cookie, and at the same time redirect back to the application with a ticket variable, which is ST.
The CAS official website gives a detailed user login sequence diagram, which is very detailed. I will not redraw the wheel here. The direct quotation is as follows: 
As can be seen from the flowchart, it is almost the same as Nebula's sequence diagram. Of course, as a mature open source CAS, the application scenarios considered are more abundant. So far, its CAS authentication protocol has continued to develop three versions, v1 implements single sign-on, and this version has similar functions to Nebula.
The v2 version focuses on adding proxy mode, which is a more complex form of authentication, that is, an authenticated web application (CAS Client) can directly access back-end services (such as mail servers) that require authentication as a proxy, and browser users do not need to Then directly authenticate and interact with the back-end service. This is more complicated and may be used in the portal, we will not discuss it here.
The v3 version further enriches the protocol. After verifying the ticket, the authentication center can not only return the identity ID, but also carry other basic user information such as the user's nickname and gender.
CAS not only provides a proprietary CAS protocol, but also supports standard open protocols such as SAML 1.1, OpenID, OAuth, etc., with wider availability.
The CAS project adopts the modular plug-in design idea, and its core sub-project is cas-server-core, which provides the core functions of CAS. Other functions are provided in the form of plug-ins and placed in different sub-projects.
Although CAS provides services in the form of web applications, in theory, the core function provided by CAS is authentication based on the ticket token method. This authentication has nothing to do with whether it is a web application. Therefore, in fact, the core module provided by cas-server-core has only two parts. One is Ticket, which includes various operations such as ticket generation, query, deletion, and storage. The other is authentication, which provides a variety of authentication methods.
Of course, CAS is a single sign-on support for web applications, a Web SSO solution to be exact. Therefore, cas-server-core also provides some of the most basic logical frameworks of the web layer, such as login request reception.
As an independent web application, CAS also needs to provide interaction with browser users and application systems that require authentication. Most of these logics are placed in two sub-projects, cas-server-webapp and cas-server-webapp-support middle. The CAS authentication center is implemented with Spring MVC + WebFlow, cas-server-webapp provides relevant interactive pages and web engineering configuration, and cas-server-webapp-support provides the relevant authentication process logic code based on WebFlow, which will call the back-end cas - Ticket and authentication functions provided by server-core.
The overall architecture of the CAS application officially provides a relatively clear architecture diagram, as shown below: 
After we have a general understanding of the interior of the CAS project, we start to practice, and we practice step by step how to practically apply CAS in the project. 
First, let's take a look at how to modify the login and logout process and related pages to meet the actual application needs. We let CAS complete the same login and logout process as our previous Nebula Server and provide a consistent interactive page.
The CAS page adopts the theme template method. Our needs are actually equivalent to customizing a set of our own theme templates.
Found in the WEB-INF/cas.properties file:
cas.themeResolver.defaultThemeName=cas-theme-default
cas.viewResolver.basename=default_viewsThese two parameters specify the style definition file and template definition file, which are referenced in WEB-INF/cas-servlet.xml. Modify these two values and use your own defined files:
cas.themeResolver.defaultThemeName=nebula-theme
cas.viewResolver.basename=nebula_viewsCreate the nebula-theme.properties file based on resources/cas-theme-default.properties, which defines the location of the css file and js file. Since we didn't use js, we only defined the following:
standard.custom.css.file=/css/nebula.cssCreate the /css/nebula.css file and copy the content of the css file in nebula.
Similarly, nebula_views.properties is created according to resources/default_views.properties. CAS defines many page templates by default, which represent the interface pages that different process nodes need to give users.
According to the login and logout process we used to develop Nebula earlier, only two pages are provided, one is the login page, which is used to deal with user login problems, and the other is the home page, which is the interface page for users before and after login. Therefore, in nebula_views, just define two templates.
nebulaLoginView.(class)=org.springframework.web.servlet.view.JstlView
nebulaLoginView.url=/WEB-INF/view/jsp/nebula/ui/login.jspnebulaIndexView.(class)=org.springframework.web.servlet.view.JstlView
nebulaIndexView.url=/WEB-INF/view/jsp/nebula/ui/index.jspAt the same time, we copy the two pages in nebula to /WEB-INF/view/jsp/nebula/ui and make corresponding adjustments.
According to the CAS login logic, for login.jsp, in addition to the two login parameters of username and password, three hidden parameters need to be added to the form, lt, execution, _eventId, lt is mainly to increase the security of page login and prevent repeated submissions. The other two ensure that the webflow login flow is properly followed.
The login and logout process of CAS is defined by webflow, which can better customize the login and logout process. The definition process description of login is login-webflow.xml, and logout-webflow.xml when logging out. We copy these two files as nebula-login-webflow.xml and nebula-logout-webflow.xml respectively as the basis for the process definition, and modify the login and logout process definition files in cas-servlet.xml to the above files.
The cas-servlet.xml file is specifically mentioned here. cas-servlet.xml is the spring mvc configuration file of CAS. The file defines the service interface and the controller that defines the processing: 
we see why there are no /login and /logout interfaces above? ? In fact, they have been configured as the webflow process entry, and go through the nebula-login-webflow.xml and nebula-logout-webflow.xml processes respectively. 
id is the corresponding path /login, and logout is the same, which can be found under the file.
As required, we modify the contents of nebula-login-webflow.xml and nebula-logout-webflow.xml. For nebula-login-webflow.xml, remove unnecessary process nodes, such as warn and proxy, and point the error response directly to the login page. Therefore, only two response pages, nebulaLoginView and nebulaIndexView, are provided in the login process.
For nebula-logout-webflow.xml, go directly to the login process after the logout ends normally. This is basically the same as Nebula's login and logout process.
OK, let's take a look at the modified effect. Let's take a look at the situation of logging in and out directly in the authentication center:
Enter www.cas.com to display the login page: 
after the login is successful, the home page is displayed: 
click logout, and the login page will be displayed, and the same is true for logging in from the application system. So far, we have modified the CAS authentication center login and logout process and related interface templates, which are basically the same as the Nebula authentication center's user experience.
Author: Hand in
Pocket_Link: http://www.imooc.com/article/3720
Source: MOOC