Apereo Community Blog

OpenID Federation with pac4j and CAS

Tue, 01 Sep 2026 00:00:00 +0000

As CAS v8.1.0 will support the three roles of the OpenID federation protocol: trust anchor, intermediate and OP, this is the perfect opportunity to present a live demo.

The setup consists of three components:

a client, referred to as the Relying Party (RP) in OIDC, implemented with pac4j
a server, referred to as the OpenID Provider (OP) in OIDC, implemented with the CAS server
a Trust Anchor (TA), also implemented with the CAS server, responsible for establishing trust between the other two components.

Although we use the CAS server for the OP and the TA, we can’t use a single CAS node: we have two separate nodes of the CAS server, each supporting an exclusive role.

The following URLs are used:

the OP runs on http://localhost:8080/cas
the RP runs on http://localhost:8081
the TA runs on http://localhost:8082/cas.

For the CAS server nodes, we use this basic Maven overlay: https://github.com/casinthecloud/cas-overlay-demo.

Both our CAS servers have a similar pom.xml file:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.casinthecloud</groupId>
    <artifactId>cas-overlay-demo</artifactId>
    <version>8.1.0-SNAPSHOT</version>
    <packaging>war</packaging>

    <dependencies>
        <dependency>
            <groupId>org.apereo.cas</groupId>
            <artifactId>cas-server-webapp${tomcat.properties}</artifactId>
            <version>${cas.version}</version>
            <type>war</type>
            <scope>runtime</scope>
        </dependency>

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

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-war-plugin</artifactId>
                <version>3.3.1</version>
                <configuration>
                    <failOnMissingWebXml>false</failOnMissingWebXml>
                    <recompressZippedFiles>false</recompressZippedFiles>
                    <archive>
                        <compress>false</compress>
                        <manifestFile>${project.build.directory}/war/work/org.apereo.cas/cas-server-webapp${tomcat.properties}/META-INF/MANIFEST.MF</manifestFile>
                    </archive>
                    <overlays>
                        <overlay>
                            <groupId>org.apereo.cas</groupId>
                            <artifactId>cas-server-webapp${tomcat.properties}</artifactId>
                        </overlay>
                    </overlays>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <release>${java.version}</release>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <version>4.2.0-M1</version>
                <configuration>
                    <mainClass>org.apereo.cas.web.CasWebApplication</mainClass>
                    <excludes>
                        <exclude>
                            <groupId>org.apereo.cas</groupId>
                            <artifactId>cas-server-webapp-tomcat</artifactId>
                        </exclude>
                    </excludes>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>repackage</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
        <finalName>cas</finalName>
    </build>

    <properties>
        <cas.version>8.1.0-RC1</cas.version>
        <java.version>25</java.version>
        <tomcat.properties>-tomcat</tomcat.properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

</project>

The OP has one more CAS dependency though (compared to the TA):

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

And the configuration specific to each server changes.

For the pac4j application, we use this simple demo: https://github.com/pac4j/simple-spring-boot-pac4j-demos/tree/oidc/src/main/java/org/pac4j/demos.

1) Setup a CAS server as the OP

In the application.yml file, let’s set up the CAS server to act as the trust anchor:

server.ssl.enabled: false
server.port: 8080

cas.tgc.secure: false
cas.tgc.same-site-policy: Lax

cas.tgc.crypto.enabled: false
cas.webflow.crypto.enabled: false

cas.server.name: http://localhost:${server.port}
cas.server.prefix: ${cas.server.name}/cas
cas.host.name: casop

cas.authn.oidc.jwks.file-system.jwks-file: file:./metadata/oidc.jwks
cas.authn.oidc.federation.role: OPENID_PROVIDER
cas.authn.oidc.federation.jwks-file: file:./metadata/federation.jwks
cas.authn.oidc.federation.authority-hints:
  - http://localhost:8082/cas/oidc
cas.authn.oidc.core.issuer: ${cas.server.prefix}/oidc

The configuration is quite easy: we set up the CAS server to run on http://localhost:8080/cas (no SSL, Lax policy, no cookie/webflow encryption, this is for development only).

For OIDC, we define its OIDC base URL (issuer) and its JWKS (./metadata/oidc.jwks).

And for the federation part, we set the OPENID_PROVIDER role, the specific JWKS (./metadata/federation.jwks) and the trust anchor:

cas.authn.oidc.federation.authority-hints:
  - http://localhost:8082/cas/oidc

2) Setup the pac4j application as the RP

In the pac4j ecosystem, Spring Boot is the most popular web stack, so we use the spring-webmvc-pac4j implementation in this simple demo: https://github.com/pac4j/simple-spring-boot-pac4j-demos/tree/oidc/src/main/java/org/pac4j/demos:

the SpringBootDemo class runs the Spring Boot demo
the SecurityConfig class defines the security configuration (OIDC + URL protection)
the Application class is a simple controller with two URLs: one public and the other one protected.

a) Dependencies

We need the following dependencies:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.pac4j</groupId>
    <artifactId>spring-webmvc-pac4j</artifactId>
    <version>8.0.3</version>
</dependency>
<dependency>
    <groupId>org.pac4j</groupId>
    <artifactId>pac4j-oidc</artifactId>
    <version>6.5.6</version>
</dependency>

b) Properties

We run it on port 8081 thanks to the application.properties file:

server.port=8081
app.base-url=http://localhost:8081

c) `SecurityConfig` class

We update the SecurityConfig class to change the configuration for the federation:

package org.pac4j.demos;

import com.nimbusds.jose.JWSAlgorithm;
import com.nimbusds.oauth2.sdk.auth.ClientAuthenticationMethod;
import org.pac4j.core.config.Config;
import org.pac4j.oidc.client.OidcClient;
import org.pac4j.oidc.config.OidcConfiguration;
import org.pac4j.oidc.config.method.PrivateKeyJwtClientAuthnMethodConfig;
import org.pac4j.oidc.federation.config.OidcTrustAnchorProperties;
import org.pac4j.springframework.config.Pac4jSecurityConfig;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.InterceptorRegistry;

import java.util.List;

@Configuration
public class SecurityConfig extends Pac4jSecurityConfig {

    @Value("${app.base-url:http://localhost:8080}")
    private String baseUri;

    @Bean
    public Config config() {
        final var config = new OidcConfiguration();
        config.setAllowUnsignedIdTokens(true);

        final var rpJwks = config.getRpJwks();
        rpJwks.setJwksPath("file:./metadata/rpjwks.jwks");
        rpJwks.setKid("defaultjwks26");
        config.setClientAuthenticationMethod(ClientAuthenticationMethod.PRIVATE_KEY_JWT);
        final var privateKeyJwtConfig = new PrivateKeyJwtClientAuthnMethodConfig(rpJwks);
        config.setPrivateKeyJWTClientAuthnMethodConfig(privateKeyJwtConfig);

        config.setRequestObjectSigningAlgorithm(JWSAlgorithm.RS256);

        final var federation = config.getFederation();

        federation.setTargetOp("http://localhost:8080/cas/oidc");
        final var trust = new OidcTrustAnchorProperties();
        trust.setIssuer("http://localhost:8082/cas/oidc");
        trust.setJwksPath("classpath:trustanchor.jwks");
        federation.getTrustAnchors().add(trust);

        federation.getJwks().setJwksPath("file:./metadata/oidcfede.jwks");
        federation.getJwks().setKid("mykeyoidcfede26");
        federation.setContactName("RP with CAS");
        federation.setContactEmails(List.of("jerome@casinthecloud.com"));

        federation.setEntityId("http://localhost:8081");

        return new Config(baseUri + "/callback", new OidcClient(config));
    }

    @Override
    public void addInterceptors(final InterceptorRegistry registry) {
        addSecurity(registry, "OidcClient").addPathPatterns("/protected/**");
    }
}

The configuration is more complicated here.

We define a global JWKS for the RP that is also used for the private_key_jwt authentication method:

    final var rpJwks = config.getRpJwks();
    rpJwks.setJwksPath("file:./metadata/rpjwks.jwks");
    rpJwks.setKid("defaultjwks26");
    config.setClientAuthenticationMethod(ClientAuthenticationMethod.PRIVATE_KEY_JWT);
    final var privateKeyJwtConfig = new PrivateKeyJwtClientAuthnMethodConfig(rpJwks);
    config.setPrivateKeyJWTClientAuthnMethodConfig(privateKeyJwtConfig);

For federation, we use:

    config.setRequestObjectSigningAlgorithm(JWSAlgorithm.RS256);

    final var federation = config.getFederation();

    federation.setTargetOp("http://localhost:8080/cas/oidc");
    final var trust = new OidcTrustAnchorProperties();
    trust.setIssuer("http://localhost:8082/cas/oidc");
    trust.setJwksPath("classpath:trustanchor.jwks");
    federation.getTrustAnchors().add(trust);

The target OP is of course the CAS server acting as an OP.

For the trust anchor, it’s the other CAS node (on port 8082) for which we retrieve the JWKS from http://localhost:8082/cas/oidc/.well-known/openid-federation and save it in the trustanchor.jwks file.

Example:

{
    "keys": [
        {
            "kty": "RSA",
            "e": "AQAB",
            "use": "sig",
            "kid": "19f7aaaa-c4d3-4c26-a26e-3ce4b8ab1beb",
            "n": "uXgnb...SEdSw"
        }
    ]
}

We also have a specific JWKS configuration dedicated to federation (displayed on the .well-known/openid-federation endpoint):

    federation.getJwks().setJwksPath("file:./metadata/oidcfede.jwks");
    federation.getJwks().setKid("mykeyoidcfede26");
    federation.setContactName("RP with CAS");
    federation.setContactEmails(List.of("jerome@casinthecloud.com"));

    federation.setEntityId("http://localhost:8081");

d) `Application` class

We also need to update the Application class to add the mapping for the OpenID federation endpoint:

@Controller
public class Application {

    @Autowired
    private Config config;

    @RequestMapping(value = "/.well-known/openid-federation", produces = DefaultEntityConfigurationGenerator.CONTENT_TYPE)
    @ResponseBody
    public String oidcFederation() throws HttpAction {
        final var oidcClient = (OidcClient) config.getClients().findClient("OidcClient").get();
        return oidcClient.getConfiguration().getFederation().getEntityConfigurationGenerator().generateEntityStatement();
    }

    ...
}

3) Setup a CAS server as the trust anchor

In the application.yml file, let’s set up the CAS server as the trust anchor this time:

server.ssl.enabled: false
server.port: 8082

cas.tgc.secure: false
cas.tgc.same-site-policy: Lax

cas.tgc.crypto.enabled: false
cas.webflow.crypto.enabled: false

cas.server.name: http://localhost:${server.port}
cas.server.prefix: ${cas.server.name}/cas
cas.host.name: casta

cas.authn.oidc.federation.role: TRUST_ANCHOR
cas.authn.oidc.federation.jwks-file: file:./metadata/trustanchor.jwks
cas.authn.oidc.core.issuer: ${cas.server.prefix}/oidc
cas.authn.oidc.federation.subordinate-directory: ./subordinates

The configuration is close to that of the other CAS node, except that we define the TRUST_ANCHOR role as well as the file directory in which we will define its subordinates.

The subordinates are the entities for which the CAS server provides trust. They must be defined upfront with their metadata and their federation key(s).

Here, it will be the RP (the pac4j client, Spring Boot demo) and the OP (the other CAS server).

For the RP (pac4j), we call the URL: http://localhost:8081/.well-known/openid-federation. An entity statement is returned by the Spring Boot demo and we can decode it via any JWT tool or the jwt.io website.

The metadata and the keys from the jwks property (not in the metadata property) are the ones we use to build the subordinate rp.json file (placed in the ./subordinates directory):

{
    "entityId": "http://localhost:8081",
    "metadata": {
        "openid_relying_party": {
            "redirect_uris": [
                "http://localhost:8081/callback?client_name=OidcClient"
            ],
            "application_type": "web",
            "response_types": [
                "code"
            ],
            "grant_types": [
                "authorization_code"
            ],
            "scope": "openid email profile",
            "token_endpoint_auth_method": "private_key_jwt",
            "token_endpoint_auth_signing_alg": "RS256",
            "request_object_signing_alg": "RS256",
            "jwks": {
                "keys": [
                    {
                        "kty": "RSA",
                        "e": "AQAB",
                        "use": "sig",
                        "kid": "defaultjwks26",
                        "n": "v-zf7...G2tyw"
                    }
                ]
            },
            "client_registration_types": [
                "explicit",
                "automatic"
            ],
            "client_name": "RP with CAS",
            "contacts": [
                "jerome@casinthecloud.com"
            ]
        }
    },
    "federationKeys": [
        {
            "kty": "RSA",
            "e": "AQAB",
            "use": "sig",
            "kid": "mykeyoidcfede26",
            "n": "uaov...EpbZQ"
        }
    ]
}

For the OP (CAS server), we do something similar and call the URL: http://localhost:8080/cas/oidc/.well-known/openid-federation to get the metadata and the federation keys and create the op.json file (in the ./subordinates directory).

{
    "entityId": "http://localhost:8080/cas/oidc",
    "metadata": {
        "openid_provider": {
            "DPopSigningAlgValuesSupported": [
                "RS256",
                "RS384",
                "RS512",
                "ES256",
                "ES384",
                "ES512"
            ],
            "request_parameter_supported": true,
            "pushed_authorization_request_endpoint": "http://localhost:8080/cas/oidc/oidcPushAuthorize",
            "introspection_signing_alg_values_supported": [
                "none",
                "RS256",
                "RS384",
                "RS512",
                "PS256",
                "PS384",
                "PS512",
                "ES256",
                "ES384",
                "ES512",
                "HS256",
                "HS384",
                "HS512"
            ],

            ...[TRUNCATED]...

            "registration_endpoint": "http://localhost:8080/cas/oidc/register",
            "request_object_signing_alg_values_supported": [
                "none",
                "RS256",
                "RS384",
                "RS512",
                "PS256",
                "PS384",
                "PS512",
                "ES256",
                "ES384",
                "ES512",
                "HS256",
                "HS384",
                "HS512"
            ],
            "request_object_encryption_alg_values_supported": [
                "RSA1_5",
                "RSA-OAEP",
                "RSA-OAEP-256",
                "A128KW",
                "A192KW",
                "A256KW",
                "A128GCMKW",
                "A192GCMKW",
                "A256GCMKW",
                "ECDH-ES",
                "ECDH-ES+A128KW",
                "ECDH-ES+A192KW",
                "ECDH-ES+A256KW"
            ]
        },
        "federation_entity": {
            "organization_name": "Apereo CAS",
            "contacts": []
        }
    },
    "federationKeys": [
        {
            "kty": "RSA",
            "e": "AQAB",
            "use": "sig",
            "kid": "0bf6c36e-1cba-41d3-a50e-a11881fd85e7",
            "n": "xoP5Q...3EkRw"
        }
    ]
}

4) Final test

With the RP, OP and TA started, we call http://localhost:8081 in the browser:

Then, we click on the “Protected area” link.

On the CAS server login page, we use the pre-defined user: casuser / Mellon to log in:

and we validate the authorizations:

And it works:

We are finally logged in to the pac4j application thanks to the OpenID Federation protocol and the two CAS server nodes.

So the CAS server can now act as a federated OP and as a trust anchor with the pac4j RP client.

Jerome LELEU

CAS Vulnerability Disclosure

Tue, 25 Aug 2026 00:00:00 +0000

Overview

This is an Apereo CAS project vulnerability disclosure, which describes a security vulnerability that mainly affects how the CAS server operates as an OAuth or OpenID Connect identity provider.

For additional details on how security issues, patches and announcements are handled, please read the Apereo CAS project vulnerability disclosure process.

Affected Deployments

The problem addressed here, per the CAS maintenance policy, affects the Apereo CAS server for the following versions:

- 7.3.x
- 8.0.x

If your CAS version is not listed above AND is still part of an active maintenance cycle per the CAS maintenance policy, then best effort (analysis or confirmation from reporters/testers) indicates that the version is not affected by this issue. That said, please note that per the project’s Apache2 license, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. For additional information, please see the project license.

If you are (or your institution is) a member of the Apereo foundation with an active support subscription supporting the CAS project, please contact the CAS subs working group to learn more about this security vulnerability report.

Exposure

You are affected if your CAS deployment qualifies for ANY of the following conditions:

CAS is configured to act as an OAuth identity provider.
…or, CAS is configured to act as an OpenID Connect identity provider.

There are also changes in place to protect against a few other variations of this issue. These fixes apply to the CAS server as a whole and are not connected to a particular feature or extension module.

Finally the 8.0.x security patch release, described below, also presents small and yet important changes to strengthen delegated authentication requests particularly for external SAML2 and OpenID Connect identity providers. For 7.3.x deployments that use delegated authentication features routing requests to external SAML2 and OpenID Connect identity providers, the recommendation is to upgrade to the 8.0.x line to benefit from these security fixes.

The fixes mainly cover the following areas:

Carry-over from here to fix a few more affected areas: A request parameter whose name equals the FQCN of the internal service attribute key org.apereo.cas.authentication.principal.Service overrides the CAS response target after login. CAS issues the Service Ticket (ST) for the legitimate registered service, but redirects the victim to the attacker-controlled URL with the ST appended.
CAS corrected an issue where percent-encoded OAuth and OpenID Connect endpoint paths could be interpreted differently by request routing and security filters. For example, an encoded character in an endpoint name could cause CAS to route the request normally while an access-control or throttling filter failed to recognize the endpoint. In affected configurations, this could bypass protections for endpoints such as (but not limited to) OIDC dynamic client registration and client configuration retrieval, potentially allowing unauthorized registration or disclosure of client information. The fix normalizes percent-encoded request paths before applying OAuth/OIDC security and throttling rules. Regression tests now cover all relevant OAuth and OIDC endpoints.

Timeline & Credits

The issues were originally reported to the CAS project on August 23rd, 2026 and fixed on August 24th, 2026. The issues were reported to the project by third-parties researchers and adopters and were then further validated and tested by Mr. Jérôme Leleu, who is a long-time project member and an active committer.

Thank you everyone!

Patching

Patch releases were published on August 25th, 2026. Upgrades to the next patch version for each release should be a drop-in replacement.

Drop-in Replacement?
For the most part, a drop-in replacement release (as is the case for almost all security patch releases) does not require you to change platform requirements, Java versions, application registration records, user interface, CAS configuration, logging semantics, etc. For most deployments, this should be closer to “upgrade and verify” than “cancel your weekend.”, unless explicitly (and uncommonly) noted otherwise.

The only serious exception to this rule would be in scenarios where you have modified Java code and CAS server internal components and your changes directly overwrite upstream's fixes. While we do our best to ensure fixes are non-intrusive with a low footprint as much as possible, we cannot guarantee that your custom Java components that entirely overwrite and overlay on top of CAS remain fully functional or compatible with CAS APIs and implementations. The risk with owning code is that you own the code. Review and assess carefully.

Versions

Forward Ports
Any CAS version that is still in development and considered a work-in-progress automatically receives any and all fixes. All changes are expected to be carried forward and released in due time.

7.3.x

Modify your CAS overlay to point to the version 7.3.8.2.

8.0.x

Modify your CAS overlay to point to the version 8.0.1.2.

How to upgrade

Locate your gradle.properties file in your CAS overlay, found at the root of the project.
Modify your CAS version to point to the appropriate release version noted above by updating the cas.version property.
Follow the instructions in the README.md file to build the server, i.e. ./gradlew[.bat] clean build.

Security In The AI Era

We are beginning to see a clear trend in how security issues are researched and reported: AI is playing a much larger role in analyzing, documenting, explaining, and submitting potential vulnerability reports. This is not unique to CAS. It is happening across open source. The same productivity gains that AI gives developers and maintainers are also changing how code is reviewed, assessed, challenged, and patched. As this article puts it:

It’s one thing for a development team of 4-10 engineers to use generative AI to build new features faster. It’s a whole other situation when, for each engineer on the team, there are dozens in our community using generative AI to create issues, pull requests, and security reports.

AI did not just learn to write code. It also learned to open security reports, explain them confidently, attach a proof of concept, and then politely ask why nobody has fixed it yet! This trend is likely to accelerate. With that in mind, we would like to highlight two practical points:

Maintainer capacity is a real constraint. Human resources and available maintainer time matter a great deal here. It is very likely that time-to-fix expectations will need to stretch, not just for CAS but for many open source projects. If the volume of security reports becomes difficult to manage, our response may be slower than usual. There are only a few of us, and many of you, them, and possibly a small army of extremely confident, polite autocomplete machines. Please set expectations accordingly, and review the vulnerability response process to understand how reports are handled and what commitments, if any, can realistically be made.
Automated verification and deployment are no longer optional luxuries. It is becoming increasingly important for adopters of open source projects, especially CAS, to invest in tooling and processes that support automated release verification, automated integration testing, reliable CI/CD pipelines, and fast production deployment. If your current deployment process depends on manual steps, delayed approvals, synchronous coordination, or one heroic person remembering the exact production checklist from 2019, you may start to feel the pain. As security fixes and patches appear more frequently, teams with slow or manual deployment practices will have a harder time consuming updates quickly and safely.

Support

Apereo CAS is Apache v2 open source software under the sponsorship of the Apereo Foundation. Support options may be found here.

If you or your institution is a member of the Apereo foundation with an active CAS subscription supporting the CAS project, please contact the CAS subs working group to learn more about this security vulnerability.

Resources

On behalf of the CAS Application Security working group,

Misagh Moayyed

CAS Vulnerability Disclosure

Tue, 18 Aug 2026 00:00:00 +0000

Overview

This is an Apereo CAS project vulnerability disclosure, which describes a security vulnerability that affects how the CAS server manages application authentication requests.

For additional details on how security issues, patches and announcements are handled, please read the Apereo CAS project vulnerability disclosure process.

Affected Deployments

The problem addressed here, per the CAS maintenance policy, affects the Apereo CAS server for the following versions:

- 7.3.x
- 8.0.x

Exposure

The issue is not tied to a specific feature of the CAS software and is an Open Redirect type of vulnerability. You are affected by this security vulnerability if you simply run CAS.

A request parameter whose name equals the FQCN of the internal service attribute key org.apereo.cas.authentication.principal.Service overrides the CAS response target after login. CAS issues the Service Ticket (ST) for the legitimate registered service, but redirects the victim to the attacker-controlled URL with the ST appended.

Timeline & Credits

The issue was originally reported to the CAS project on August 16th, 2026 and fixed on August 17th, 2026. The reporter decided to remain anonymous. Thank you anyway!

Patching

Patch releases were published on August 17th, 2026. Upgrades to the next patch version for each release should be a drop-in replacement.

Versions

7.3.x

Modify your CAS overlay to point to the version 7.3.8.1.

8.0.x

Modify your CAS overlay to point to the version 8.0.1.1.

How to upgrade

Locate your gradle.properties file in your CAS overlay, found at the root of the project.
Modify your CAS version to point to the appropriate release version noted above by updating the cas.version property.
Follow the instructions in the README.md file to build the server, i.e. ./gradlew[.bat] clean build.

Security In The AI Era

It’s one thing for a development team of 4-10 engineers to use generative AI to build new features faster. It’s a whole other situation when, for each engineer on the team, there are dozens in our community using generative AI to create issues, pull requests, and security reports.

Maintainer capacity is a real constraint. Human resources and available maintainer time matter a great deal here. It is very likely that time-to-fix expectations will need to stretch, not just for CAS but for many open source projects. If the volume of security reports becomes difficult to manage, our response may be slower than usual. There are only a few of us, and many of you, them, and possibly a small army of extremely confident, polite autocomplete machines. Please set expectations accordingly, and review the vulnerability response process to understand how reports are handled and what commitments, if any, can realistically be made.
Automated verification and deployment are no longer optional luxuries. It is becoming increasingly important for adopters of open source projects, especially CAS, to invest in tooling and processes that support automated release verification, automated integration testing, reliable CI/CD pipelines, and fast production deployment. If your current deployment process depends on manual steps, delayed approvals, synchronous coordination, or one heroic person remembering the exact production checklist from 2019, you may start to feel the pain. As security fixes and patches appear more frequently, teams with slow or manual deployment practices will have a harder time consuming updates quickly and safely.

Support

Apereo CAS is Apache v2 open source software under the sponsorship of the Apereo Foundation. Support options may be found here.

Resources

On behalf of the CAS Application Security working group,

Misagh Moayyed

Changes to CAS Security Vulnerability Response

Tue, 23 Jun 2026 00:00:00 +0000

TL;DR

The Apereo CAS project has approved a proposal to shorten our security grace window from four weeks to two weeks.

Going forward, security fixes will follow a two-week grace period before broader public disclosure and announcement. This change reflects both the current pace of software delivery and the evolving security landscape in which fixes, diffs, source artifacts, and public hints can be analyzed far more quickly than in the past.

Why the Change?

The previous four-week window was established at a time when many organizations still relied heavily on manual build, release, and deployment processes. It was intended to give adopters a reasonable amount of time to upgrade before security issues were more widely announced.

That environment has changed significantly. Today, automated builds, dependency management tools, CI/CD pipelines, containerized deployments, and release automation are far more common. At the same time, security reports are arriving more frequently, and AI-assisted analysis has shortened the time between a fix being published and the underlying vulnerability being understood. In practice, this means the effective secrecy window around a security fix is much shorter than it used to be. Once a fix is available, motivated observers can often infer the nature of the issue without a lot of hassle.

Given that reality, maintaining a four-week delay before wider disclosure no longer provides the same level of protection it once did.

What Is Changing?

For future security fixes, the grace window will be shortened from 4 weeks to 2 weeks. This means adopters will have two weeks after a security fix is published before broader public disclosure and announcement. The project documentation has been updated to reflect the new two-week security grace window.

What Is Not Changing?

This change does not affect security fixes that have already been published. Any security fix already operating under the previous four-week window will continue to follow that original timeline. The new two-week window applies only to future security fixes.

Expectations for Adopters

We recognize that this change means organizations will need to respond more quickly to security releases. However, this is also an intentional nudge toward more automated, repeatable, and reliable upgrade processes. Projects and organizations that still depend on manual upgrade and deployment steps should use this change as an opportunity to review their release workflows, dependency management practices, and deployment automation. Today, the ability to apply security updates quickly is no longer just operationally convenient. It is part of maintaining a responsible security posture.

The goal is to strike a better balance between giving adopters time to upgrade and ensuring the wider community receives timely information about security issues. We appreciate the community’s continued attention to responsible disclosure, timely upgrades, and the ongoing security of the ecosystem.

On behalf of the CAS Project,

Misagh Moayyed

CAS Vulnerability Disclosure

Thu, 18 Jun 2026 00:00:00 +0000

Overview

This is an Apereo CAS project vulnerability disclosure, which describes a security vulnerability that affects how the CAS server manages state for authentication flows.

For additional details on how security issues, patches and announcements are handled, please read the Apereo CAS project vulnerability disclosure process.

Affected Deployments

The problem addressed here, per the CAS maintenance policy, affects the Apereo CAS server for the following versions:

- 7.3.x

Exposure

You are affected by this security vulnerability if your CAS deployment manages its state for authentication webflows using the client browser. This is the default setup and configuration for almost all deployments.

A vulnerability in CAS client-side Spring Webflow state encryption caused AES-GCM to reuse a deterministic initialization vector with the same encryption key. This allowed unauthenticated attackers to collect chosen webflow state ciphertexts and recover portions of the encryption keystream. If an attacker obtained another user’s webflow execution token, the recovered keystream could be used to disclose corresponding portions of that user’s serialized webflow state. The issue primarily affects confidentiality of client-side webflow state; integrity remains protected when CAS webflow signing is enabled.

Timeline & Credits

The issue was originally reported to the CAS project on June 16th, 2026 and fixed on June 17th, 2026. The reporter decided to remain anonymous. Thank you anyway!

Patching

Patch releases were published on June 18th, 2026. Upgrades to the next patch version for each release should be a drop-in replacement.

Versions

7.3.x

Modify your CAS overlay to point to the version 7.3.7.3.

How to upgrade

Locate your gradle.properties file in your CAS overlay, found at the root of the project.
Modify your CAS version to point to the appropriate release version noted above by updating the cas.version property.
Follow the instructions in the README.md file to build the server, i.e. ./gradlew[.bat] clean build.

Security In The AI Era

It’s one thing for a development team of 4-10 engineers to use generative AI to build new features faster. It’s a whole other situation when, for each engineer on the team, there are dozens in our community using generative AI to create issues, pull requests, and security reports.

Maintainer capacity is a real constraint. Human resources and available maintainer time matter a great deal here. It is very likely that time-to-fix expectations will need to stretch, not just for CAS but for many open source projects. If the volume of security reports becomes difficult to manage, our response may be slower than usual. There are only a few of us, and many of you, them, and possibly a small army of extremely confident, polite autocomplete machines. Please set expectations accordingly, and review the vulnerability response process to understand how reports are handled and what commitments, if any, can realistically be made.
Automated verification and deployment are no longer optional luxuries. It is becoming increasingly important for adopters of open source projects, especially CAS, to invest in tooling and processes that support automated release verification, automated integration testing, reliable CI/CD pipelines, and fast production deployment. If your current deployment process depends on manual steps, delayed approvals, synchronous coordination, or one heroic person remembering the exact production checklist from 2019, you may start to feel the pain. As security fixes and patches appear more frequently, teams with slow or manual deployment practices will have a harder time consuming updates quickly and safely.

Support

Apereo CAS is Apache v2 open source software under the sponsorship of the Apereo Foundation. Support options may be found here.

Resources

On behalf of the CAS Application Security working group,

Misagh Moayyed

CAS Vulnerability Disclosure

Sat, 06 Jun 2026 00:00:00 +0000

Overview

This is an Apereo CAS project vulnerability disclosure, which describes a series of security vulnerabilities that affect different features and aspects of the CAS server. Additional details will be made public once the security grace window has passed.

For additional details on how security issues, patches and announcements are handled, please read the Apereo CAS project vulnerability disclosure process.

Affected Deployments

The problem addressed here, per the CAS maintenance policy, affects the Apereo CAS server for the following versions:

- 7.3.x

Exposure

You are affected by this security vulnerability IF ANY of the following separate conditions apply to your CAS deployment:

Your CAS server is using Google Authenticator for multifactor authentication and storing user device records in Redis.
Your CAS server is using Redis to store tickets, complemented with a local cache.
Your CAS server is acting as an OpenID Connect identity provider.

These conditions are separate from one another and operate independently. Again, your CAS deployment is considered vulnerable IF ANY of the above conditions are true for your CAS deployment.

THIS IS SERIOUS!
Our initial analysis of issue #3, where CAS acts as an OpenID Connect identity provider in a vulnerable state, indicates that the impact may extend beyond OpenID Connect provider functionality. The issue may affect broader CAS server behavior and could potentially lead to remote code execution.

Even if you do not believe you are affected by any of the above conditions, we VERY STRONGLY recommend that you upgrade anyway.

Timeline & Credits

Issue: Google Authenticator with Redis

The issue was originally reported to the CAS project on May 28th, 2026 and fixed on June 1st, 2026. The reporter declined to be listed in this advisory. Thank you anyway!

Exposure

This issue affects deployments that use a dedicated Redis backend to manage Google Authenticator accounts and scratch codes. When using a scratch code to authenticate, instead of updating the original account and the owner of the scratch code, CAS would instead create a new record for the account with the updated list of scratch codes and thus leaving the original in place as an orphaned account. This meant that the scratch code assigned now to the orphaned account could be used indefinitely to authenticate.

Issue: Redis Ticket Registry

This issue was originally reported to the CAS project on May 30th, 2026 by Georgia Tech’s Enterprise Application and Identity teams and a candidate fix was offered on June 1st, 2026. While final reporter confirmation is still pending, our analysis gives us reasonable confidence that the issue has been addressed. We may iterate further if additional testing identifies gaps. As ever, we appreciate Georgia Tech’s cooperation and willingness to report and verify the fixes.

Exposure

With crypto operations enabled for the Redis ticket registry coupled with a local cache that is backed by Redis messaging, the publisher CAS node would capture the ticket in its local cache using a SHA-512 of the ticket id to publish a message using Redis messaging to other CAS nodes. The receiver nodes would then receive a signal that is composed of the op type (ADD, DELETE, etc) as well as the ticket object itself, when available/relevant. The bug here was that the receiver node attempted to remove the ticket from its own local cache using the plain ticket id as the key; not its SHA-512 equivalent. This of course meant that receiver nodes will end up carrying a cached ticket that is effectively removed from Redis itself, which would then pose a problem for logout operations, specially those that are admin-forced for disabled or compromised accounts.

Issue: OpenID Connect

This issue was originally reported to the CAS project on June 2nd, 2026 by Richard Gašparík, an ethical hacker at Citadelo and was fixed on June 3rd, 2026. Citadelo is a European cybersecurity company that focuses primarily on penetration testing and offensive security, helping organizations across Europe find and fix vulnerabilities before attackers do. We also wish to credit Richard’s colleague, Josef Korbel, who worked on the penetration test with Richard and helped to find the vulnerabilities.

We appreciate Richard’s and Josef’s time and effort who shared complete and thorough instructions on how this vulnerability can be observed and exercised and were able to ultimately verify the fix. Thank you both very much!

CVEs
The Citadelo team has reserved CVEs for this issue. We'll notify them to publish the records and make CVEs public, once the security grace period has passed.

Exposure

Authentication bypass of OIDC dynamic client registration. The authentication interceptor is registered for the OIDC base endpoint plus a single path segment while the registration endpoint also maps a multi-segment wildcard. A request with one extra path segment reaches the registration handler without the required initial access token.
Expression-language injection in jwks_uri or jwks leading to RCE in OIDC dynamic client registration requests. The client-supplied jwks or jwks_uri can be passed as a Spring expression which evaluates using a standard non-sandboxed evaluation context. A registered jwks_uri such as ${T(java.lang.Runtime)...} can execute arbitrary code.

Patching

Patch releases were published on June 5th, 2026. Upgrades to the next patch version for each release should be a drop-in replacement.

Versions

Given the timeline and severity of the reported issues, we decided to publish one security patch release for affected versions per the CAS maintenance policy, rather than individual releases for every fix and issue. This was a rather unusual event where we received multiple security reports all around the same timeframe and one release to rule them all helps us reduce maintenance burden and release churn, as the fixes are quite targeted and surgical.

7.3.x

Modify your CAS overlay to point to the version 7.3.7.2.

How to upgrade

Locate your gradle.properties file in your CAS overlay, found at the root of the project.
Modify your CAS version to point to the appropriate release version noted above by updating the cas.version property.
Follow the instructions in the README.md file to build the server, i.e. ./gradlew[.bat] clean build.

Security In The AI Era

It’s one thing for a development team of 4-10 engineers to use generative AI to build new features faster. It’s a whole other situation when, for each engineer on the team, there are dozens in our community using generative AI to create issues, pull requests, and security reports.

Maintainer capacity is a real constraint. Human resources and available maintainer time matter a great deal here. It is very likely that time-to-fix expectations will need to stretch, not just for CAS but for many open source projects. If the volume of security reports becomes difficult to manage, our response may be slower than usual. There are only a few of us, and many of you, them, and possibly a small army of extremely confident, polite autocomplete machines. Please set expectations accordingly, and review the vulnerability response process to understand how reports are handled and what commitments, if any, can realistically be made.
Automated verification and deployment are no longer optional luxuries. It is becoming increasingly important for adopters of open source projects, especially CAS, to invest in tooling and processes that support automated release verification, automated integration testing, reliable CI/CD pipelines, and fast production deployment. If your current deployment process depends on manual steps, delayed approvals, synchronous coordination, or one heroic person remembering the exact production checklist from 2019, you may start to feel the pain. As security fixes and patches appear more frequently, teams with slow or manual deployment practices will have a harder time consuming updates quickly and safely.

Support

Apereo CAS is Apache v2 open source software under the sponsorship of the Apereo Foundation. Support options may be found here.

Resources

On behalf of the CAS Application Security working group,

Misagh Moayyed

CAS OpenID Connect Vulnerability Disclosure

Wed, 27 May 2026 00:00:00 +0000

Overview

This is an Apereo CAS project vulnerability disclosure, describing an issue in CAS acting and running as an OpenID Connect provider.

For additional details on how security issues, patches and announcements are handled, please read the Apereo CAS project vulnerability disclosure process.

Credits

This issue was originally reported to the team at Coop (Switzerland), namely Artur Stoecklin and David Roth, via the YesWeHack platform, which is a “global crowdsourced security and bug bounty platform that connects organizations with a vetted community of tens of thousands of ethical (white-hat) hackers to identify and report vulnerabilities in websites, mobile apps, and infrastructure”. Both the original reporter as well as the team at YesWeHack shared complete and thorough instructions on how this vulnerability can be observed and exercised. The team at Coop (Switzerland) further validated and tested the fix.

Thank you everyone!

Affected Deployments

The problem addressed here, per the CAS maintenance policy, affects the Apereo CAS server for the following versions:

- 7.3.x

Severity

You are affected by this security vulnerability IF AND ONLY IF your CAS deployment is acting and running as an OpenID Connect identity provider. If your deployment does not pass the noted condition(s) above, there is nothing for you to do here. Keep calm and carry on.

Exposure

A security vulnerability was identified in Apereo CAS when operating as an OpenID Connect Provider with support for Pushed Authorization Requests, which is on and available by default. In the affected behavior, CAS accepted a PAR request without properly validating the supplied redirect_uri against the relying party’s registered redirect URI configuration. Because PAR requests move authorization parameters into a back-channel request and later reference them by request_uri, validation must occur when the request is pushed, not deferred or assumed safe simply because the request was stored by the server.

The impact is that a malicious or misconfigured client could submit an authorization request containing an unauthorized redirect_uri, potentially causing the resulting authorization response, including an authorization code or related OIDC response parameters, to be delivered to a location not approved for that client.

Timeline

The issue was originally reported to the team at Coop (Switzerland) on May 5th, 2026 and was shared with the CAS project on May 22nd, 2026. Upon confirmation, CAS releases were patched and eventually published on May 27th, 2026.

Patching

Patch releases are available to address CAS deployments. Upgrades to the next patch version for each release should be a drop-in replacement.

Affected Versions

7.3.x

Modify your CAS overlay to point to the version 7.3.7.1.

How to upgrade

Locate your gradle.properties file in your CAS overlay, found at the root of the project.
Modify your CAS version to point to the approriate release version noted above by updating the cas.version property.
Follow the instructions in the README.md file to build the server, i.e. ./gradlew[.bat] clean build.

Support

Apereo CAS is Apache v2 open source software under the sponsorship of the Apereo Foundation. Support options may be found here.

Resources

On behalf of the CAS Application Security working group,

Misagh Moayyed

Java CAS Client JWT Vulnerability Disclosure

Wed, 20 May 2026 00:00:00 +0000

Overview

This is an Apereo CAS project vulnerability disclosure, describing an issue in the Java CAS Client while validating tickets issued as JWT.

For additional details on how security issues, patches and announcements are handled, please read the Apereo CAS project vulnerability disclosure process.

Credits

This issue was reported to the project by a third-party researcher and was then further validated and tested by Mr. Jérôme Leleu, who is a project member and an active committer.

Thank you everyone!

Affected Deployments

If you have an application that uses the Java CAS client to intergrate with a CAS server and is configured to accept and validate JWTs from that server, you are affected and do need to upgrade. If this condition does not pass for your application deployments, there is nothing for you to do here. Keep calm and carry on.

If you or your institution is a member of the Apereo foundation with an active support subscription supporting the CAS project, please contact the CAS subs working group to learn more about this security vulnerability report.

Timeline

The issue was originally reported on May 2nd 2026, and upon confirmation, Java CAS client releases were patched and eventually published on May 20th, 2026.

Patching

Upgrade your applications to use Java CAS client’s version 4.1.1.

Support

Apereo CAS is Apache v2 open source software under the sponsorship of the Apereo Foundation. Support options may be found here.

Resources

On behalf of the CAS Application Security working group,

Misagh Moayyed

Apereo CAS - External Identity Providers

Sat, 25 Apr 2026 00:00:00 +0000

External identity providers registered with CAS, such as those that speak the OpenID Connect or SAML2 protocol largely remain static throughout the server lifecycle. Once built and available, their configuration remains in read-only mode and can only be modified with direct access to CAS configuration, server rebuilds and restarts.

Building on top of Dynamic Configuration Management features, newer CAS 8.x releases now allow one to register and modify external identity providers that can be used for delegated authentication attempts. The registration of external identity providers is now handled and supported by the Palantir admin dashbord.

This post provides an overview of external identity providers can be registered with the CAS server dynamically, without having to restart the server. Please note that this work is supported by and executed as part of the CAS proposal to NLnet.

Overview

As discussed, the main objective here is to allow the Palantir admin dashbord to support registering external identity providers. Doing so requires one to use Dynamic Configuration Management features of CAS to allow on-the-fly registration of external providers and gain the ability to edit their configuration without having to rebuild or restart.

Starting with most recent releases of CAS 8.x, Palantir admin dashbord now provides a humble view of all available external identity providers, regardless of their method of registration and configuration:

The most notable change here is the NEW button which allows one to register an identity provider. Available identity provider types are for now limited to the following set:

CAS

OpenID Connect

OAUTH

Keycloak

SAML2

Modifications

The registration process requires Dynamic Configuration Management features of CAS. Once an identity provider is registered, its configuration can be modified and edited exactly as any other CAS setting, since all configuration constructs are eventually translated to CAS properties and ultimately become available to the CAS application context.

Roadmap

The admin dashboard today supports a limited set of external identity provider types and a narrowed populist view of what can be configured for each provider. Going forward, the intention is to customize and enhance the registration process to add more identity provider types and support additional settings as necessary.

On behalf of the CAS project,

Misagh Moayyed

CAS JWT Authentication Vulnerability Disclosure

Fri, 06 Mar 2026 00:00:00 +0000

Overview

This is an Apereo CAS project vulnerability disclosure, describing an issue in CAS while using a token-based JWT Authentication feature.

For additional details on how security issues, patches and announcements are handled, please read the Apereo CAS project vulnerability disclosure process.

Credits

This issue was originally reported, researched and tested by Mr. Jérôme Leleu, who is a project member and an active committer. Jérôme was kind enough to thoroughly investigate the issue, discuss the problem in detail, provide steps to reproduce the problem and offer insight to diagnose the root cause.

Thank you Jérôme!

Affected Deployments

The problem addressed here, per the CAS maintenance policy, affects the Apereo CAS server for the following versions:

- 7.2.x
- 7.3.x

Severity

You are effected by this security vulnerability if your CAS deployment has specifically enabled a feature called JWT Authentication, sometimes also referred to as token-based non-interactive authN and accepts credentials as JWTs for non-interactive authentication attempts. Note that this has nothing to do with any other CAS functionality that deals with JWTs.

For better details, see:

When JwtAuthenticator decrypts a JWE, it attempts to parse the inner token as a SignedJWT. If the inner token is a PlainJWT (alg=none), the SignedJWT object is null and the signature verification path is skipped due to a logic error. The code then builds a user profile from unverified claims, enabling full impersonation. Impacted deployments are those using RSA-based JWE together with JwtAuthenticator configured with both EncryptionConfiguration and SignatureConfiguration.

If your deployment does not pass the noted condition(s) above, there is nothing for you to do here. Keep calm and carry on.

Timeline

The issue was originally reported on March 2nd 2026, and upon confirmation, CAS releases were patched and eventually published on March 6th, 2026.

Patching

Patch releases are available to address CAS deployments. Upgrades to the next patch version for each release should be a drop-in replacement.

Affected Versions

7.2.x

Modify your CAS overlay to point to the version 7.2.7.1.

7.3.x

Modify your CAS overlay to point to the version 7.3.5.

How to upgrade

Locate your gradle.properties file in your CAS overlay, found at the root of the project.
Modify your CAS version to point to the approriate release by updating the cas.version property.
Follow the instructions in the README.md file to build the server.

Support

Apereo CAS is Apache v2 open source software under the sponsorship of the Apereo Foundation. Support options may be found here.

Resources

On behalf of the CAS Application Security working group,

Misagh Moayyed

Apereo Community Blog

OpenID Federation with pac4j and CAS

1) Setup a CAS server as the OP

2) Setup the pac4j application as the RP

a) Dependencies

b) Properties

c) SecurityConfig class

d) Application class

3) Setup a CAS server as the trust anchor

4) Final test

CAS Vulnerability Disclosure

Overview

Affected Deployments

Exposure

Timeline & Credits

Patching

Versions

7.3.x

8.0.x

How to upgrade

Security In The AI Era

Support

Resources

CAS Vulnerability Disclosure

Overview

Affected Deployments

Exposure

Timeline & Credits

Patching

Versions

7.3.x

8.0.x

How to upgrade

Security In The AI Era

Support

Resources

Changes to CAS Security Vulnerability Response

TL;DR

Why the Change?

What Is Changing?

What Is Not Changing?

Expectations for Adopters

CAS Vulnerability Disclosure

Overview

Affected Deployments

Exposure

Timeline & Credits

Patching

Versions

7.3.x

How to upgrade

Security In The AI Era

Support

Resources

CAS Vulnerability Disclosure

Overview

Affected Deployments

Exposure

Timeline & Credits

Issue: Google Authenticator with Redis

Exposure

Issue: Redis Ticket Registry

Exposure

Issue: OpenID Connect

Exposure

Patching

Versions

7.3.x

How to upgrade

Security In The AI Era

Support

Resources

CAS OpenID Connect Vulnerability Disclosure

Overview

Credits

Affected Deployments

Severity

Exposure

Timeline

Patching

c) `SecurityConfig` class

d) `Application` class