I find it amusing how you empirically claim the redirects as being "wildly inefficient" especially when your thoughts on how to improve the situation do nothing to reduce network congestion. I would counter that many of us CAS deployers have seen little concern for this through our long term use.
The service ticket is used not only for authenticating a user for a service, but it is the identifier transmitted to the service whenever a user logs out of CAS. The CAS client needs to invalidate the user's session and does so by associating the service ticket with the session. If CAS merely told the application "Log user X out" then you cannot support concurrent sessions. When a service ticket is created, CAS associates a username and a service URL with the service ticket. If you tried to reuse it, then everyone who connects to the application will be given the same username. I don't see the CAS protocol changing as it has been well thought out with security in mind, so I imagine this thread will end shortly. A- On 7/21/09 7:41 AM, "Anthony R. J. Ball" <[email protected]> wrote: >> One-time tickets protect against replay attacks. >> That's good for security and not ridiculous at all. >> >> Also the way it works makes cross-domain WebSSO possible. This is not >> possible with cookies in web browsers (also for very good reasons). > > I understand how the system works, but honestly, how > much more secure is the TGC that CAS uses than a long term > application cookie? I mean, if someone gets ahold of the TGC > then they could generate their own tickets. Though I suppose > it is relatively easy to pull a url from a web log or something > of the like, while a bit harder to steal a cookie. > > However, if the system were redesigned such that the client app > requested a temporary token, stored it in a session or cookie and > called the login page passing that token and when authenticated > used the temp token to pull the service ticket from the backend, > wouldn't this be just as secure but let you bypass the crazy > redirects? It just seems wildly inefficient. -- Andrew Feller, Business System Programmer LSU University Information Services 200 Frey Computing Services Center Baton Rouge, LA 70803 Office: 225.578.3737 Fax: 225.578.6400 -- 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
