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 cas-user@lists.jasig.org as: d...@case.edu > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- > -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
