首页 > CAS 配置票据组件

CAS 配置票据组件

相关标签: 配置 cas

2020腾讯云“6.18”活动开始了!!!(巨大优惠重现!4核8G,5M带宽 1999元/3年),




  • TicketRegistry - 用于票据持久化.
  • ExpirationPolicy - Provides a policy framework for ticket expiration semantics.


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

默认(In-Memory) 票据注册

DefaultTicketRegistry uses a ConcurrentHashMap for memory-backed ticket storage and retrieval. This component does not preserve ticket state across restarts. There are a few configuration knobs available:

  • initialCapacity - ConcurrentHashMap initial capacity.
  • loadFactor - ConcurrentHashMap load factor.
  • concurrencyLevel - Allows tuning the ConcurrentHashMap for concurrent write support.

All three arguments map to those of the ConcurrentHashMap constructor.

<bean id="ticketRegistry"
      c:concurrencyLevel="20" />


Cache-Based 票据注册

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

RDBMS Ticket Registries

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


CAS presents a pluggable architecture for generating unique ticket ids for each ticket type. The configuration of each generator is defined at src\main\webapp\WEB-INF\spring-configuration\uniqueIdGenerators.xml. Here’s a brief sample:

<bean id="ticketGrantingTicketUniqueIdGenerator" class="org.jasig.cas.util.DefaultUniqueTicketIdGenerator"
        c:maxLength="50" c:suffix="${}" />

<bean id="serviceTicketUniqueIdGenerator" class="org.jasig.cas.util.DefaultUniqueTicketIdGenerator"
    c:maxLength="20" c:suffix="${}" />

<bean id="loginTicketUniqueIdGenerator" class="org.jasig.cas.util.DefaultUniqueTicketIdGenerator"
    c:maxLength="30" c:suffix="${}" />

<bean id="proxy20TicketUniqueIdGenerator" class="org.jasig.cas.util.DefaultUniqueTicketIdGenerator"
    c:maxLength="20" c:suffix="${}" />

<util:map id="uniqueIdGeneratorsMap">
        value-ref="serviceTicketUniqueIdGenerator" />




Strategy parent interface that describes operations needed to generate a unique id for a ticket.


Uses numeric and random string generators to create a unique id, while supporting prefixes for each ticket type, as is outlined by the CAS protocol, as well as a suffix that typically is mapped to the CAS server node identifier in order to indicate which node is the author of this ticket. The latter configuration point helps with troubleshooting and diagnostics in a clustered CAS environment.


An extension of DefaultUniqueTicketIdGenerator that is able auto-configure the suffix based on the underlying host name. In order to assist with multi-node deployments, in scenarios where CAS configuration and file is externalized, it would be ideal to simply just have one set of configuration files for all nodes, such that there would for instance be one file for all nodes. This would remove the need to copy/sync configuration files over across nodes, again in a situation where they are externalized.

The drawback is that in keeping only one file, we’d lose the ability to define unique host.nameproperty values for each node as the suffix, which would assist with troubleshooting and diagnostics. To provide a remedy, this ticket generator is able to retrieve the value directly from the actual node name, rather than relying on the configuration, only if one isn’t specified in the file.


Unique Ticket Id Generator compliant with the SAML 1.1 specification for artifacts, that is also compliant with the SAML v2 specification.

Ticket Registry Cleaner

The ticket registry cleaner should be used for ticket registries that cannot manage their own state. That would include the default in-memory registry and the JPA ticket registry. Cache-based ticket registry implementations such as Memcached, Hazelcast or Ehcache do not require a registry cleaner. The ticket registry cleaner configuration is specified in the spring-configuration/ticketRegistry.xml file.



Strategy interface to denote the start of cleaning the registry.


The default ticket registry cleaner scans the entire CAS ticket registry for expired tickets and removes them. This process is only required so that the size of the ticket registry will not grow beyond a reasonable size. The functionality of CAS is not dependent on a ticket being removed as soon as it is expired. Locking strategies may be used to support high availability environments. In a clustered CAS environment with several CAS nodes executing ticket cleanup, it is desirable to execute cleanup from only one CAS node at a time.


Strategy pattern for defining a locking strategy in support of exclusive execution of some process.


No-Op locking strategy that allows the use of DefaultTicketRegistryCleaner in environments where exclusive access to the registry for cleaning is either unnecessary or not possible.


If you’re using the default ticket registry configuration, your /cas-server-webapp/WEB-INF/spring-configuration/ticketRegistry.xml probably looks like this:

<bean id="ticketRegistryCleaner" 

<bean id="jobDetailTicketRegistryCleaner"  
    p:targetMethod="clean" />

<bean id="triggerJobDetailTicketRegistryCleaner" 
    p:repeatInterval="5000000" />


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.


配置票据组件 有两个配置票据的组件: TicketRegistry - 用于票据持久化. ExpirationPolicy - Provides a policy framework for ticket expiration semantics. 票据注册 The deployment environm