Java Apereo CAS Client

Intro

This is the official home of the Java Apereo CAS client. The client consists of a collection of Servlet filters that are suitable for most Java-based web applications. It also serves as an API platform to interact with the CAS server programmatically to make authentication requests, validate tickets and consume principal attributes.

All client artifacts are published to Maven central. Depending on functionality, applications will need include one or more of the listed dependencies in their configuration.

Build

git clone [email protected]:apereo/java-cas-client.git
cd java-cas-client
mvn clean package

Components

• Core functionality, which includes CAS authentication/validation filters.

<dependency>
    <groupId>org.apereo.cas.client</groupId>
    <artifactId>cas-client-core</artifactId>
    <version>${java.cas.client.version}</version>
</dependency>

• Support for SAML functionality is provided by this dependency:

<dependency>
   <groupId>org.apereo.cas.client</groupId>
   <artifactId>cas-client-support-saml</artifactId>
   <version>${java.cas.client.version}</version>
</dependency>

• Distributed proxy ticket caching with Ehcache is provided by this dependency:

<dependency>
   <groupId>org.apereo.cas.client</groupId>
   <artifactId>cas-client-support-distributed-ehcache</artifactId>
   <version>${java.cas.client.version}</version>
</dependency>

• Distributed proxy ticket caching with Memcached is provided by this dependency:

<dependency>
   <groupId>org.apereo.cas.client</groupId>
   <artifactId>cas-client-support-distributed-memcached</artifactId>
   <version>${java.cas.client.version}</version>
</dependency>

• Spring Boot AutoConfiguration is provided by this dependency:

<dependency>
   <groupId>org.apereo.cas.client</groupId>
   <artifactId>cas-client-support-springboot</artifactId>
   <version>${java.cas.client.version}</version>
</dependency>

Configuration

Strategies

The client provides multiple strategies for the deployer to provide client settings. The following strategies are supported:

• JNDI (JNDI)
• Properties File (PROPERTY_FILE). The configuration is provided via an external properties file. The path may be specified in the web context as such:

<context-param>
    <param-name>configFileLocation</param-name>
    <param-value>/etc/cas/file.properties</param-value>
</context-param>

If no location is specified, by default /etc/java-cas-client.properties will be used.

• System Properties (SYSTEM_PROPERTIES)
• Web Context (WEB_XML)
• Default (DEFAULT)

In order to instruct the client to pick a strategy, strategy name must be specified in the web application's context:

<context-param>
    <param-name>configurationStrategy</param-name>
    <param-value>DEFAULT</param-value>
</context-param>

If no configurationStrategy is defined, DEFAULT is used which is a combination of WEB_XML and JNDI.

Client Configuration Using web.xml

The client can be configured in web.xml via a series of context-params and filter init-params. Each filter for the client has a required (and optional) set of properties. The filters are designed to look for these properties in the following way:

• Check the filter's local init-params for a parameter matching the required property name.
• Check the context-params for a parameter matching the required property name.
• If two properties are found with the same name in the init-params and the context-params, the init-param takes precedence.

Note: If you're using the serverName property, you should note well that the fragment-URI (the stuff after the #) is not sent to the server by all browsers, thus the CAS client can't capture it as part of the URL.

An example application that is protected by the client is available here.

org.apereo.cas.client.authentication.AuthenticationFilter

The AuthenticationFilter is what detects whether a user needs to be authenticated or not. If a user needs to be authenticated, it will redirect the user to the CAS server.

<filter>
  <filter-name>CAS Authentication Filter</filter-name>
  <filter-class>org.apereo.cas.client.authentication.AuthenticationFilter</filter-class>
  <init-param>
    <param-name>casServerUrlPrefix</param-name>
    <param-value>https://battags.ad.ess.rutgers.edu:8443/cas</param-value>
  </init-param>
  <init-param>
    <param-name>serverName</param-name>
    <param-value>http://www.acme-client.com</param-value>
  </init-param>
</filter>
<filter-mapping>
    <filter-name>CAS Authentication Filter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Ignore Patterns

The following types are supported:

org.apereo.cas.client.authentication.Saml11AuthenticationFilter

The SAML 1.1 AuthenticationFilter is what detects whether a user needs to be authenticated or not. If a user needs to be authenticated, it will redirect the user to the CAS server.

<filter>
  <filter-name>CAS Authentication Filter</filter-name>
  <filter-class>org.apereo.cas.client.authentication.Saml11AuthenticationFilter</filter-class>
  <init-param>
    <param-name>casServerLoginUrl</param-name>
    <param-value>https://somewhere.cas.edu:8443/cas/login</param-value>
  </init-param>
  <init-param>
    <param-name>serverName</param-name>
    <param-value>http://www.the-client.com</param-value>
  </init-param>
</filter>
<filter-mapping>
    <filter-name>CAS Authentication Filter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

org.apereo.cas.client.validation.Cas10TicketValidationFilter

Validates tickets using the CAS 1.0 Protocol.

<filter>
  <filter-name>CAS Validation Filter</filter-name>
  <filter-class>org.apereo.cas.client.validation.Cas10TicketValidationFilter</filter-class>
  <init-param>
    <param-name>casServerUrlPrefix</param-name>
    <param-value>https://somewhere.cas.edu:8443/cas</param-value>
  </init-param>
  <init-param>
    <param-name>serverName</param-name>
    <param-value>http://www.the-client.com</param-value>
  </init-param>    
</filter>
<filter-mapping>
    <filter-name>CAS Validation Filter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

org.apereo.cas.client.validation.Saml11TicketValidationFilter

Validates tickets using the SAML 1.1 protocol.

<filter>
  <filter-name>CAS Validation Filter</filter-name>
  <filter-class>org.apereo.cas.client.validation.Saml11TicketValidationFilter</filter-class>
  <init-param>
    <param-name>casServerUrlPrefix</param-name>
    <param-value>https://battags.ad.ess.rutgers.edu:8443/cas</param-value>
  </init-param>
  <init-param>
    <param-name>serverName</param-name>
    <param-value>http://www.acme-client.com</param-value>
  </init-param>
</filter>
<filter-mapping>
    <filter-name>CAS Validation Filter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

org.apereo.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter

Validates the tickets using the CAS 2.0 protocol. If you provide either the acceptAnyProxy or the allowedProxyChains parameters, a Cas20ProxyTicketValidator will be constructed. Otherwise a general Cas20ServiceTicketValidator will be constructed that does not accept proxy tickets.

Note: If you are using proxy validation, you should place the filter-mapping of the validation filter before the authentication filter.

<filter>
  <filter-name>CAS Validation Filter</filter-name>
  <filter-class>org.apereo.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>
  <init-param>
    <param-name>casServerUrlPrefix</param-name>
    <param-value>https://battags.ad.ess.rutgers.edu:8443/cas</param-value>
  </init-param>
  <init-param>
    <param-name>serverName</param-name>
    <param-value>http://www.acme-client.com</param-value>
  </init-param>
</filter>
<filter-mapping>
    <filter-name>CAS Validation Filter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

org.apereo.cas.client.validation.Cas30ProxyReceivingTicketValidationFilter

Validates the tickets using the CAS 3.0 protocol. If you provide either the acceptAnyProxy or the allowedProxyChains parameters, a Cas30ProxyTicketValidator will be constructed. Otherwise a general Cas30ServiceTicketValidator will be constructed that does not accept proxy tickets. Supports all configurations that are available for Cas20ProxyReceivingTicketValidationFilter.

org.apereo.cas.client.validation.Cas30JsonProxyReceivingTicketValidationFilter

Identical to Cas30ProxyReceivingTicketValidationFilter, yet the filter is able to accept validation responses from CAS that are formatted as JSON per guidelines laid out by the CAS protocol. See the protocol documentation for more info.

org.apereo.cas.client.validation.CasJWTTicketValidationFilter

Validates service tickets that issued by the CAS server as JWTs.

At the moment, only JWTs that are first signed and then encrypted (in that order) are supported by this filter.

<filter>
  <filter-name>CAS Validation Filter</filter-name>
  <filter-class>org.apereo.cas.client.validation.CasJWTTicketValidationFilter</filter-class>
  <init-param>
    <param-name>signingKey</param-name>
    <param-value>...</param-value>
  </init-param>
  <init-param>
    <param-name>encryptionKey</param-name>
    <param-value>...</param-value>
  </init-param>
</filter>
<filter-mapping>
    <filter-name>CAS Validation Filter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Proxy Authentication vs. Distributed Caching

The client has support for clustering and distributing the TGT state among application nodes that are behind a load balancer. In order to do so, the parameter needs to be defined as such for the filter.

Ehcache

Configure the client:

<init-param>
  <param-name>proxyGrantingTicketStorageClass</param-name>
  <param-value>org.apereo.cas.client.EhcacheBackedProxyGrantingTicketStorageImpl</param-value>
</init-param>

The setting provides an implementation for proxy storage using EhCache to take advantage of its replication features so that the PGT is successfully replicated and shared among nodes, regardless which node is selected as the result of the load balancer rerouting.

Configuration of this parameter is not enough. The EhCache configuration needs to enable the replication mechanism through once of its suggested ways. A sample of that configuration based on RMI replication can be found here. Please note that while the sample is done for a distributed ticket registry implementation, the basic idea and configuration should easily be transferable.

When loading from the web.xml, the Apereo CAS Client relies on a series of default values, one of which being that the cache must be configured in the default location (i.e. classpath:ehcache.xml).

<cacheManagerPeerProviderFactory class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
   properties="peerDiscovery=automatic,
   multicastGroupAddress=230.0.0.1, multicastGroupPort=4446"/>
 
<cacheManagerPeerListenerFactory class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory"/>
 
<cache
   name="org.apereo.cas.client.EhcacheBackedProxyGrantingTicketStorageImpl.cache"
   maxElementsInMemory="100"
   eternal="false"
   timeToIdleSeconds="100"
   timeToLiveSeconds="100"
   overflowToDisk="false">
   <cacheEventListenerFactory class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"/>
</cache>

Memcached

A similar implementation based on Memcached is also available.

Configure the client:

<init-param>
  <param-name>proxyGrantingTicketStorageClass</param-name>
  <param-value>org.apereo.cas.client.proxy.MemcachedBackedProxyGrantingTicketStorageImpl</param-value>
</init-param>

When loading from the web.xml, the Client relies on a series of default values, one of which being that the list of memcached servers must be defined in /cas/casclient_memcached_hosts.txt on the classpath). The file is a simple list of <hostname>:<ports> on separate lines. BE SURE NOT TO HAVE EXTRA LINE BREAKS.

org.apereo.cas.client.HttpServletRequestWrapperFilter

Wraps an HttpServletRequest so that the getRemoteUser and getPrincipal return the CAS related entries.

<filter>
  <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
  <filter-class>org.apereo.cas.client.HttpServletRequestWrapperFilter</filter-class>
</filter>
<filter-mapping>
  <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

org.apereo.cas.client.AssertionThreadLocalFilter

Places the Assertion in a ThreadLocal for portions of the application that need access to it. This is useful when the Web application that this filter "fronts" needs to get the Principal name, but it has no access to the HttpServletRequest, hence making getRemoteUser() call impossible.

<filter>
  <filter-name>CAS Assertion Thread Local Filter</filter-name>
  <filter-class>org.apereo.cas.client.AssertionThreadLocalFilter</filter-class>
</filter>
<filter-mapping>
  <filter-name>CAS Assertion Thread Local Filter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

org.apereo.cas.client.ErrorRedirectFilter

Filters that redirects to the supplied url based on an exception. Exceptions and the urls are configured via init filter name/param values.

<filter>
  <filter-name>CAS Error Redirect Filter</filter-name>
  <filter-class>org.apereo.cas.client.ErrorRedirectFilter</filter-class>
  <init-param>
    <param-name>java.lang.Exception</param-name>
    <param-value>/error.jsp</param-value>
  </init-param>
  <init-param>
    <param-name>defaultErrorRedirectPage</param-name>
    <param-value>/defaulterror.jsp</param-value>
  </init-param>
</filter>
<filter-mapping>
  <filter-name>CAS Error Redirect Filter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

Client Configuration Using Spring

Configuration via Spring IoC will depend heavily on DelegatingFilterProxy class. For each filter that will be configured for CAS via Spring, a corresponding DelegatingFilterProxy is needed in the web.xml.

As the HttpServletRequestWrapperFilter and AssertionThreadLocalFilter have no configuration options, we recommend you just configure them in the web.xml

<filter>
    <filter-name>CAS Authentication Filter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    <init-param>
        <param-name>targetBeanName</param-name>
        <param-value>authenticationFilter</param-value>
    </init-param>
  </filter>
<filter-mapping>
    <filter-name>CAS Authentication Filter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Bean Configuration

AuthenticationFilter

<bean
    name="authenticationFilter"
    class="org.apereo.cas.client.authentication.AuthenticationFilter"
    p:casServerLoginUrl="https://localhost:8443/cas/login"
    p:renew="false"
    p:gateway="false"
    p:service="https://my.local.service.com/cas-client" />

Cas10TicketValidationFilter

<bean
    name="ticketValidationFilter"
    class="org.apereo.cas.client.validation.Cas10TicketValidationFilter"
    p:service="https://my.local.service.com/cas-client">
    <property name="ticketValidator">
        <bean class="org.apereo.cas.client.validation.Cas10TicketValidator">
            <constructor-arg index="0" value="https://localhost:8443/cas" />
        </bean>
    </property>
</bean>

Saml11TicketValidationFilter

<bean
    name="ticketValidationFilter"
    class="org.apereo.cas.client.validation.Saml11TicketValidationFilter"
    p:service="https://my.local.service.com/cas-client">
    <property name="ticketValidator">
        <bean class="org.apereo.cas.client.validation.Saml11TicketValidator">
            <constructor-arg index="0" value="https://localhost:8443/cas" />
        </bean>
    </property>
</bean>

Cas20ProxyReceivingTicketValidationFilter

Configuration to validate tickets:

<bean
    name="ticketValidationFilter"
    class="org.apereo.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter"
    p:service="https://my.local.service.com/cas-client">
    <property name="ticketValidator">
        <bean class="org.apereo.cas.client.validation.Cas20ServiceTicketValidator">
            <constructor-arg index="0" value="https://localhost:8443/cas" />
        </bean>
    </property>
</bean>

Configuration to accept a Proxy Granting Ticket:

<bean
    name="ticketValidationFilter"
    class="org.apereo.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter"
    p:service="https://my.local.service.com/cas-client"
    p:proxyReceptorUrl="/proxy/receptor">
    <property name="ticketValidator">
        <bean
            class="org.apereo.cas.client.validation.Cas20ServiceTicketValidator"
            p:proxyCallbackUrl="/proxy/receptor">
            <constructor-arg index="0" value="https://localhost:8443/cas" />
        </bean>
    </property>
</bean>

Configuration to accept any Proxy Ticket (and Proxy Granting Tickets):

<bean
    name="ticketValidationFilter"
    class="org.apereo.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter"
    p:service="https://my.local.service.com/cas-client"
    p:proxyReceptorUrl="/proxy/receptor">
    <property name="ticketValidator">
        <bean class="org.apereo.cas.client.validation.Cas20ProxyTicketValidator"
            p:acceptAnyProxy="true"
            p:proxyCallbackUrl="/proxy/receptor">
            <constructor-arg index="0" value="https://localhost:8443/cas" />
        </bean>
    </property>
</bean>

Configuration to accept Proxy Ticket from a chain (and Proxy Granting Tickets):

<bean
    name="ticketValidationFilter"
    class="org.apereo.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter"
    p:service="https://my.local.service.com/cas-client"
    p:proxyReceptorUrl="/proxy/receptor">
    <property name="ticketValidator">
        <bean class="org.apereo.cas.client.validation.Cas20ProxyTicketValidator"
            p:proxyCallbackUrl="/proxy/receptor">
            <constructor-arg index="0" value="https://localhost:8443/cas" />
            <property name="allowedProxyChains">
                <list>
                    <value>http://proxy1 http://proxy2</value>
                </list>
            </property>
        </bean>
    </property>
</bean>

The specific filters can be configured in the following ways. Please see the JavaDocs included in the distribution for specific required and optional properties:

Spring Boot AutoConfiguration

Usage

• Define a dependency:

Maven:

<dependency>
   <groupId>org.apereo.cas.client</groupId>
   <artifactId>cas-client-support-springboot</artifactId>
   <version>${java.cas.client.version}</version>
</dependency>

Gradle:

dependencies {
    ...
    implementation 'org.apereo.cas.client:cas-client-support-springboot:${java.cas.client.version}'
    ...
}

• Add the following required properties in Spring Boot's application.properties or application.yml:

cas.server-url-prefix=https://cashost.com/cas
cas.server-login-url=https://cashost.com/cas/login
cas.client-host-url=https://casclient.com

• Annotate Spring Boot application (or any @Configuration class) with @EnableCasClient annotation

@SpringBootApplication
@Controller
@EnableCasClient
public class MyApplication { .. }

For CAS3 protocol (authentication and validation filters) - which is default if nothing is specified

cas.validation-type=CAS3

For CAS2 protocol (authentication and validation filters)

cas.validation-type=CAS

For SAML protocol (authentication and validation filters)

cas.validation-type=SAML

Available optional properties

• cas.single-logout.enabled
• cas.authentication-url-patterns
• cas.validation-url-patterns
• cas.request-wrapper-url-patterns
• cas.assertion-thread-local-url-patterns
• cas.gateway
• cas.use-session
• cas.attribute-authorities
• cas.redirect-after-validation
• cas.allowed-proxy-chains
• cas.proxy-callback-url
• cas.proxy-receptor-url
• cas.accept-any-proxy
• server.context-parameters.renew

Spring Security Integration

An application that is handling security concerns via Spring Security can take advantage of this module to automatically populate the Spring Security authentication context with roles and authorities that are fetched as attributes from the CAS assertion.

To do so, the attributes names (i.e. membership) from the CAS assertion that should be translated to Spring Security authorities must be specified in the configuration:

cas.attribute-authorities=membership

The application may then enforce role-based security via:

@SpringBootApplication
@EnableCasClient
public class MyConfiguration extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
            .antMatchers("/").permitAll()
            .antMatchers("/protected-endpoint").hasAuthority("ADMIN")
            .anyRequest().authenticated();
    }
}

The translation between CAS attributes and Spring Security authorities and/or roles can be customized using the following bean definition:

@Bean
public AuthenticationUserDetailsService<CasAssertionAuthenticationToken> springSecurityCasUserDetailsService() {
    return null;
}

Advanced configuration

This module does not expose ALL the CAS client configuration options via standard Spring property sources, but only most commonly used ones. If there is a need however, to set any number of not exposed, 'exotic' properties, you can implement the CasClientConfigurer class in your @EnableCasClient annotated class and override appropriate configuration method(s) for CAS client filter(s) in question. For example:

@SpringBootApplication
@EnableCasClient
class CasProtectedApplication implements CasClientConfigurer {    
    @Override
    void configureValidationFilter(FilterRegistrationBean validationFilter) {           
        validationFilter.getInitParameters().put("millisBetweenCleanUps", "120000");
    }        
    @Override
    void configureAuthenticationFilter(FilterRegistrationBean authenticationFilter) {
        authenticationFilter.getInitParameters().put("artifactParameterName", "casTicket");
        authenticationFilter.getInitParameters().put("serviceParameterName", "targetService");
    }                                
}

Configuring Single Sign Out

The Single Sign Out support in CAS consists of configuring one SingleSignOutFilter and one ContextListener. Please note that if you have configured the CAS Client for Java as Web filters, this filter must come before the other filters as described.

The SingleSignOutFilter can affect character encoding. This becomes most obvious when used in conjunction with applications such as Atlassian Confluence. It's recommended you explicitly configure either the VT Character Encoding Filter or the Spring Character Encoding Filter with explicit encodings.

Configuration

CAS Protocol

<filter>
   <filter-name>CAS Single Sign Out Filter</filter-name>
   <filter-class>org.apereo.cas.client.session.SingleSignOutFilter</filter-class>
</filter>
...
<filter-mapping>
   <filter-name>CAS Single Sign Out Filter</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>
...
<listener>
    <listener-class>org.apereo.cas.client.session.SingleSignOutHttpSessionListener</listener-class>
</listener>

SAML Protocol

<filter>
   <filter-name>CAS Single Sign Out Filter</filter-name>
   <filter-class>org.apereo.cas.client.session.SingleSignOutFilter</filter-class>
   <init-param>
      <param-name>artifactParameterName</param-name>
      <param-value>SAMLart</param-value>
   </init-param>
</filter>
...
<filter-mapping>
   <filter-name>CAS Single Sign Out Filter</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>
...
<listener>
    <listener-class>org.apereo.cas.client.session.SingleSignOutHttpSessionListener</listener-class>
</listener>

Recommend Logout Procedure

The client has no code to help you handle log out. The client merely places objects in session. Therefore, we recommend you do a session.invalidate() call when you log a user out. However, that's entirely your application's responsibility. We recommend that text similar to the following appear when the application's session is ended.

You have been logged out of [APPLICATION NAME GOES HERE].
To log out of all applications, click here. (provide link to CAS server's logout)

JAAS

The client supports the Java Authentication and Authorization Service (JAAS) framework, which provides authn facilities to CAS-enabled JEE applications.

A general JAAS authentication module, CasLoginModule, is available with the specific purpose of providing authentication and authorization services to CAS-enabled JEE applications. The design of the module is simple: given a service URL and a service ticket in a NameCallback and PasswordCallback, respectively, the module contacts the CAS server and attempts to validate the ticket. In keeping with CAS integration for Java applications, a JEE container-specific servlet filter is needed to protect JEE Web applications. The JAAS support should be extensible to any JEE container.

Configure CasLoginModule

It is expected that for JEE applications both authentication and authorization services will be required for CAS integration. The following JAAS module configuration file excerpt demonstrates how to leverage SAML 1.1 attribute release in CAS to provide authorization data in addition to authentication:

cas {
  jaas.org.apereo.cas.client.CasLoginModule required
    ticketValidatorClass="org.apereo.cas.client.validation.Saml11TicketValidator"
    casServerUrlPrefix="https://cas.example.com/cas"
    tolerance="20000"
    service="https://webapp.example.com/webapp"
    defaultRoles="admin,operator"
    roleAttributeNames="memberOf,eduPersonAffiliation"
    principalGroupName="CallerPrincipal"
    roleGroupName="Roles"
    cacheAssertions="true"
    cacheTimeout="480";
}

Programmatic JAAS login using the Servlet 3

A jaas.org.apereo.cas.client.Servlet3AuthenticationFilter servlet filter that performs a programmatic JAAS login using the Servlet 3.0 HttpServletRequest#login() facility. This component should be compatible with any servlet container that supports the Servlet 3.0/JEE6 specification.

The filter executes when it receives a CAS ticket and expects the CasLoginModule JAAS module to perform the CAS ticket validation in order to produce an AssertionPrincipal from which the CAS assertion is obtained and inserted into the session to enable SSO.

If a service init-param is specified for this filter, it supersedes the service defined for the CasLoginModule.