Fernando Wermus-3 wrote: > > I am using shiro successfully with wicket. But I need to develop > authorization for services in the backend. >
Could you elaborate on your requirements a bit more? As a fellow Wicket developer who is also using Shiro, I would be interested in hearing how you have your application set up, and how you are dividing the security concerns between Wicket and backend. In my experience it has usually been easier to deal with authorization at the Wicket layer, because the UIs I build dictate that components need to be shown or hidden conditionally based on security concerns (e.g. "delete" link should be shown for admins, but not for other users). The nice thing about Wicket is that if a component is hidden, the action that component performs is inherently secured. There is no way for a user to invoke the onClick() code (i.e. perform the delete action) if the component is not being shown. So authorization at the Wicket layer goes a long way. I always hesitate moving authorization to the service layer, because there will inevitably be repetition of logic: the UI visibility checks at the Wicket layer will still be needed, plus there will be redundant service layer checks (e.g. securing the delete() method). For what it's worth, I agree that if you are going with an AOP solution with Wicket, Spring is your best bet. But before you overhaul your app to integrate Spring, I would first verify that AOP-style authorization of your service layer is really needed. In your backend, you can use assertions like SecurityUtils.getSubject().checkPermission(). That would not require Spring. You only need Spring if you want to use Shiro annotations or another AOP approach. -- Matt -- View this message in context: http://shiro-user.582556.n2.nabble.com/shiro-wicket-backend-tp5760310p5761393.html Sent from the Shiro User mailing list archive at Nabble.com.
