> > Similar, yes, and yet different, and I could be entirely wrong, I am > > just trying to better understand, sorry if I sound confrontational. > > > > My thought: > > > > Application is accessed, not logged in. > > Application contacts the server on the backend, gets a temp token. > > > This is better than redirecting, how exactly? Its definitely not more > efficient.
> > > > > > Application stores the temp token, probably in a cookie. > > Application redirects to login server. > > > So far you haven't made anything more efficient. > > > > > Login server authenticates, storing temp token against login token. > > Login server redirects to app (no token in url) > > > You've moved a token from the app url by generating an extra HTTP request. > This is more efficient? If you're really that concerned about a token being > in a url. Not really, just an added benefit, mostly cosmetic, not important to the overall scheme. > > > > > Application sees temp token, checks against backend, gets login token. > > > You should never have the login/TGT token. Its a SECRET between the user > and the CAS server. Its NOT to be seen by anyone else. Its YOUR key to > seamlessly logging into other applications. Alright, call it a long term service ticket, then. > > > > > > Temp token is invalidated, login token is stored. > > Successive accesses to the app cause single validation of login token > > against backend, if logged out, repeat process. > > > So you want to revalidate a token on every request? Who are you to say that > your application's access is determined by the SSO session? Besides, most > application servers have solved the session problem. I kind of figured that would be the main goal, to leave your login overhead to the SSO, including timeouts and logouts etc. In the case of not I can see why the current design is the way it is. I am looking more toward a central SSO to manage the login "session" (login/timeout/logout). > > This would not only prevent the need for the redirects combined with > > a backend call, but would make things like AJAX calls work better (I > > believe). Single sign out would become a non issue, and login caching > > would be much less necessary. > > For the most part AJAX calls work fine as long as you protected the > application correctly. Have you actually tried it? I'm not really sure > what your issue is with a redirect. Its definitely more efficient than all > the backend calls you've added. > > Also, what is "login caching" ? We don't have that anywhere in our > documentation, and you keep referencing it. I admit this came from another site talking about CAS https://sp.princeton.edu/oit/sdp/cas/Wiki%20Pages/Home.aspx under Best Practices, though it sounded feasible. > > Again, please read and understand the multitude of existing authentication > protocols including CAS, OpenID, and SAML. > > I would not be surprised if I have missed something and am totally > > wrong, but I can't see any more holes in it than the existing system. > > > > -- > > www.suave.net - Anthony Ball - [email protected] > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Classic: A book which people praise and don't read... - Mark Twain > > > > > > -- > > 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] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Question anything that starts "Obviously..." -- 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
