The CAS structure generally includes three parts: the CAS server, the application server, and the client. The client sends a request to the application server. Since it is not logged in, it will be redirected to the CAS server to log in. After the login is successful, it will jump back to the pre-login URL of the application server, but the CAS server will add a ticket parameter to the URL. The application server takes the ticket to the CAS server for verification. After the verification is successful, a session is added to indicate that it has logged in, and there is no need to log in again in the future.
In the web.xml configuration, the AuthenticationFilter and TicketValidationFilter filters are responsible for handling the login process.
web.xml configuration:
The processing flow of this filter can be seen from the source code:
If the session contains an attribute named "_const_cas_assertion_", that is, the user has already logged in, this filter is skipped.
If the ticket parameter is not empty, that is, it may be the URL that jumps back after logging in, this filter is skipped. (Note that AuthenticationFilter only judges whether the ticket is empty, and does not do the validity check of the ticket, that is, if you enter any ticket parameter in the URL, you can pass this filter. The second filter is responsible for validating the ticket: TicketValidationFilter .)
If the above two conditions are not met, that is, there is neither a session of "_const_cas_assertion_" nor a ticket parameter, then jump to the casServerLoginUrl configured in XML, let the user log in to the CAS Server, and add a parameter service to the URL (That is, the serverName of the XML configuration plus the relative path is used to return to the page before login after successful login).
Let's test it, first configure only one filter in web.xml and remove other filters:
enter the address http://localhost:9999/a/b/c in the browser and open it, it will jump to the login page, that is The casServerLoginUrl configured in XML, plus a parameter for returning the pre-login page, this parameter is generated by the serverName configured in XML plus the path /a/b/c, ie http://localhost:8080/cas/login? service=http://localhost:9999/a/b/c. Enter the user name and password on the page again to log in. If the login is successful, it will jump to the page specified by the service parameter, and add a parameter ticket, namely http://localhost:9999/a/b/c?ticket=ST-12 -1XGQRUtFnwtqQxdNLOdv-cas01.example.org.
Here you can test whether the AuthenticationFilter verifies the validity of the ticket. For example, open http://localhost:9999/a/b/c?ticket=123 in the browser, where the ticket parameter is written casually, which is definitely not legal, but the access can directly enter the page, no need to log in anymore. That is, AuthenticationFilter only judges whether the ticket is empty, and does not check whether it is legal.
2.
TicketValidationFilter is inherited from AbstractTicketValidationFilter because TicketValidationFilter and Cas20ProxyReceivingTicketValidationFilter. Let's look at the source code of the doFilter method in AbstractTicketValidationFilter:
The processing flow of this filter can be seen from the source code:
if there is a ticket parameter, check whether the ticket is valid (if not valid, an exception: org.jasig.cas.client.validation.TicketValidationException: CAS Server could not validate ticket).
If it is legal, add "_const_cas_assertion_" to the session and jump again. This jump is mainly to remove the ticket parameter, that is, from http://localhost:9999/a/b/c?ticket=ST-12-1XGQRUtFnwtqQxdNLOdv-cas01 .example.org jumps to http://localhost:9999/a/b/c. (One advantage of doing this is that if the user F5 refreshes the page, since there is no ticket parameter, the ticket will not be verified again, and the same ticket can only be used once, and a TicketValidationException exception will occur when going to the CAS server for verification.)
If not If the ticket parameter is used, this filter will be skipped directly (if there is no ticket parameter, the session must contain the attribute "_const_cas_assertion_", otherwise even the first filter AuthenticationFilter will not pass).
Sort out the entire login process:
Requesting the application server for the first time:
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, 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, "_const_cas_assertion_" will be added to the session, and then the ticket parameter will be removed to make a jump.
The third request to the application server:
At this time, since there is already "_const_cas_assertion_" in the session, the AuthenticationFilter will be passed. Since there is no ticket parameter, the TicketValidationFilter will also be passed, 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.
Taken from http://www.it165.net/pro/html/201407/18224.html