Apereo CAS deployments generally need a ticket registry: a place where CAS can store, find, update, and eventually forget tickets. Depending on your mood, budget, infrastructure team, and tolerance for YAML, this registry may be backed by Redis, Hazelcast, MongoDB, JDBC, Cassandra, Kafka, or any other technology that promises clustering nirvana just after you finish reading its 93-page production guide.
The stateless ticket registry takes a different path. Instead of storing tickets in a backend system, CAS produces tickets that carry their own state. The ticket itself becomes the suitcase, the passport, the boarding pass, the hotel reservation, and possibly the tiny shampoo bottle you were not supposed to take. CAS encrypts and compresses the ticket payload, and any CAS node that can decrypt and understand the ticket can process it without needing to ask a central storage service.
This post takes a closer look at the stateless ticket registry, where it shines, where it politely declines to participate, and what caveats you should understand before inviting it to production.
Our main focus is on:
Why Stateless?
A traditional ticket registry stores ticket state somewhere. That somewhere must be installed, maintained, monitored, upgraded, backed up, secured, tuned, and eventually blamed during an outage. A stateless ticket registry removes that moving part.
dependencies {
implementation "org.apereo.cas:cas-server-support-stateless-ticket-registry"
}
With the module included in the CAS WAR overlay, generated tickets become self-contained and portable across CAS nodes. This can be attractive in environments where:
- CAS runs in Kubernetes or another cloud-native platform.
- You want to reduce infrastructure dependencies.
- You do not want Redis, JDBC, Hazelcast, or another backend just to manage tickets.
- Your deployment needs horizontal scaling without registry replication gymnastics.
- You enjoy deleting entire sections from architecture diagrams.
The result is a deployment model where CAS nodes do not have to coordinate ticket state through a shared store. The ticket carries what CAS needs, and CAS validates it by decoding and decrypting the ticket itself.
What You Get
The obvious win is operational simplicity. There is no schema to migrate. There is no cache cluster to babysit. There is no expired-ticket cleanup process to tune. There is no “node A created the ticket but node B cannot find it” incident to enjoy at 2:17 AM while developing a sincere appreciation for coffee! You also get easier portability across clustered deployments. As long as CAS nodes share compatible configuration and cryptographic material, one node may issue a ticket and another node may validate it.
Supported Protocols
The stateless ticket registry is designed to support common CAS use cases, but it is not a universal drop-in replacement for every feature that has ever touched a ticket object. At the time of this writing, the following protocol families are generally supported:
- CAS protocol.
- SAML1.
- SAML2, with selected exceptions such as SAML2 attribute queries.
- OAuth2, with selected exceptions such as device authorization and token exchange.
- OpenID Connect, with selected exceptions such as DPoP.
This is a good time to remember that a ticket registry is not just a bucket of strings. Many CAS features create, update, retrieve, remove, track, count, correlate, revoke, or inspect tickets. A stateless registry changes the rules of that game.
Ticket Size: The Suitcase Has Limits
Stateless tickets carry their own state. This means the ticket value may become larger than what you are used to seeing with a traditional registry. CAS attempts to keep generated tickets compact, compressed, and constrained to a reasonable size. Still, you should assume ticket size is now part of your architecture.
For example, a traditional service ticket might look like:
A stateless service ticket may need to carry encoded, encrypted ticket state and therefore may be longer. This becomes important when tickets travel through:
- HTTP query parameters.
- Form posts.
- Response headers.
- Reverse proxies.
- Application servers.
- Older CAS clients.
You may need to review and adjust container and proxy limits. For example, with embedded Apache Tomcat in Spring Boot:
server.max-http-request-header-size=16KB
server.tomcat.max-http-form-post-size=2MB
If CAS is behind nginx, you may need something like:
large_client_header_buffers 4 16k;
client_header_buffer_size 16k;
The actual values depend on your environment, ticket size, client behavior, and proxy chain. The important lesson is not “copy these values and declare victory.” The important lesson is: test the entire path.
Long Service URLs: Bring a Smaller Backpack
Service tickets often need to remember the service URL for which they were issued. If your service URL looks like a complete autobiography with query parameters, tracking codes, tenant identifiers, UI state, campaign data, and the emotional history of the front-end team, your ticket size may suffer.
For example:
https://app.example.org/callback?tenant=alpha&theme=blue&returnUrl=https%3A%2F%2F...
CAS can apply a modest shortening strategy for long application URLs, and validation logic can account for that behavior. Still, shorter URLs are strongly recommended. A better pattern is:
https://app.example.org/cas/callback
Then let the application manage local routing state after authentication. This is not just a stateless-ticket-registry recommendation. It is a general life recommendation. Short URLs are easier to validate, easier to log, easier to compare, easier to troubleshoot, and less likely to become a novel.
Ticket Expiration
Because stateless tickets need to be decoded and decrypted, extremely aggressive expiration settings may become counterproductive. If your service tickets expire in the blink of an eye, a ticket might be issued, redirected, received, decoded, and rejected because the expiration policy was configured by someone who apparently benchmarks authentication flows using a stopwatch and a grudge.
A reasonable suggestion is to allow service tickets to live for around 30 seconds:
cas.ticket.st.time-to-kill-in-seconds=30
The exact property names may vary depending on the CAS version and policy type, so check the configuration metadata for your release. The intent is what matters:
- Service tickets should remain short-lived.
- Service tickets should generally remain single-use.
- The timeout should still allow realistic redirect and validation flows to complete.
This is especially important when applications, proxies, or clients add latency. The ticket should not live forever, but it should live long enough to reach adulthood, which in service-ticket years is approximately a few seconds.
Reusability and Idle Expiration
In a traditional ticket registry, CAS can update ticket state. It can track usage counts, idle timestamps, last-used moments, and other mutable state. In a stateless model, mutation is limited by design. The ticket is self-contained. Once issued, it is not sitting in a central registry waiting to be updated. This means expiration policies for generated tickets are generally reduced to enforcing an expiration instant. Reusability limits and idle/inactivity semantics are not handled in quite the same way.
For example, with a stateful registry like Redis, CAS may say:
“This TGT has not been used for 30 minutes. Expire it.”
With a stateless registry, there is no central TGT record whose idle timestamp can be continuously updated by all nodes. The ticket must be evaluated based on what it carries. You are trading centralized mutability for portability and operational simplicity.
The practical takeaway:
cas.ticket.tgt.primary.max-time-to-live-in-seconds=28800
Prefer hard expiration windows that match your risk profile. Avoid designing policies that require CAS to constantly update and remember server-side ticket state.
Encryption
Stateless tickets are encrypted to protect their contents. This is essential because the ticket carries state that would otherwise have lived inside a backend registry. This also means cryptographic configuration becomes operationally significant. All CAS nodes that participate in issuing and validating stateless tickets must agree on the relevant cryptographic settings and keys. If node A encrypts a ticket using one key and node B tries to decrypt it using another, the ticket validation ceremony will end quickly and without applause.
In containerized environments, you might externalize secrets:
cas.ticket.registry.crypto.encryption.key=${CAS_TICKET_REGISTRY_ENCRYPTION_KEY}
cas.ticket.registry.crypto.signing.key=${CAS_TICKET_REGISTRY_SIGNING_KEY}
The exact property path may differ by CAS version and registry implementation, so use your release’s configuration catalog as the final authority. Operationally, treat these keys like production secrets:
- Store them in a secret manager.
- Keep them consistent across CAS nodes.
- Rotate them carefully.
- Understand whether old tickets should survive rotation.
- Never generate fresh random keys independently per node unless you enjoy distributed authentication roulette.
A stateless ticket registry does not remove state from the universe. It moves some of that responsibility into cryptographic material and ticket payloads.
Attribute Resolution
One of the most important caveats is attribute handling. During the first leg of authentication, CAS may collect attributes from authentication handlers. In a stateful model, ticket state can preserve what happened during authentication. In a stateless model, particularly during back-channel ticket validation, attributes produced only during the original authentication transaction may not be available later.
This matters when an authentication handler produces attributes that are not otherwise resolvable. For example, imagine an authentication handler that returns:
{
"uid": "casuser",
"department": "engineering",
"favoriteDatabase": "the one that is currently up"
}
If department only exists because the authentication handler produced it during login, back-channel validation may not see it unless CAS can resolve it again from an attribute repository. The fix is to configure an attribute repository that can reproduce the required attributes during validation.
For example, using a JDBC-backed attribute repository:
cas.authn.attribute-repository.jdbc[0].url=jdbc:postgresql://db.example.org/iam
cas.authn.attribute-repository.jdbc[0].user=cas
cas.authn.attribute-repository.jdbc[0].password=${CAS_ATTR_REPO_PASSWORD}
cas.authn.attribute-repository.jdbc[0].sql=select * from user_attributes where uid=?
cas.authn.attribute-repository.jdbc[0].username=uid
Or with LDAP:
cas.authn.attribute-repository.ldap[0].ldap-url=ldaps://ldap.example.org
cas.authn.attribute-repository.ldap[0].base-dn=ou=people,dc=example,dc=org
cas.authn.attribute-repository.ldap[0].search-filter=uid={user}
cas.authn.attribute-repository.ldap[0].bind-dn=cn=cas,ou=services,dc=example,dc=org
cas.authn.attribute-repository.ldap[0].bind-credential=${CAS_LDAP_PASSWORD}
Single Logout
Back-channel single logout generally requires CAS to know which services participated in a single sign-on session. In a stateful registry, CAS can track that relationship. It can know which service tickets were issued under a TGT and which applications should receive logout notifications. In a stateless registry, there is no central backend holding that session graph. As a result, back-channel single logout is not supported in the same way. Similarly, administrative features that ask CAS to list active SSO sessions, inspect who is logged in, or forcibly terminate a user’s session are outside the scope of this model.
For example, this sort of operational question becomes difficult:
“Show me every active session for casuser and terminate them now.”
There is no central registry to query. CAS cannot inspect a storage backend that does not exist. If your environment requires central session visibility, administrative termination, or reliable back-channel logout, you should strongly consider a stateful registry option. If you mostly need short-lived ticket validation, horizontal portability, and fewer infrastructure dependencies, stateless may be a good fit.
The Browser Has a Job
The stateless ticket registry leans heavily on browser session management features during ticket exchanges. This means the browser must support local or session storage as required by the flow. In most modern environments this is fine. In more restrictive environments, you should test carefully:
- Locked-down kiosk or Privacy-enhanced browsers.
- Embedded web views and mobile in-app browsers.
If browser storage is blocked or aggressively cleared, some flows may behave poorly. This is not unique to CAS. Many modern identity flows depend on browser-side state to correlate requests, prevent forgery, and complete redirects. Still, stateless ticketing makes it especially important to test real clients rather than only your favorite developer browser with all shields down and a warm cup of optimism.
Final Thoughts
The stateless ticket registry is a powerful option for CAS deployments that want to reduce operational dependencies and simplify clustered ticket validation. It allows tickets to carry their own encrypted state, making them portable across CAS nodes without a shared backend registry.
That simplicity comes with trade-offs. You give up certain kinds of centralized tracking. You need to care about ticket size. You need to test proxy and client limits. You need to configure attribute repositories properly. You need to understand that single logout and administrative session management do not work the same way when there is no central session record to inspect.
Need Help?
If you have questions about the contents and the topic of this blog post, or if you need additional guidance and support, feel free to send us a note and ask about consulting and support services.
So…
I hope the content here was of some help to you and I am sure that both this post as well as the functionality it attempts to explain can be improved in any number of ways. If you have suggestions or ideas on how to improve this post, please feel free to reach out to us.
Misagh Moayyed
]]>
