APEREO CASDocumentation

Enterprise Authentication for All Earthlings and Beyond

Identity, Single Sign-On and Access Management
View on GitHub

Ticketing

There are two core configurable ticketing components:

  • TicketRegistry - Provides for durable ticket storage.
  • ExpirationPolicy - Provides a policy framework for ticket expiration semantics.

Ticket Registry

The deployment environment and technology expertise generally determine the particular TicketRegistry component. A cache-backed implementation is recommended for HA deployments, while the default in-memory registry may be suitable for small deployments.

Actuator Endpoints

The following endpoints are provided by CAS:

ticketRegistry
CAS endpoint3 operationsNot exposed by defaultcas-server-support-reports
1

Include the module that provides this endpoint in the WAR overlay:

Show in CAS Initializr Generate CAS Server WAR Overlay 
1
2
3
4
5

<dependency>
    <groupId>org.apereo.cas</groupId>
    <artifactId>cas-server-support-reports</artifactId>
    <version>${cas.version}</version>
</dependency>

1

implementation "org.apereo.cas:cas-server-support-reports:${project.'cas.version'}"

1
2
3
4
5
6
7
8
9

dependencyManagement {
    imports {
        mavenBom "org.apereo.cas:cas-server-support-bom:${project.'cas.version'}"
    }
}

dependencies {
    implementation "org.apereo.cas:cas-server-support-reports"
}

1
2
3
4
5
6
7
8
9
10

dependencies {
    /*
        The following platform references are included automatically and are listed for reference only.

        implementation enforcedPlatform("org.apereo.cas:cas-server-support-bom:${project.'cas.version'}")
        implementation platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)
        
    */
    implementation "org.apereo.cas:cas-server-support-reports"
}
2

Turn the endpoint on and expose it over the web. One entry covers every operation. By default only info, health and status are exposed.

1
2

management.endpoint.ticketRegistry.access=UNRESTRICTED
management.endpoints.web.exposure.include=ticketRegistry

Endpoints may be mapped to other paths. For example, to serve health at healthcheck:

1

management.endpoints.web.path-mapping.health=healthcheck

How Do I Choose?

There are a wide range of ticket registries on the menu. The selection criteria are outlined below:

  • Choose a technology that you are most familiar with and have the skills and patience to troubleshoot, tune and scale for the win.
  • Choose a technology that does not force your CAS configuration to be tied to any individual servers/nodes in the cluster, as this will present auto-scaling issues and manual effort.
  • Choose a technology that works well with your network and firewall configuration and is performant and reliable enough based on your network topology.
  • Choose a technology that shows promising results under your expected load, having run performance and stress tests.
  • Choose a technology that does not depend on outside processes and systems as much as possible, is self-reliant and self contained.

The above outlines suggestions and guidelines you may wish to consider. Each option presents various pros and cons and in the end, you must decide which drawbacks or advantages provide you with the best experience.

Comparison

The table below compares the registries on the properties that matter most when choosing one. Each registry’s own page has the details, including connection, replication and encryption settings.

Registry Kind Shared across nodes Tickets survive a full restart Distributed locking
Default In memory No, one node only No In-process only
Stateless No storage Yes, with the same keys on every node Yes, tickets travel with the request Not needed
Hazelcast Cache grid Yes Only while some cluster members keep running In-process only
Apache Ignite Cache grid Yes Only while some cluster members keep running In-process only
Apache Geode Cache grid Yes Only while some cluster members keep running In-process only
AMQP, Kafka, Pulsar, Google Cloud PubSub Messaging Yes, replicated through the broker No In-process only
JPA Database Yes Yes Yes
Redis Database Yes When Redis persistence is turned on Yes
MongoDb Database Yes Yes In-process only
DynamoDb Database Yes Yes In-process only
Apache Cassandra Database Yes Yes In-process only
Google Cloud Firestore Database Yes Yes In-process only
Memcached (deprecated) Cache Yes No In-process only
Azure CosmosDb (deprecated) Database Yes Yes In-process only

“In-process only” means CAS uses the default lock implementation, which only coordinates requests within one node.

Cache-Based Ticket Registries

Cached-based ticket registries provide a high-performance solution for ticket storage in high availability deployments. Components for the following caching technologies are provided:

Stateless Ticket Registries

Stateless ticket registries require no backend storage with a few caveats and limitations.

Message-based Ticket Registries

RDBMS Ticket Registries

RDBMS-based ticket registries provide a distributed ticket store across multiple CAS nodes. Components for the following caching technologies are provided:

NoSQL Ticket Registries

CAS also provides support for a variety of other databases, including Redis, MongoDb and Apache Cassandra, for ticket storage and persistence:

Secure Cache Replication

A number of cache-based ticket registries support secure replication of ticket data across the wire, so that tickets are encrypted and signed on replication attempts to prevent sniffing and eavesdrops. See this guide for more info.

Ticket Registry Locking

A number of ticket registries support advanced distributed locking operations for highly concurrent requests, to assist with synchronization of data and atomicity of operations. See this guide for more info.

Ticket Expiration Policies

CAS supports a pluggable and extensible policy framework to control the expiration policy of ticket-granting tickets (TGT) and service tickets (ST). See this guide for details on how to configure the expiration policies.