...
When the CAS server receives the request, CAS authenticates the user either via prompting the user to login or by checking to see if they already have an active SSO session with CAS (Ticket Granting Ticket, TGT). If authentication is successful, CAS generates verifies that application1 has been loaded into it's persistent store of CAS registered services, generates a service ticket (ST) and programmatically forms a new URL request (redirection) back to application1 with the ST as a request parameter in the query string. Remember that the user does not see any of this. Also, please note that HTTPS is marked with parentheses. It is critical that you understand how HTTPS can be used. CAS will make no assumptions outside of the authentication security mechanism. HTTPS recommendations and practices will be discussed in separate documentation.
...
The other server receives this request through a CAS client (either a servlet filter or a module) that's been configured with application1. It parses the ticket and starts a new HTTPS connection with the CAS server. This new request is formed programmatically by the CAS filter Java code and it's commonly called the "service validation" step.
CAS receives and validates this secure server-to-server request, verifies that application1 has been loaded into it's persistent store of CAS registered services, and if successful, fulfills then fulfills the application server's HTTPS CAS client request and returns an XML message of "success" along with the authenticated username. Remember that all of this is occurring whilst the user has only made a single request to access application1. The original request then exits the CAS filter/module and allows application1 to serve content to this newly authenticated user.
...