This has been happening intermittently for some time (and I'm aware of earlier threads on the topic):
Every so often a user with a valid TGT visits a site and it triggers a loop between our CAS servers (3.5.2) and a one of a seemingly random selection of CAS clients. If the user lets the browser sit, the looping could go on for hours, sometimes several times per second: generating a service ticket, the CAS client validating it, and starting all over again. The issues doesn't seem to be CAS client specific, as we've seen the behavior with a number of different CAS client implementations (at least mod_auth_cas, the official Java CAS client and a home-grown ColdFusion client off the top of my head). This is CAS version 2 (don't recall offhand if it happens with version 1). Our deployment uses Ehcache. Given service tickets are being validated at the servers, I don't expect the issue to be with the cache. Q: Our TGTs are not replicated synchronously (every 10s), the STs are. I assume an ST entry on a CAS server contains the user principal, or we would have seen principal resolution problems much, much earlier. Correct? I see nothing in CAS client logs that I've been able to observe to explain the situation, such as a malformed serviceValidate response. Being production, logs are not set to debug, though. For what it's worth, with mod_auth_cas we typically run CASDebug on and httpd LogLevel warn. I don't think it's that the browser isn't accepting cookies. I've witnessed it once myself, and was not running the browser in any kind of private/incognito mode. I'm kind of stumped here. If one of more instances of looping occurs during a busy time of the academic year, user entries in cache grow effectively without bound (to 100+ MB) faster than STs are being expired, and the service slowly grinds to a halt (Ehcahche is configured for full replication). We're working on 4.x with Hazelcast, but it would be useful to find a solution/workaround to this issue while we garner resources for the upgrade. In the mean time, I'm trying to look into request throttling (or redirect to an error page) on the CAS servers when some combination of IP address plus service URL exceeds a (TBD) threshold in a (TBD) time window, e.g. more than 100 requests per minute to /cas/login from a single IP for the same service URL. And for the record, this is not throttling login attempts; the user in this case is already authenticated (valid CASTGC). Thanks for any info, suggestions, .... Tom. -- 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]. Visit this group at http://groups.google.com/a/apereo.org/group/cas-user/.
