CAS integration

The CAS module allows to integrate GeoServer with the Central Authentication Service (CAS) Single Sign On (SSO), in particular, using standard tickets and proxy tickets.


To install the CAS module:

  1. Visit the website download page, locate your release, and download:

    The download link will be in the Extensions section under Security.


    Ensure to match plugin (example 2.24-SNAPSHOT above) version to the version of the GeoServer instance.

  1. Extract the files in this archive to the WEB-INF/lib directory of your GeoServer installation.

  2. Restart GeoServer


The CAS integration is a authentication filter module, hence in order to use it one has to:

  • Go to the authentication page, add the CAS filter and configure it

  • Add it to the authentication chains, taking care of removing the other authentication methods (or the CAS authentication won’t trigger and redirect users to the CAS login page)

This page serves as a reference for configuration options, but a step by step tutorial is also available, see Authentication with CAS.





Name of the filter

CAS server URL including context root

The CAS server location (GeoServer will redirect to it, for example, in order to login, adding the necessary extra path elements)

No single sign on

If checkecd, will send the “renew=true” options to the CAS server, forcing the user to login on the server at each request (unless session creation is allowed)

Participate in single sign out

Whether GeoServer should receive and handle callbacks for Single Sign Out.

URL in CAS loutput page

CAS logout page location

Proxy callback URL

The URL CAS will call back to after proxy ticket authentication

Role source

A choice of role sources for the user authenticated via CAS

Specifically for the role source, the following options are available:



User group service

Locate the user in a the specified user group service, extract the roles from it.

Role service

Locate user roles from the specified role service

Header attribute

Look up the roles in the specified HTTP header of the CAS response

Custom CAS attribute

Extract the roles from a CAS custom attribute in the <cas:serviceResponse> received from the server. The attributes must be configured, on the CAS side, via an attribute repository, and then released for publication in service configuration.

Example CAS configuration

In order to use the CAS custom attributes the server must be configured to extract the attributes from a given attribute repository, and then allow their release in the GeoServer service configuration.

For example, the following file sets up a JDBC user source, as well as JDBC attribute repository (this configuration file might useful for testing purposes, but not setup for production):
# cas.authn.accept.users=

cas.authn.jdbc.query[0].sql=SELECT * FROM users WHERE email = ?

cas.authn.attributeRepository.jdbc[0].sql=SELECT * FROM roles WHERE {0}


The database has the following two tables for users and roles:

CREATE TABLE public.users (
    id bigint NOT NULL,
    disabled boolean,
    email character varying(40),
    first_name character varying(40),
    last_name character varying(40),
    expired boolean,
    password character varying(100)

CREATE TABLE public.roles (
    email character varying,
    attribute character varying,
    value character varying

A sample service configuration for GeoServer might look as follows (again, setup for testing and development only):

  "@class" : "",
  "serviceId" : "^http(s)?://localhost:[\\d]+/geoserver/.*",
  "name" : "GeoServer",
  "id" : 1002,
  "logoutType" : "BACK_CHANNEL",
  "logoutUrl" : "https://localhost:8442/geoserver",
  "redirectUrl" : "https://localhost:8442/geoserver",
  "proxyPolicy" : {
    "@class" : "",
    "pattern" : "^http(s)?://localhost:[\\d]+/geoserver/.*"
  "attributeReleasePolicy" : {
    "@class" : ""

Configuring the web chain

The CAS authentication can be included in the web filter chain, with different behavior depending on which filters are included. The following discusses three possible examples.

As first case, let’s consider having only the CAS authentication in the “web” filter chain:


Since anonymous access is not allowed, any attempt to access the GeoServer web console will cause a redirect to the CAS server, for login. Once logged in, the user interface shows a button to initiate a CAS logout (the logout is shared among all examples, won’t be repeated in the following text).


A second option is to allow anonymous access in the web chain, allowing users to access the layer preview and other demo functionality without logging in:


In this case the web console does not immediately redirect to the CAS server, but provides a CAS login button instead:


As a final example, let’s consider having both CAS and form login in the web chain:


This allows both a CAS login, and a form based login using GeoServer local username/password. It could be useful to allow GeoServer administration while the CAS server is offline for any reason. In this case both the form login and the CAS login button appear at the same time: