Barry, as Jérôme explained, the TGC/TGT is a cookie sent by CAS to the browser, stored by the browser and only played back to the CAS server by the browser. "A" has no access to the TGC, so the TGC can play no role in authenticating the communication from A to B. That is precisely why A needs the PGT.
You can summarize by saying that the TGC/TGT is used by a single client (the browser). Other clients such as A need a PGT. From: Barry Kern [mailto:[email protected]] Sent: Thursday, May 16, 2013 11:07 AM To: [email protected] Subject: Re: [cas-user] cas proxy / tgc confusion A communicates to B directly B is full of RESTful services that A consumes. B is secured by spring security if that matters. The first service call to the backend services (B)is mapped in spring security to allow anonymous authentication so I think the CAS filter in spring security picks it up and validates its etc. The second service call to B is mapped in spring security to be fully authenticated to spring security which it has not been yet. So the second call to B I see a GET to B/secure/someService then a 302 to CAS/login with service parameter then GET to CAS/login then 302 to service URL with service ticket which then gets validated then finally a response comes from the B/secure/someService etc. I think I was thinking the reason the second call 'worked' when it redirected to cas/login but was redirected w/ a ticket was because of the initial TGT set by CAS when A authenticated. But it sounds like I am incorrect. Was it that the proxy ticket validation authenticated B to CAS so subsequent calls to CAS from B were recognized as authenticated and no login was necessary? thanks, Barry On Thu, May 16, 2013 at 9:38 AM, jleleu <[email protected]> wrote: Hi, A TGT (ticket granting ticket) represents a SSO session, it's not linked to a specific service even if the services accessed during the SSO session are known by the TGT. A TGT is stored as a cookie (CASTGC : CAS ticket granting cookie) only seen by the CAS server (and not the applications). I'm not sure to clearly understand what kind of communication is between A and B in your use case. If A contacts B directly (no browser involved), there won't any redirection available towards the CAS server. In this case, you need a PGT (proxy granting ticket). If A redirects to B (through the browser), a redirection to the CAS server will occur from B and the authentication can be "propagated" from A to B. Best regards, Jérôme -- 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
smime.p7s
Description: S/MIME cryptographic signature
