Well, of course you need the redirect at the beginning because of the login cookie. It is the repeated redirects after the fact that seem unnecessary.
I'm not saying absolutely that I am right, just trying to figure out if I am, and if I'm not then why. On Tue, Jul 21, 2009 at 09:36:46AM -0400, Scott Battaglia wrote: > Also, if you look at other protocols including SAML and OpenID, they > generally all involve some form of redirect as part of their profiles for > enabling single sign on and authentication. > > Very few protocols don't, and those that don't generally cannot do > cross-domain single sign on. > > Cheers, > Scott > > > On Tue, Jul 21, 2009 at 9:34 AM, Andrew Feller <[email protected]> wrote: > > > 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 > > > > -- > 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 -- www.suave.net - Anthony Ball - [email protected] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Nice landing. Next time, put the wheels down first. -- 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
