I posted about something that MAY be relevant a few months ago, though not 
directly related to MFA overlay…

I was having issues with my Ehcache implementation (via RMI replication) and 
synchs of TGTs not happening in a timely manner (sub-second, bear in mind.) 
While the default cache replicator for ST is synchronous, the TGT is 
asynchronous (both RMI & Jgroups instructions.) I’m not sure why this is.

See docs I followed here:
http://jasig.github.io/cas/4.0.x/installation/Ehcache-Ticket-Registry.html

Instead of fussing with timing and sizing of the asynchronous TGT cache 
replicator, I modified my config to make TGT cache replication synchronous as 
well, which solved my issues with TGT timing issues. I have not yet had any 
issues yet in light load testing, but am all ears to any potential issues from 
the community on this topic.

--
Raymond Walker
Software Systems Engineer StSp.
ITS Northern Arizona University

From: Michael O Holstein
Reply-To: "[email protected]<mailto:[email protected]>"
Date: Friday, July 17, 2015 at 9:05 AM
To: "[email protected]<mailto:[email protected]>"
Subject: [cas-user] mfa + any distributed cache = fail


I have built cas-mfa-overlay RC5 from fresh pull a couple of times now .. and 
as long as I use the default ticketManager, everything works fine.


As soon as I try and enable another cache manager (I've tried memcached and 
ehcache thus far) I get a failure mode whereby the first login to CAS or a CAS 
service works fine. The *NEXT* login to something (whereby the TGT should be 
verified from the cache) fails with a 500 web error and this exception thrown :


Jul 17, 2015 11:53:13 AM org.apache.catalina.core.StandardWrapperValve invoke

SEVERE: Servlet.service() for servlet [cas] in context with path [/cas] threw 
exception [Request processing failed; nested exception is 
org.springframework.webflow.execution.ActionExecutionException: Exception 
thrown executing org.jasig.cas.web.flow.InitialFlowSetupAction@30502819 in 
state 'null' of flow 'login' -- action execution attributes were 
'map[[empty]]'] with root cause

java.lang.ClassCastException: Cannot cast 
org.jasig.cas.ticket.registry.AbstractDistributedTicketRegistry$TicketGrantingTicketDelegator
 to org.jasig.cas.ticket.TicketGrantingTicketImpl


I've already dealt with the bug of competing classes between the ticket ehcache 
and the one that comes with support-radius using an exclusion in the overlay .. 
but regardless of what cache manager I use I always get the above error when 
trying to authenticate to the 2nd (and subsequent) service.


Actually it fails way before it even gets to looking up services, because 
something that normally would fail with not authorized like this :


https://my.cas.server/cas/login?TARGET=https://foo.bar .. still barfs with the 
"cannot cast" exception.


Anyone have any ideas on this? I've been through spring forums and Google and 
not found much to point me in the right direction.


Thanks,


Michael Holstein

Cleveland State University

--
You are currently subscribed to 
[email protected]<mailto:[email protected]> as: 
[email protected]<mailto:[email protected]>
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Reply via email to