Trouble with ActiveMQ/Artemis JMS ticketing system on Cas 6.5.6.

[Joe Gullo]

We have a cas environment with 2 front ends, and want to point to a central jms server for distributed ticketing.  We have artemis set up on a third box (not using artemis specifically, just using it as the next activemq release).  Auth is handed off via delegated saml (to okta) so pac4j is used for authentication.  When a user logs in, it is successful, they get a ticket and they get attributes, but I do not believe the distributed ticketing is successful.  Here is the JMS configuration:

cas.ticket.registry.jms.crypto.signing.key=REDACTED
cas.ticket.registry.jms.crypto.encryption.key=REDACTED
spring.activemq.broker-url=tcp://urltoserver:61617
spring.activemq.user=REDACTED
spring.activemq.password=REDACTED
spring.activemq.pool.enabled=true
spring.activemq.pool.max-connections=50
spring.activemq.packages.trust-all=false
spring.activemq.packages.trusted=org.apereo.cas

Then when a user logs in, despite the login being successful, I get this in the cas logs (the actual value of the specified config replaces what's in bold):

2022-07-20 20:32:37,106 WARN [org.springframework.jms.listener.DefaultMessageListenerContainer] - <Execution of JMS message listener failed, and no ErrorHandler has been set.>
org.springframework.jms.listener.adapter.ListenerExecutionFailedException: Listener method 'public void org.apereo.cas.ticket.registry.JmsTicketRegistryQueueReceiver.receive(org.apereo.cas.ticket.queue.BaseMessageQueueCommand) throws java.lang.Exception' threw exception; nested exception is org.springframework.jms.support.converter.MessageConversionException: Failed to convert JSON message content; nested exception is com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Problem deserializing 'setterless' property ("authnContexts"): no way to handle typed deser with setterless yet
 at [Source: (String)"{"@class":"org.apereo.cas.ticket.queue.UpdateTicketMessageQueueCommand","id":{"@class":"org.apereo.cas.util.PublisherIdentifier","id":"90e5a8e0-2654-43dc-aeb8-210880c1083d"},"ticket":{"@class":"org.apereo.cas.ticket.TransientSessionTicketImpl","@id":1,"expirationPolicy":{"@class":"org.apereo.cas.ticket.expiration.MultiTimeUseOrTimeoutExpirationPolicy$TransientSessionTicketExpirationPolicy","numberOfUses":1,"timeToLive":300,"name":"TransientSessionTicketExpirationPolicy-95b2fec6-0c78-4d42-8f70-99"[truncated 2020 chars]; line: 1, column: 2068] (through reference chain: org.apereo.cas.ticket.queue.UpdateTicketMessageQueueCommand["ticket"]->org.apereo.cas.ticket.TransientSessionTicketImpl["properties"]->java.util.HashMap["pac4jUserProfiles"]->java.util.LinkedHashMap["cas.authn.pac4j.saml[0].clientName="]->org.pac4j.saml.profile.SAML2Profile["authnContexts"])

Additionally, this is in the artemis logs:

2022-07-20 20:32:39,115 WARN  [org.apache.activemq.artemis.core.server] AMQ222149: Message Reference[47408]:RELIABLE:CoreMessage[messageID=47408,durable=true,userID=11bdaf9a-086b-11ed-b8ae-0a888fcbcf63,priority=4, timestamp=Wed Jul 20 20:32:27 UTC 2022,expiration=0, durable=true, address=CasTicketRegistryQueue,size=6788,properties=TypedProperties[__HDR_dlqDeliveryFailureCause=java.lang.Throwable: Delivery[7] exceeds redelivery policy limit:RedeliveryPolicy {destination = null, collisionAvoidanceFactor = 0.15, maximumRedeliveries = 6, maximumRedeliveryDelay = -1, initialRedeliveryDelay = 1000, useCollisionAvoidance = false, useExponentialBackOff = false, backOffMultiplier = 5.0, redeliveryDelay = 1000, preDispatchCheck = true}, cause:null,__AMQ_CID=ID:cas-front-end-hostname-36353-1658348877999-0:10,_AMQ_GROUP_SEQUENCE=0,__HDR_BROKER_IN_TIME=1658349147052,@class=org.apereo.cas.ticket.queue.UpdateTicketMessageQueueCommand,_AMQ_ROUTING_TYPE=1,__HDR_ARRIVAL=0,__HDR_COMMAND_ID=5,__HDR_PRODUCER_ID=ID:cas-front-end-hostname-36353-1658348877999-1:10:1:1,__HDR_MESSAGE_ID=ID:cas-front-end-hostname-36353-1658348877999-1:10:1:1:1,__HDR_DROPPABLE=false]]@1093364495 has reached maximum delivery attempts, sending it to Dead Letter Address DLQ from CasTicketRegistryQueue

I'm stumped, this is over my head as a sysadmin and not a java developer, any clues would be helpful here.

[Lars Grefer]

We found the same Problem on CAS 6.5.5 with a JPA-Ticket Registry and delegation to a Microsoft AD via SAML2.

TL;DR: It seems like CAS failes to read the JSON it wrote earlier.

Inside the stored ticket is some JSON Data which gets serialized when the ticket is stored.
When the tickets is then read again later, CAS tries to deserialize the JSON back into Java objects which fails here.

This seems to be independent of the actual storage used as it happens with both JMS/Artemis (your case) and JPA/MariaDB (our case).

Im afraid this is a bug which has to be fixed somewhere inside CAS itself and we cannnot fix it by simply setting some properties.

[Henry Heikkinen]

We have encountered the same issue with CAS 6.6 and JPA Ticket Registry. Redis Ticket Registry seems to not have this issue as it uses org.apereo.cas.util.serialization.SerializationUtils instead of AbstractJacksonBackedStringSerializer to serialize the tickets for storage.

Is it possible to change the serialization method for JPA Ticket Registry?

[Henry Heikkinen]

For now we have solved the issue by registering custom serializer for the TransientSessionTickets which uses SerializationUtils for serialization similar to how RedisTicketRegistry does it.

Our changes for reference: https://github.com/Opetushallitus/cas-oppija/commit/809a7f357d74c54526e63266e660d19ae92f04b2