...
- Round Robin - A list of the servers is maintained. Each request is assigned to the next computer in the list. When you get to the end of the list, you wrap back to the beginning.
- Master/Spare - All requests go to the first computer until it fails. Then requests go to the backup computer until the Master comes back up.
There is a problem when different requests from the same client are randomly distributed to different servers. The servers may be retaining some information about the client (like a "shopping basket" in eCommerce). This information is tied to a Session object, and so some clustering technology is designed to replicate the Session object and all its data to all the other servers that run the same application. JBoss servers do this when you turn on their clustering feature.
However, designers of Front End devices quickly learned However, if each Web request can go to a different server, then all the data about the current session either has to be saved back to the browser (as a cookie) or it has to be saved to a database that all servers in the cluster can access. The database limited performance. Companies building network equipment realized that they would have a competitive advantage if they the Front End learned a little bit about the common application and Web servers and made more intelligent decisions that optimized the performance of the servers and the customer applications they support. For example, if the Front End knows about the JSESSIONID parameter used by Java Web servers to identify Session data, then the Front End can send subsequent requests back to the same server that handled previous requests for the same transaction. Now the Web server doesn't have to replicate Session information frantically in order to handle the next Web page request, although it may back up data to recover from a server crash.As chips and memory became less expensive, Front End devices became more powerful and added even more features to protect and optimize applicationsmore about servers and protocols to optimize request routing and make things simpler and more efficient for the applications. Then they added additional features to enhance security. Today, these device track repetitive activity from very active IP addresses to detect and suppress Denial of Service attacks. With "deep packet inspection" they can identify attempts to hack a system. They can remove HTTP Headers regarded as inappropriate, and add Headers of their own. Vendors may provide even fairly complex services for very widely used programs, and local network administrators can add their own coding in some high level language for applications that are locally important.
For example, users at Yale know that CAS is "https://secure.its.yale.edu/cas". In reality, DNS resolves secure.its.yale.edu to 130.132.35.49 and that is a Virtual IP address (a VIP) on the BIG-IP F5. The VIP requires configuration, because the F5 has to hold the SSL Certificate for "secure.its.yale.edu" and manage the SSL protocol. Yale decided to make it appear that other security applications appear to run on the secure.its.yale.edu machine, even though each application has its own pool of VMs. So the F5 has to examine the URL to determine if the server name is followed with "/cas" and therefore goes to the pool of CAS VMs, or if it contains "/idp" and therefore goes to the Shibboleth pool of VMs. Because it is the F5 that is really talking to the browser, it has to create a special Header with the browser IP address in the event that it is important to the Web server.
The amount of logic in the Front End can be substantial. Suppose CAS wants to use X.509 User Certificates installed in the browser as a authetication authentication credential. CAS has an entire X509 support module, but that depends on the browser talking to the CAS server directly. If the Front End is terminating the SSL/TLS session itself, then it has to be configured with all the standard information needed by any Web component that handles user certificates. There has to be a special list of "Trusted" Certificate Authorities from which User Certificates will be accepted. The Front End has to tell the browser that certificates are required or optional. The signature in the submitted Certificate has to be validated against the Trusted CA list. The Certificate has to be ASN.1 decoded, and then the DN and/or one or more subjectAltNames has to be extracted, and they have to be turned into new HTTP headers that can be forwarded to the application. All this is fairly standard stuff and it is typically part of the built in code for any Front End device.Modern Front End systems can select specific servers from the pool based on data in the URL or Headers or based on the recent history of requests from that client device. Requests from phones could go to a different pool of servers than requests from PCs. If the Front End is going to all the trouble of decoding the X.509 User Certificate, then it could select servers based on organizational unit or geographic information that it contains. The application can write out a Cookie that the Front End can subsequently use to select specific servers for the next request.
So teaching a Front End about CAS protocol is not that big a deal. Commercial sites do this all the time, but they don't run CAS. Universities probably spend less time optimizing eCommerce applications and so they may not normally think about Front End devices this way.
...
A typical XML configuration for a particular type of ticket (when you use CushyCushyClusterConfiguration) looks like this:
<bean id="ticketGrantingTicketUniqueIdGenerator" class="org.jasig.cas.util.DefaultUniqueTicketIdGenerator">
<constructor-arg index="0" type="int" value="50" />
<constructor-arg index="1" value="#{clusterConfiguration.getTicketSuffix()}" />
</bean>
The suffix value, which is the index="1" argument to the Java object constructor, is obtained using a Spring "EL" expression to be the TicketSuffix property of the bean named clusterConfiguration. This is the CushyClusterConfiguration object that scans the configured cluster definitions to determine which cluster the server is running in and what name and IP address it uses. By directly feeding the output of clusterConfiguration into the input of the Ticket ID Generator, this approach makes configuration simple and ensures that all the machines come up configured properly. There is special logic in Cushy for an F5 which, for some reason, likes to identify hosts by the MD5 hash of the character representation of their decimal/dotted IPv4 address.
...
Cases 1-3 are only meaningful for a GET request. The only CAS POST is the login form and it is case 4.
CushyFrontEndFilter
CAS uses SSL/TLS sessions and they are rather expensive to set up. So after going to all the trouble to create one of these sessions, the client and the server reuse it over and over again. If the secure session was set up with client identification information, like an X.509 Certficate or a SPNEGO (Windows integrated AD login), then the SSL session belongs to just one user. Otherwise the session is anonymous and can carry many unrelated requests from many users.
The Front End will maintain a pool of already established SSL connections to the CAS servers. If it routes a request using the logic of cases 1-3 to a specific server, this has nothing to do with what Web servers normally describe as a "session". Consecutive ST validation requests from the same application will go to different CAS servers based on different suffix values in the different ST ids, and they will reuse entirely different idle SSL sessions from the pool.It is not always possible to convince the network administrators who own the Front End device to add programming for CAS protocol. It turns out, however, that this sort of programming is a good idea even if you have to wait until the request hits the application servers.
CushyFrontEndFilter is a Java Servlet Filter that you can insert using WEB-INF/web.xml in the CAS WAR file. It is typically configured by CushyClusterConfiguration to know the ticket suffix and URL of the other nodes in a CAS cluster. It builds a small pool of reusable SSL sessions with each member of the cluster and uses them to forward GET requests that the case 1-3 analysis indicates would better be handled by another node that generated the ticket. It sends back to the browser whatever reply the other node generated. In short, it does what we would prefer the Front End do, but it waits until the request hits the processing stack of one of the CAS servers.
This adds some overhead and some network delay due to the request forwarding. However, it turns out that you can save more overhead and reduce more delay than the Filter consumes.
Start with an existing configuration that uses Ehcache for the TicketRegistry. The standard configuration creates a Service Ticket cache that replicates ticket operations "synchronously" (the node that creates the ticket has to wait until the RMI call to all the other nodes finishes copying the ticket to the other caches before it can return the ticketid to the browser). If you have a two node cluster, then every Service Ticket that is created has to wait for one RMI call to the other node, and then because all operations are synchronous, every ST validation that deletes the ticket also has to wait for that RMI call to get to the other node. So the overhead is two network operations and each is synchronous, delaying the return of the response to the client.
Now consider the same configuration with CushyFrontEndFilter inserted in front of the stack, and because of that you reconfigure the ticketRegistry.xml file so that Ehcache uses delayed replication for Service Tickets with the same parameters it uses for Login Tickets.
The Front End randomly chooses a CAS server, which creates the Service Ticket and sends it back to the
If you would like to see how this sort of programming is done, but you don't want to learn about real Front End devices, the same program logic is defined in the CushyFrontEndFilter.
...