A couple of implementation questions: 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? 3) Shared data store - is this a wicket/java object or just any resource(like db) that both apps have access to? 4) Did you override some of wicket session store methods to support the extraction of the id from the shared data store? 5) Session expiration -where do you add a session expiration listener? on the wicket app level or in the web.xml?
Thanks a lot for the help so far. I started looking this kind of info a couple of days ago but couldn't find anything useful. I only found info about implementation using the container (tomcat) or spring-security (which i don't use). 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. > > >
