Is this happening with only a handful of applications, or is the problem evident across all? I would narrow down the problem scope. If it's just a few apps, they may be doing something out of band, they may need more memory to function, or they may be holding onto JVM's GC pauses and such. If it's happening across all, chances are this is a latency issue with your network topology. Firewalls, domain controllers, load balancer config, etc. Also, if you are running an HA CAS setup and are using synchronous replication of STs, (like you would be with Ehcache) note that network latency during the replication of an ST from one node to the next may cause a ticket to expire, which would then fail validation, etc. Personally, the only time I have run into a situation like that did involve the native windows firewall, and the TCP stack implementation on the windows server. The solution was to move away from that environment :) but that was a very unique case, and I have not seen that issue duplicated in other windows deployments.
Also, the delay may depend on your choice of ticket registry and its configuration. If there are competing processes that attempt to interact with the registry, like they would be with the JDBC registry, it may take a bit for CAS to locate the ST in the registry and proceed by which time it may be too late and the ticket may have already expired. Generally, connection latency to subsystems that CAS talks to for tickets and attribute resolution may be a factor here. From: Christopher Sterling [mailto:[email protected]] Sent: Monday, May 18, 2015 2:05 PM To: [email protected] <mailto:[email protected]> Cc: [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> Subject: Re: [cas-user] phpCAS not always returning user So, looking to see if anybody has any ideas of how I can trace some of the issues. There is something going on between our users where it takes the end user more then 30 seconds to go from CAS to our application. I realize this isn't a network support/what ever group, and that it's related to CAS, but does anybody have any suggestions on how we can do some diagnosing? Looking at the phpCAS debug log, the instant that phpCAS sees the user, it has finished the validation in < 1 second. Not sure where to go from here. If anybody has any suggestions as to what we can do to track down some of these errors, I would be very appreciative of it. Chris On Friday, May 15, 2015 at 1:34:04 PM UTC-4, Christopher Sterling wrote: Hey Mearl, Given that you've bumped it up and it resolved the issues you guys were encountering, we are going to do something similar and see if it resolves our issues as well. Chris On Friday, May 15, 2015 at 1:10:02 PM UTC-4, Danner, Mearl wrote: Finger fudge, Sorry IIRC we had to lengthen to 30 seconds due to similar issues. Didn't seem to have any problems due to it. Sent from my Android phone using Symantec TouchDown ( <http://www.symantec.com> www.symantec.com) -----Original Message----- From: Danner, Mearl [[email protected]] Received: Friday, 15 May 2015, 12:07PM To: <mailto:[email protected]> [email protected] [[email protected]] CC: <mailto:[email protected]> [email protected] [[email protected]]; <mailto:[email protected]> [email protected] [[email protected]] Subject: RE: [cas-user] phpCAS not always returning user IIRC Sent from my Android phone using Symantec TouchDown ( <http://www.symantec.com> www.symantec.com) -----Original Message----- From: Christopher Sterling [[email protected]] Received: Friday, 15 May 2015, 12:00PM To: <mailto:[email protected]> [email protected] [[email protected]] CC: <mailto:[email protected]> [email protected] [[email protected]]; <mailto:[email protected]> [email protected] [[email protected]] Subject: Re: [cas-user] phpCAS not always returning user Andy: >Why is it taking longer than 10 seconds for your application to validate the ticket? That's a good question, I wish I knew. We can't find any rhyme or reason. I was thinking slow network between redirecting the user from our CAS server back to the application. The reason I suspected that was because a number of the debug emails we've gotten have a mobile related user agent as part of the request. I just tried as GPRS (50Kbps and 500ms RTT) using google developer tools but I can't seem to get it to trigger our error page. I'm wondering if chrome allows the lookups and stuff to go through your standard connection, but downloads the assets via the throttled connection. I also tried fiddler2 and still can't reproduce it, so I'm out of ideas. I'm ok with the 1 time validation, but any suggestions on how we can change it to expire after like 30 seconds or something, and are there any downsides to extending that by 20 seconds? John: So, how our application is configured, we do allow non-CAS authenticated users to login to our system. I have an override a little later in the code that forces authentication if they don't meet certain criteria. The thing is, the current configuration of how I'm checking for CAS works probably 99.5% of the time. Though, looking through the code, I may not need the phpCAS::isAuthenticated() any more. Chris On Friday, May 15, 2015 at 11:55:58 AM UTC-4, Andrew Morgan wrote: Why is it taking longer than 10 seconds for your application to validate the ticket? The default timeout for service tickets is 10 seconds. Service tickets are only valid for 10 seconds (by default) or one validation. Andy On Fri, 15 May 2015, Christopher Sterling wrote: > So, our security guy wasn't a fan of the paste that I had posted since it > did have some information about our server in there (and he likes to err on > the side of caution), so here it is, even more > stripped: http://pastebin.com/NKpVrM8i > > So, what is happening is that some of our service tickets are expiring > after 10 seconds, but for the most part, they aren't. Since sunday, I can > find about 300 or so instances of it expiring early, the log file is almost > 400 megs, wasn't going to look at each one to see how quickly they failed, > and over 130,000 successful service tickets created and redeemed. > > Any insight? > > Chris > > On Thursday, May 14, 2015 at 9:32:21 PM UTC-4, Christopher Sterling wrote: >> >> So, have a weird issue that is popping up. 99% of the time, our users are >> authenticated successfully. There is that 1% where users aren't >> authenticated. I'm calling phpCAS::isAuthenticated() before calling the >> phpCAS::getUser() so they are authenticated when I'm trying to get their >> username. >> >> We do occasionally get this error that I have captured I'm not sure if >> this is the error that everybody is throwing. But it's happening frequently >> enough that I suspect it. >> >> When I get into work tomorrow. I'm going to enable cas debugging in php. >> I'll give any extra info I can >> >> >> Error is: >> >> Message: Uncaught exception 'CAS_AuthenticationException' in >> /portal/server/htdocs/portal/globals/CAS/CAS-1.3.2/CAS/Client.php:2839 >> Stack trace: #0 >> /portal/server/htdocs/portal/globals/CAS/CAS-1.3.2/CAS/Client.php(1224): >> CAS_Client->validateCAS20('https://cas.geo...', '\n\n\nisAuthenticated() >> #2 /portal/server/htdocs/portal/globals/CAS/CAS-1.3.2/CAS.php(1101): >> CAS_Client->forceAuthentication() #3 >> /portal/server/htdocs/portal/globals/template/auth.inc.php(48): >> phpCAS::forceAuthentication() #4 >> /portal/server/htdocs/portal/globals/template/head.inc.php(61): >> include('/portal/server/...') #5 >> /portal/server/htdocs/portal/portal.php(3): include('/portal/server/...') >> #6 {main} thrown >> File: /portal/server/htdocs/portal/globals/CAS/CAS-1.3.2/CAS/Client.php >> Line Number: 2839 >> -- >> >> > -- > 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] <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] <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] <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] <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] <mailto:[email protected]> as: [email protected] <mailto:jasig-cas-user%[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] <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
