CAS server is using a special cookie CASTGC, which is useful for SSO scenarios with more Service applications. For example, you have a single CAS server and two eXo Platform servers configured to use it (in which eXo Platform instances are marked as accounts and services). So if your login is against CAS server with accounts of eXo Platform instance, you do not need to authenticate again when you access CAS with services of eXo Platform instance. You will be auto-authenticated when clicking Sign in on the services instance. This is real SSO and works thanks to CASTGC cookie, which automatically creates a new ticket for services instance if it recognizes that user is already authenticated.
However, the CASTGC cookie is secured by default (available only from https connections). So to make it work, you have 2 possibilities:
Use the https protocol to access your CAS server. This will ensure that the secure CASTGC cookie can be viewable by browsers. This is a recommended approach for production environment. See here for more details.
The easier workaround (but not recommended in production environment) is to switch the CASTGC cookie to be non-secure
(for example, the cookie will not require secure access through https but can be accessed from http as well).
To achieve this, you need to make configuration in the CAS side in the
and switch the cookieSecure attribute to false.
Configuration of the cookie generator in this file should look like this: