You can use Spring security with wicket auth-roles, I works out pretty nice compared to the alternatives. iirc You need do your normal Spring setup, extend AuthenticatedWicketApplication, and AuthenticatedSession which has an authenticate method you'll call your UserDetails bean from.
Outdated Link https://cwiki.apache.org/WICKET/spring-security-and-wicket-auth-roles.html#SpringSecurityandWicket-auth-roles-ExampleWicket1.3.5 On Tue, Apr 27, 2010 at 7:20 PM, Jimi <jimi.hulleg...@mogul.com> wrote: > > Hi, > > I'm curious to know what security frameworks you guys are using. > > The reason I'm asking is because I recently tried out Spring Security > together with a simple wicket web application, and was amazed on how easy > it > was. I applied the steps mentioned in their Pet Clinic tutorial > ( > http://static.springsource.org/spring-security/site/petclinic-tutorial.html > ) > more or less exactly as they are, and I didn't have to write a single line > of code. All was done using configuration. And even when I replaced the > hard > coded list of users (with their passwords and groups) with my custom > authentication provider (or actually custom UserDetailsService) I only had > two write two simple classes that implemented two very simple and logical > interfaces respectively, that used my pre existing hibernate configuration > and POJOs. > > BUT... when I wanted to replace the auto generated login screen (which > worked great, but just didn't look very appealing) with a custom login page > I quickly ran into trouble. If the login was successful then all was fine. > But for the cases when the login failed for some reason (like incorrect > username/password or database being down) I was having problems accessing > the error cause. Because as far as I could tell this message (actually an > Exception subclass) was only available as a http session attribute. And it > seems that Wicket does everything to hide those from the user, discourages > the use of the getHttpServletRequest() and the session attributes of the > wicket session object only seems to include attributes with a specific > wicket-prefix (like "wicket:wicket.myProject:") which of course caused my > precious Spring Security session attributes to be unavailable. > > It was then I started thinking that Spring Security maybe isn't the best > security framework together with Wicket. So I started looking around for > other alternatives. Wicket-security/WASP/SWARM (still not sure what is > what) > and "wicket auth roles" where the first two, and some time later I also > heard about wicket-shiro. > > But all these three seemed to have one or more of the following down sides > that irritated me when I evaluated them: > > 1. Missing official site. [wicket auth roles] At least I can't find it. > > 2. Seems old. [wicket auth roles + WASP/SWARM] Found a two year old > discussion labeled "is wicket-auth-roles discontinued?". And the comments > on > the "Getting started with Swarm" wiki page is from 2007 and 2008, plus that > they talk about Acegi (the old name for Spring Security) and the project > has > dependencies to Wicket 1.3 and Spring 2.0. > > 3. Doesn't seem stable. [wicket-shiro] No maven repository (you have to > check out trunk and build yourself) and has three different SNAPSHOT > dependencies. > > 4. Seems to require a lot of different project specific java classes. [all > three]. > > > The last point, number 4, is a really big down side if you ask me. Keep in > mind that I was able to integrate Spring Security almost completely in my > wicket web application with very little new java code needed. And that is a > good thing, because project specific code is of course much less tested and > tried compared to official stable code of reputable frameworks. Plus that I > don't have to reinvent the wheel, considering the simple authentication and > authorization demands of my project. The only thing stopping me was this > stupid error message in the "unavailable" http session attribute. > > I actually started converting my project into a WASP/SWARM project, using > the example project from > > http://out-println.blogspot.com/2009/02/wicket-swarm-spring-security-how-to.html > , > but after creating class after class after class of in-my-eyes boilerplate > code I got the overwhelming feeling that I was making my project more and > more dirty. And, more importantly, I got the feeling that this shouldn't be > so complicated. Other people surely have done this before, and maybe there > is a good, stable and official framework/plugin/whatever that makes Spring > Security and Wicket integration into a breeze. Which it really was when I > followed the Pet Clinic tutorial (see URL above), since that used the auto > generated login form. > > So, any input from you guys? What do you use to secure your wicket web > sites? Or maybe someone can explain how to best solve my Wicket+Spring > Security problem with the "hidden" http session attributes? > > Also, I hope I didn't step on anybody's toes with my list of down sides. > Maybe I just haven't found the right web pages that document these > frameworks(?) and how easy it can be to use them. Tips more then welcome! > > Regards > /Jimi Hullegård > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Wicket-security-what-are-the-best-options-Spring-Security-reached-almost-all-the-way-tp2068415p2068415.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
