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
Em sábado, 29 de novembro de 2025 às 20:19:50 UTC-3, Petr Bodnár escreveu:
> 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
> <https://apereo.github.io/cas/developer/Build-Process.html#remote-debugging>
> the CAS application and e.g. step over the Java lines I've sent previously.
>
> Best regards
> Petr
> On Wednesday, 26 November 2025 at 17:17:34 UTC+1 Thiago Castro wrote:
>
>> 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
>>
>> Em quarta-feira, 26 de novembro de 2025 às 12:52:24 UTC-3, Petr Bodnár
>> escreveu:
>>
>>> 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
>>> On Saturday, 22 November 2025 at 05:26:05 UTC+1 Thiago Castro wrote:
>>>
>>>> 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
>>>>
>>>
--
- 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 [email protected].
To view this discussion visit
https://groups.google.com/a/apereo.org/d/msgid/cas-user/63553a75-153d-446f-bf70-d2933c3c487fn%40apereo.org.
