> I see that, after being authenticated, the CASTGC cookie that the CAS server > creates that contains the session token in the content attribute
I would recommend avoiding the term "session token" when referring to the CAS ticket-granting ticket for fear of confusion with the more common meaning of an identifier that maintains an application server's session state. > I'm assuming though that ... the CAS client code is retrieving the session > token from the cookie and calling the CAS server to validate the token. The CAS client does not interact with browser cookies. Study of the protocol documents may be helpful background here. The TGT is not sent with the service ticket at validation time. The _browser_ sends a request to CAS for a service ticket. CAS either complies immediately if the CASTGC containing a valid TGT is sent or it forces the user to authenticate. The service ticket is then delivered back to the CAS-enabled application for validation. _Only_ the service ticket is needed for validation, and it is retrieved from the querystring. > Although the validation between the client and the CAS server is over SSL, > the cookie data is being sent from the browser to the client app server over > http. Is this correct? No. As Scott said, the CASTGC cookie is only sent over a secure channel. It is _never_ sent over http assuming the browser honors the "secure" flag in the cookie. > If yes, then this is what you meant in your earlier reply that the session > token is exposed? I am fairly certain he meant the application server session identifier. If your application maintains any sort of state, then a session ID cookie of some sort is sent back to the browser. Failure to send this cookie over a secure channel enables man-in-the-middle attacks against your application. 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
