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. >
