we just finished (yesterday) to implement authorization in a wicket app.
basically, we end up with integration of WASP, Spring Security and a
little beat of SWARM with a home made User-Group-Permission mechanism
that is really simple and string based, and persisted on DB (via
hibernate)
We have an implementation of WaspAuthorizationStrategy with basicalle
login, logoff and this other method implemented:
@Override
public boolean isComponentAuthorized(Component component,
WaspAction action) {
if (component instanceof SecureWebPage) {
return isUserAuthenticated();
}
return checkPermission(component, action);
}
in our app, authenticated user can see all pages (so the first if),
but some component can have further restrictions, there is the
second method that goes into out custom permission check. In that
method, we ask spring the Authentication in the session, so we get the
User (a custom class) and from there we can check permissions.
If you are interested, I can write a more specific essay on our implementation.
I am happy with that becouse it integrates with wicket and spring
security using some of the mechanism and facility but without being a
slave of the framework, so the granularity of authorization is
completely domain-side and so are the permission definitions.
In the end, define a permission on a button you now need just to
change a Button with a SecureButton (that has a very trivial
implementation). Then we create a Permission on the DB (a string) for
that button in some specific Page and assign the Permission to some
group. That's it.
We stayed away from SWARM and its hive replacing it with a simpler
home made mechanism. We just use the SwarmAction to have the "access,
render, enable" granularity for components already built in.
Permission implemented the Spring Security interface called
GrantedAuthority, that is the way spring guys calls permissions. In
fact, both are just a string and we are perfectly integrated.
For the point:
. Authorization before being able to run methods in the service layer
I think that spring security is the way to go, it allows use AOP to
restrict a method call, with also filtering and so on. I had not the
change to experiment with it actually, but I know it can for sure :)
On Sun, Mar 8, 2009 at 5:20 PM, Kent Larsson <[email protected]> wrote:
> Hi,
>
> I know there has been some discussion on this. But I've had a hard
> time deciding how this project should use security anyway.
>
> The application in question is layered into three layers for
> presentation, services and persistence using Wicket, Spring and
> Hibernate.
>
> What we need:
> - Authentication
> - Authorization on pages, components
> - Authorization before being able to run methods in the service layer
> - Authorization for viewing/editing some domain objects using Access
> Control List's (ACL's)
>
> I have read Wicket in Action and it's custom security solution has some pros:
> - It's quite easy to understand
> - We have a lot of freedom in how to do authentication and authorization
>
> And some cons:
> - I don't know how to authorize calls of specific methods, and thus
> - All security will be in the presentation layer
> - It won't be usable if we want security on web services later (which
> we do not need now, so maybe this can be disregarded)
>
> It would be nice if we could have a common solution to our security
> needs that integrates well with Wicket and Spring. I know that the
> Auth Roles project is out there as well as Swarm. But I don't know
> which will meet our needs and which will most likely be an option to
> us when we later move to Wicket 1.4 or a higher version.
>
> Best regards,
> Kent
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
--
Daniele Dellafiore
http://blog.ildella.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
