Lenny, Andres Thanks for your replies. I'll take a look at using CAS as well as writing to the cookie with a filter.
-Vijay On 12/7/05, Lenny Marks <[EMAIL PROTECTED]> wrote: > We also use CAS to accomplish single sign-on across multiple servers. > We actually have several apps running on each server (in Tomcat) behind > a load balancer. The only thing that doesn't work quite the way we'd > like is that when the user logs out, the CAS token is invalidated and > the HttpSession for that app is terminated. However, if the user is > already logged into another app on a different backend server(usually > in a different tab/window), that session is not terminated because the > HttpSession is already established. Preferably, we'd like to have > single logout and completely hide the fact that the user is actually > accessing multiple applications each on one of several backend servers. > I'm sure there is a setting that tells Acegi to consult the CAS server > for each request, but that would be too time consuming. > > I also did some minor tweaking to make everything work regardless of > whether the app is accessed through the load balancer or directly at > the backend. > > See: > http://sourceforge.net/mailarchive/message.php?msg_id=12208592 > > -lenny > > On Dec 7, 2005, at 1:53 PM, March, Andres wrote: > > > 1. I believe you can write the cookie in a class that is chained as a > > filter in the filter to bean proxy. There are plenty of other > > options. The main concern is the order of operations. > > 2. Depends on your app requirements. If it is a simple auth token, > > you may not need db access. But remember if you are not using https, > > your data in the cookie is at risk. > > > > Another option I would suggest is to use CAS. It would handle > > validating the authentication each time the user hits a new server. > > You would do the authorization piece only when necessary. This is > > definitely a more complex set up (with its own concerns) but for me it > > is preferable. You could also look at partial http session clustering > > but we all know how that usually goes... > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On > >> Behalf Of > >> Vijay Varadan > >> Sent: Tuesday, December 06, 2005 11:13 PM > >> To: [email protected] > >> Subject: [Acegisecurity-developer] How can Acegi be used in a webfarm > >> without HttpSession? > >> > >> Acegi newbie here. :-) > >> > >> I did a search in the mailing list archives to see if there are any > >> posts on how to use Acegi in a webfarm, but I couldn't find any. In > >> case I'm not clear, I have a single web application that I'd like to > >> deploy on multiple web servers behind a load balancer and allow the > >> users to be able to bounce between the servers for various requests > >> within a "session" - of course, since a user can hit any of the > >> multiple web servers behind the load balancer, the session I'm > >> referring to is not an HttpSession object, but to the general meaning > >> of the term session as applied to a user's interaction with a web > >> site. > >> > >> From what I've seen of the Acegi source code and samples, the context > >> information seems to either be tied to the HttpSession (optionally > >> stored in EhCache) - in my situation, I would like to specify some > >> information in an encrypted cookie that contains among other things > >> the session start time, login-status, username if applicable and > >> retrieve the relevant data without using any cache (such as EhCache) > >> from the DB for each request. (Note that we do this is a conscious > >> trade-off we're making to enable a better user experience in case a > >> web server goes down and also to allow operations to be able to take > >> servers in and out of rotation as needed.) > >> > >> What exactly do I need to do to: > >> 1. write the cookie w/ the encrypted information? i.e. where do I > >> do > >> this? > >> 2. read the cookie to get the relevant information to retrieve the > >> user record from the DB and stuff it into the threadlocal context? > >> i.e. where do I do this? > >> > >> Do I need to write my own replacement for > >> HttpSessionContextIntegrationFilter? i.e. one that will do the work of > >> looking for the appropriate cookie, retrieve the authetication object > >> and stuff it into the thread local security context? > >> > >> > >> Thanks > >> Vijay > >> NHu > >> > >> ~z^zzjɺ{ > >> > >> ,H4i > > ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÓ†+ù޵隊X¬²š'²ŠÞu¼ÿJ™nžB'sð > > èÊ‹êm†º.‚hø¥zÇè(r)šènW¦³ô¢ŸÃ£ 塧m > > [EMAIL PROTECTED],º·âž a{›ü3–4³€ > > #ËPÒÿ†ÛiÿÿÚvÏè±Ùÿr‰¿ý§ÿ‰ë~ÿjYhsøëŸè‰Éÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ > > ÿÿñè™ïá¶Úÿÿöœz¬yË«ŠÜÿ¢¸
