I am assuming that the third party won't share their code ?? My initial gut response was that they were maybe using a static variable somewhere to store the userid or that they didn't have caching set properly on their http request.
-John -----Original Message----- From: Tobias Quosigk [mailto:[email protected]] Sent: Tuesday, December 11, 2012 8:51 AM To: [email protected] Subject: Re: [cas-user] Log XML response to application server Thank you, Andy! I did consider changing the log levels to Debug, but decided to stay away that because it will store clear text user passwords in the log file on production. In a nutshell, the third-party application provider claims that CAS is sending his application the same username for two different CAS tickets (and two different users). All logs on CAS show that it was two different users, each getting a unique ST. However, when the third-party application server validates the tickets and receives the responses at the exact same time (same time down to the millisecond), his log of the XML responses show that CAS returned the same user for two different tickets in the XML responses. I have only circumstantial evidence that CAS doesn't return the same username for different STs (from different users) so I can't 'prove' to the developer that it's not CAS. (I have other casified applications with exponentially higher volume that do not exhibit this issue). Tobias ----- Original Message ----- From: "Andrew Morgan" <[email protected]> To: [email protected] Sent: Monday, December 10, 2012 6:17:51 PM Subject: Re: [cas-user] Log XML response to application server On Mon, 10 Dec 2012, Tobias Quosigk wrote: > I'm in the process of diagnosing a potential issue with a third-party > application and it would help me tremendously, if I could turn on > logging for the XML response referenced below, specifically the > username that gets returned to the third-party application: > > [From https://wiki.jasig.org/display/CASUM/Technical+Overview] "CAS > receives and validates this secure server-to-server request, then > fulfills the application server's HTTPS CAS client request and returns > an XML message of "success" along with the authenticated username." > > I'm running CAS 3.4.10. This doesn't give you the full XML, but have you looked at the audit log in CAS? Here is an example of the log entry for a ticket validation: 2012-12-10 09:39:29,385 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN ============================================================= WHO: audit:unknown WHAT: ST-471027-oySesJjITuWkeJUpOB2y-login1 ACTION: SERVICE_TICKET_VALIDATED APPLICATION: CAS WHEN: Mon Dec 10 09:39:29 PST 2012 CLIENT IP ADDRESS: 128.193.123.123 SERVER IP ADDRESS: login.oregonstate.edu ============================================================= You could also turn on DEBUG logging for (just a guess): org.jasig.cas.web.support.CasArgumentExtractor org.jasig.cas.web.support.SamlArgumentExtractor org.jasig.cas.util Or... approach it from the networking side. Run tcpdump to capture the traffic, then use Wireshark along with your CAS server's SSL cert and SSL key to decrypt the traffic and view it. Andy -- 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
