The request process and interception features of shrio cas integration:
To organize the entire login process (one login contains three requests):
http://localhost:8080/cas/login?a=0&service=http://localhost:8081/web/cas (a=0, parameter of cas login interface, & escape character)
The first request to the application server: the pre-cas part configured with the address http://localhost:8080/cas/login
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.
The second request to the application server: call the service part to verify the TGT, service=http://localhost:8081/web/cas
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: after the verification is passed, go to the ticket and then jump normally
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.
That is, the addresses of these three requests are all in the login page in the front part of the login address, and the latter part verifies the TGT, and then goes to the ticket for the last time and then jumps normally.
Simple cas:
Implemented with a filter in web.xml, his casServerLoginUrl is equivalent to the previous part of the cas login page request that shrio integrates with (A integration),
TGT verification is done in another filter, which is no longer like A integration, and it is necessary to manually call TGT verification by the second half of the address,
The login success callback address is the address to be logged in before the request is filtered and intercepted before login. It is equivalent to the successUrl displayed by the A integration. Of course, the A integration also has priority.
Jump to the address that was intercepted and logged in first when the request was made (the feature of the cas login success callback request page takes priority over successUrl (successUrl is used for direct login requests))
<filter>
<filter-name>CAS Authentication Filter</filter-name>
<filter-class>com.ylsoft.utils.MyCasFilter</filter-class>
<init-param>
<param-name>casServerLoginUrl</param-name>
<param-value>/login</param-value>
</init-param>
</filter>
<filter>
<filter-name>CAS Authentication Filter1</filter-name>
<filter-class>com.ylsoft.utils.MyCasFilter</filter-class>
<init-param>
<param-name>casServerLoginUrl</param-name>
<param-value>/login?a=1</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CAS Assertion Thread Local Filter</filter-name>
<url-pattern>/os/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>CAS Authentication Filter1</filter-name>
<url-pattern>/ou/*</url-pattern>
</filter-mapping>
After cas writes the cookie session, shrio will verify it by itself
Blocking Features:
Only after the authentication is successful, the session information will be written. The addresses that are not intercepted do not have the function of recording the session, and the interception of filters such as login interception will not have session records.
When distributed, the address of which service is requested will be intercepted by which service (where the interception url is configured), regardless of whether the request is sent from which service,
The feature of writing the interception address is to directly write /myaccount/getFirmCenter =csLogin after the project name without writing the project name,
This only looks at the url sent after assembly, regardless of before assembly, such as this system ${content}+"web/myaccount/getFirmCenter", or other systems
${content}+"/../web/myaccount/getFirmCenter "(/../ to go to other system names) The final request address is http://localhost:8081/web/myaccount/getFirmCenter
So: the interception address is in the web project with /myaccount/getFirmCenter =csLogin,
For custom interception such as fixed-point interception scheme, the custom interception takes precedence over the interception written in the interception factory (interception of the same function), that is, the interceptor of the same function conforms to the address rules.
If there are multiple interceptors (custom and default) for a url
For example, the configuration of multiple custom login filtering (there is one by default), when the url matches the filtering rules, the custom one is preferred.
For those that do not need to be intercepted, only those that are released can be released (anoe)