Hi, Sam. Responses inline. On Tue, Feb 14, 2012 at 12:07 AM, Sam Zilverberg <[email protected]>wrote:
> 1) Do you use the "RestartResponseAtInterceptPageException" to redirect > users to the cas site when the user is not logged in and the cookie is not > present, or something else? > 2) Do you allow loging in also through the "normal" sites, not using the > cas? > We do not have a single authentication application; each application has the ability to authenticate the user and create the site-wide cookie. That said, yes, we use RestartResponseAtInterceptPage in that situation. > 3) Shared data store - is this a wicket/java object or just any > resource(like db) that both apps have access to? We use a relational database. I intentionally left my statement vague, though, since depending on your deployment there are multiple viable approaches to sharing the set of active sessions. > 4) Did you override some of wicket session store methods to support the > extraction of the id from the shared data store? > I assume you mean "id *for* the shared data store", and no it's just o.a.w.Session.get().getId() which is public. I don't know why we selected that unique ID though; it's really arbitrary. > 5) Session expiration -where do you add a session expiration listener? on > the wicket app level or in the web.xml? > We use web.xml. The only reason ISessionStore#registerUnboundListener() didn't work is because we needed to grab something out of the underlying HttpSession which isn't exposed to UnboundListeners. But that requirement is unique to our app. For further context, we use this to allow customization of our application on a client-by-client basis. Most of our clients use our "generic" app, but we can extend the app with custom development for larger/paying clients while minimizing impact to shared functionality. These clients can authenticate from the generic login page, and then get HTTP redirected and immediately logged into their custom app. Hope that helps! Dan > On Tue, Feb 14, 2012 at 12:58 AM, Dan Retzlaff <[email protected]> > wrote: > > > Hi Sam, > > > > We have a similar use case, and we use a home-grown approach within > Wicket: > > 1. The authenticating application persists a session ID into a shared > data > > store, and puts the ID into a new site-wide cookie. We use Wicket's > > Session#getId() for the ID, but could equivalently use UUID.randomUUID(). > > 2. When other apps' IAuthorizationStrategy detects an > > unauthorized/unauthenticated request, it tries to authenticate using this > > site-wide cookie. It basically just verifies that the session ID in the > > cookie corresponds to an active session in the shared data store. > > > > One thing to consider is your session expiration/logout logic. Our use > case > > is more like "user handoff" than concurrent Wicket sessions, and we have > a > > session expiration listener that invalidates the session in the shared > data > > store from the "owning" application. If your use case is not so simple, > > then you'll have to define your own site-wide authentication expiration > > event(s). > > > > On Mon, Feb 13, 2012 at 1:55 PM, Sam Zilverberg <[email protected] > > >wrote: > > > > > Hi, > > > > > > Our base wicket app is deploy around 40-50 times on a couple of > tomcats. > > > Each instance has a different configuration but the code base is the > same > > > app. > > > Each instance has its own context and it looks something like this: > > > app a : baseurl/a > > > app baba: baseurl/baba > > > > > > Currently the authentication and authorization for each site is handled > > by > > > the wicket app assigned to that context. > > > We implemented IAuhorizationStrategy and are using the signin page from > > the > > > examples + captcha after a couple of tries. > > > > > > We want an app at baseurl/login that will take care of loging in > instead > > of > > > all the different apps doing it for themselves. > > > Whats the best way to implement such a CAS mechanism? (preferably using > > > wicket, spring is ok too) > > > > > > Thanks, > > > Sam. > > > > > >
