Thanks all, let me just check what's happening here: CAS server sends single signout to all apps with service tickets for the user. Some apps don't give the expected response (and give server errors on receiving the SSO traffic over https). The CAS server doesn't get the expected response from SSO and throws an error (OR the CAS server logs the server error from the external app in its server log).
Kim ~=|=~ Kim Cary Chief Information Security Officer Pepperdine University On Fri, Dec 11, 2009 at 5:41 AM, Scott Battaglia <[email protected]>wrote: > Created CAS-828 to track it. > > Cheers, > Scott > > On Fri, Dec 11, 2009 at 8:35 AM, Marvin Addison > <[email protected]>wrote: > >> > The alternative is that if this list agrees we can change the logging >> level >> > of that error message and possibly not include the entire stack trace >> ;-) >> >> +1 for some change here. It's important to log it, but the stack >> trace is both verbose and virtually useless. We just need to know >> what URL failed and the HTTP response code. Suggested message text >> off the top of my head: >> >> WARN Single sign out failed for http://example.com/app/?data. >> Application returned HTTP 500 response. >> >> We also see lots of connection failures in our environment, which >> should be treated similarly. I'd recommend logging this at WARN since >> it has security implications. >> >> 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
