Supported protocols in service definition

[Thiago Castro]

Greetings,

I'm using Apereo/CAS 7.3.1 in Podman and I have a problem with templates of services + supportedProtocols. I defined a template in a file called "desativaCASV1.json" with the following content:

{
  "@class" : "org.apereo.cas.services.CasRegisteredService",
  "templateName" : "desativaCASV1",
  "supportedProtocols": [ "java.util.HashSet", ["CAS20", "CAS30"] ]
}

I'm using this template in a service without supportedProtocols object and with templateName: "desativaCASV1". When I access the actuator of registeredServices, the definition is there, but the service can still validate a ticket through CAS V1.0.

Can anyone help me understand why it's allowing CAS V1.0? 

Beforehand, I'm assure you that I inserted the scripting dependency and configured the directory of templates with file:/path/to/directory/in/container. We can notice that since the registeredServices actuator shows the definition correctly.


Respectfully,

Thiago

[Petr Bodnár]

Hi Thiago,

some additional questions:

1. So you are calling /cas/validate, right?
2. Have you tested with older versions of CAS?
3. When you don't use a template, you say the validation correctly fails?

For prospective investigation, these are the interesting top-level lines in CAS AbstractServiceValidateController which, apparently by-design, firstly validate the ticket and only then check the used protocol (and return INVALID_TICKET when that check is not successful):

        val assertion = validateServiceTicket(service, serviceTicketId);
        if (!validateAssertion(request, serviceTicketId, assertion, service)) {
            val description = getTicketValidationErrorDescription(CasProtocolConstants.ERROR_CODE_INVALID_TICKET, new Object[]{serviceTicketId}, request);
            return generateErrorView(CasProtocolConstants.ERROR_CODE_INVALID_TICKET, description, request, service);
        }

Best regards

Petr

[Thiago Castro]

Hello Petr! 

Thank you for the reply.

1 - The client which is doing the request is a Apache server doing proxy and using mod_auth_cas. I set CASVersion 1 with /validate for validation. And my server context path is /.

2 - No, I didn't. This is the first version ever going in production.

3 -  Yes. If I write directly the "supportedProtocols" key in the service definition, it correctly rejects the ticket due to wrong supported version of protocol.

Best regards,

Thiago

[Petr Bodnár]

Hello Tiago,

that's strange. I've just tested on a pure CAS 7.3.1 instance and I couldn't reproduce the problem with a service template even there. I.e.:

1. I can see the expected merged definition via /actuator/registeredService - it contains "supportedProtocols": [ "java.util.HashSet", ["CAS20", "CAS30"] ].

2. When calling /validate ("CAS10"), I can see SERVICE_TICKET_VALIDATE_SUCCESS and then PROTOCOL_SPECIFICATION_VALIDATE_FAILED in the audit logs, and CAS server correctly returning "no".

Are you sure you don't have a) any other service definition matching the requests while testing, b) no customizations in this area? Otherwise, I can see no reason why CAS would show you the expected supportedProtocols, while not respecting them while processing the validation request.

If the problem doesn't go away, you can always try to debug the CAS application and e.g. step over the Java lines I've sent previously.

Best regards

Petr

[Ray Bon]

Tiago,

Petr made a good point about other matching services.

If you have actuators enabled, you can see what cas has for services with:

https://local.uvic.ca/cas/actuator/registeredServices

Or with logger:

        <!-- INFO Loaded [#] service(s) from [???ServiceRegistryDAO]

             DEBUG Adding registered service [service URL] -->

        <Logger name="org.apereo.cas.services.AbstractServicesManager" level="warn" />

Ray

---

From: cas-...@apereo.org <cas-...@apereo.org> on behalf of Thiago Castro <thiag...@gmail.com>
Sent: November 26, 2025 08:02
To: CAS Community <cas-...@apereo.org>
Cc: Petr Bodnár <p.bo...@centrum.cz>; Thiago Castro <thiag...@gmail.com>
Subject: [cas-user] Re: Supported protocols in service definition

 

You don't often get email from thiag...@gmail.com. Learn why this is important

--
- Website: https://apereo.github.io/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/ead74cb9-d41f-469e-badc-6de688374768n%40apereo.org.

[Thiago Castro]

I did the debug as you mentioned. When using template, the supportedProtocols in registeredService in the assertion of validateAssertion method call is a linkedHashSet empty (the expansion gives nothing). When I insert the supportedProtocols directly, the assertion variable has a hashSet as expected with CAS20 and CAS30. 

In order to eliminate the possibility of problem in the service definition, I declared a description in the template. It also doesn't appear in the registeredService in the assertion, but appears in the actuator registeredService JSON output.

Thus, I guess it's a problem with the merge recognition.

Best regards,

Thiago