Google seems to be accepting the assertions each time as we are seeing the same number of logins in Google's audit logs as the number of STs being created. I would expect that if there was something wrong with assertion we would be receiving complaints from the users. I am more inclined at this point to believe some sort of crazy browser loop, but it's definitely not happening with any consistency.
We have tried contacting the two people we identified once we started to get a handle on what the issue was, however neither has responded. That's not terribly surprising given that we are in our finals period here and requests for information go pretty much ignored by students and faculty alike at this time. Dave On 12/10/14 8:14 PM, Sean Baker wrote: > Your access logs should show the individual SAMLRequest's generated by > Google; if it's rejecting your assertions in some automated way you > should see a new SAMLRequest each time. If it's the same request over > and over, one might infer a more local issue (not definitively mind you; > just much more likely) [ehcache issue, browser configuration, etc.]. > > Has anyone talked with your end users who're triggering these events > about what they experienced? > > On 12/10/14, 15:16 PM, David A. Kovacic wrote: >> Does anyone know what I would need to do to be able to log the actual >> SAML transactions? Is there any way to actually do that? We have >> isolated this issue to only logins to Google and only under certain >> conditions when something seems to start looping and generating STs >> rapidly. We are trying to isolate the conditions under which the >> loop starts. >> >> It would be helpful to actually see the SAML transactions being >> generated so we could begin to get a handle on what Google apps is >> being referenced and if Google is returning any errors or not >> (although Google claims valid logins). >> >> >> On 12/6/14 9:11 AM, Marvin Addison wrote: >>> >>> Second, the massive number of STs are being created on only one >>> server (we can tell by the host name in the logged ST) but the >>> OTHER SERVER is where the memory is growing out of bounds. >>> >>> >>> I'm still working through this thread, but I wanted to point out >>> that the other is hurting likely because of load balancer session >>> affinity. Recall that ticket validation is a back-channel call, and >>> the network source differs from that of the user's browser. In our >>> environment, services typically get stuck on one node causing hot >>> spots. This is because the service is validating tickets frequently >>> enough that the session affinity timeout never kicks in. >>> >>> M >>> >>> -- >>> 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 >>> >>> -- >>> >> -- >> 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 > > -- > 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 -- 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
