...
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.
Encrypt or sign?
Signing, rather than encrypting, the information in a ticket granting ticket is probably sufficient. Out of the box, CAS does not authenticate services validating service or proxy tickets, and so the full content of the ticket validation response is available to the possessor of a ticket granting ticket, service ticket, or proxy ticket. Of course, if you were to selectively enhance the ticket validation response on the basis of authenticating services requesting ticket validation, via such means as client certs on those requests, to restrict who has access to what information in a validation response, then the tickets containing this information would need to be encrypted rather than just signed.
Alternatives
An alternative approach is to cluster CAS by sharing state across CAS server instances in a cluster. This shared state could be in an RDBMS or in a messaging, in-memory Java state cache.