There was an interesting post about making CAS ticket granting tickets self-validating as an approach to load balancing CAS. This page is for collecting thoughts about this idea.
The idea
In short, the idea is: "the TGC delivered to the client is no longer a truly random string; instead, it contains encrypted details of the ticket which can be used to validate it in the absence of a cache entry".
Rather than using ticket granting cookies that are nothing more than large random numbers, and so are meaningless to anyone other than the CAS server that issued them, instead CAS server would issue ticket granting cookies that are an encryption of the username with a private key shared across the CAS server instances in the load balanced set.
This means that when the user comes back to CAS, any of the CAS servers in the set can recognize the ticket granting cookie and whom it authenticates.
The idea is intended to reduce the need for state sharing across load balanced CAS instances.
Issues
Approach for other tickets
Ticket granting cookies are not the only tickets CAS vends. CAS also vends service tickets, proxy tickets, proxy granting tickets... When a service validates a service ticket someone presented to it, it will randomly reach one of the load balanced CAS instances. That CAS instance will need to be able to recognize and validate the service ticket. Either this same self-validating-ticket approach would need to be used to encrypt or at least sign the service identifier and other information (renewness) into the service ticket, or the CAS servers would need to share state about outstanding service tickets. Proxy tickets additionally bear an arbitrarily long chain of proxying entities, a chunk of information that would become unweildy for encrypting or signing into the proxy ticket itself.
It's hard to enforce on-time-use and revocation for self-validating tickets. That is, once you validate a service ticket it's not supposed to be re-validatable, to prevent replay attacks.
Potentially large content for ticket granting cookies
The content borne by a ticket granting ticket in CAS 3 is more than merely a String username. The ticket validation response can include arbitrary attributes. All of this content would need to be signed or encrypted into the ticket granting cookie for this self-validating ticket-granting-cookie scheme to work. Which might be fine – presumably a Cookie could accomodate this.