SAML2 error "registry or service access is denied" during server runtime after upgrade from 6.6.15 => 7.2.7.1
Olivier Salaün
Hello,
Our context :
- JSON service registry
- 99% of CAS clients - 1 SAML client
- JRE 21
We are facing a tricky problem after upgrading our CAS server (6.6.15 => 7.2.7.1)
At CAS startup everything is fine, but during server runtime suddenly
our SAML client's authentication requests get rejected with the
following log :
2026-03-24 15:39:43,952 WARN
[org.apereo.cas.support.saml.web.idp.profile.AbstractSamlIdPProfileHandlerController]
- <[https://vpn.univ-rennes1.fr:443/remote/saml/metadata] is not
found in the registry or service access is denied.>
We had a similar error while CAS server processes a logout request :
2026-03-24 15:38:45,090 WARN [org.apereo.cas.services.RegisteredServiceAccessStrategyAuditableEnforcer] - <Service is not registered in the service registry.Service is [Optional[AbstractWebApplicationService(id=https://vpn.univ-rennes1.fr:443/remote/saml/metadata, originalUrl=https://vpn.univ-rennes1.fr:443/remote/saml/metadata, artifactId=null, principal=null, source=null, tenant=null, loggedOutAlready=false, format=XML, attributes={headers={jakarta.servlet.http.HttpServletRequest.header-host=[sso-cas.univ-rennes.fr], jakarta.servlet.http.HttpServletRequest.header-user-agent=[FortiSSLVPN (Windows NT; SV1 [SV{v=02.01; f=07;}])], jakarta.servlet.http.HttpServletRequest.header-fsv_public_ip=[83.197.190.96], jakarta.servlet.http.HttpServletRequest.header-x-forwarded-for=[83.197.190.96], jakarta.servlet.http.HttpServletRequest.header-x-forwarded-host=[sso-cas.univ-rennes.fr], jakarta.servlet.http.HttpServletRequest.header-x-forwarded-server=[sso-cas.univ-rennes.fr], jakarta.servlet.http.HttpServletRequest.header-connection=[Keep-Alive]}, SigAlg=[http://www.w3.org/2000/09/xmldsig#rsa-sha1], SAMLRequest=[lZJdb9sgFIbv9yss7gn+jBeUWMritIqWrh9OV2k3E7WPOyobPA728vOLnVXKJnXqJG448D6cB1iiaJuO7/WT7u0d/OwBrXdsG4V8WlmR3iiuBUrkSrSA3Ja8WF/teTjzeWe01aVuyFnk3wmBCMZKrYi3y1fk+ybdpB/zRZpEn+Z+Po/zrR+u1/Mk3iabKI62xPsKBt3+FXFxF0LsYafQCmVdyQ/n1I9oGB+CmIduLL4RL3cOUgk7pX5Y2yFnDFHTUuCsV3KgBpQCnNWGyapjzqKWDbCxyZDdQSUNlJYV+2uSLUclPp1qslfW0KlzTuBAPI4jZqDVFtgYYS1YUQkrluyccMJ9cdeyy70LbVph376vYBZMFVnRetrKe4UdlLKWUBFvpNz2ohmn5j2ixCtu3gj9jxHJWgGqgUdtnhT89jspnfw6XgCOb7ZTFRyz4kCDKPJj+nkdHlL6cD1cXvn3afJg9aLeBr+e88dbOrTPYhC0c50nJ+RflA+v1T++avYC], RelayState=[magic=3-5779cf88c789b4fb], Signature=[L7EhDKsMitM71TmBYXkRnTc7MEiCc02G5p8iojlgLHPEzz8Ray+tutWc5VwoBCCpGATJ9BW4gyCbwwkCLemuHiFIpKBXm503fOnOmDen+FFxBbr31qY1fOM4VAs8LzuMQzLjGENnJHUvapvwiB/KWKCGByLBu9m3uBVrswgJwPFQ2+tzeKKoAXLWcyQ7uhUtSYB1jt0cIX9MFgy3wbbWB0ojIXUkKseZISptNTqJGLLI4flDtVpbnahyHYGfU1a6MBiQFnEcvQFGmp/CwQR35Azmj8srQRj+C0BDzD0KuSRcQOmV20UQYJLNcl0dKdduz5OvWu69OcKISEiDnDa8Lw==], httpRequest={jakarta.servlet.http.HttpServletRequest.httpMethod=[GET], jakarta.servlet.http.HttpServletRequest.requestURL=[https://sso-cas.univ-rennes.fr/idp/profile/SAML2/Redirect/SLO], jakarta.servlet.http.HttpServletRequest.requestURI=[/idp/profile/SAML2/Redirect/SLO], jakarta.servlet.http.HttpServletRequest.requestId=[27cce], jakarta.servlet.http.HttpServletRequest.localeName=[vmjava-pcas5.univ-rennes.fr]}, entityId=[https://vpn.univ-rennes1.fr:443/remote/saml/metadata]})]] and registered service is [Optional.empty]>
We observed this behavior on both our 2 production CAS servers after 10-70min of runtime.
Our interpretation : for some reason, during CAS process execution, it looses knowledge of some registry entries.
Details :
- once a CAS server starts rejecting our SAML client's SAML requests, it never goes back to normal until the process is restarted;
- only SAML requests are affected ; we did not observe similar problems for clients request using CAS protocol ;
- we were not able to reproduce this on our test server, because we have, of course, much less traffic than the production servers.
We tried to remotely debug support/cas-server-support-saml-idp-web/src/main/java/org/apereo/cas/support/saml/web/idp/profile/AbstractSamlIdPProfileHandlerController.java, but it din't help because we can't reproduce the problem without real load.
We went through https://apereo.github.io/cas/7.3.x/release_notes/Overview.html, but didn't find reference to a similar bug fix.