Wicket has a nice mechanism for plugging in security whereby all components (including pages) have three cross-cutting hooks which can be validated by a security rule –
- Instantiation
- Render
- Enable
You can build your own security framework using the IAuthorizationStrategy interface and setting an appropriate implementation in your Wicket Application class.
Alternatively, you can leverage a simple security framework that is included in my open source library visural-wicket.
Visural-wicket’s security framework really is just the “glue” between Wicket’s IAuthorizationStrategy and something that you can start using immediately to control component level security.
There are two key interfaces – IClient and IPrivilege. The former represents some client of the application, generally a logged in user. The latter represents some security rule which is applied on rendering or enabling of a component.
They’re really simple interfaces -
/**
* A client is any user of your system, i.e. in most cases an authenticated User.
*/
public interface IClient < T extends Serializable> {
/**
* Return any unique identifier.
* @return
*/
T getId();
}
/**
* A privilege is any condition that can be evaluated with respect to a {@link IClient}.
*/
public interface IPrivilege < T extends IClient> {
/**
* Determine whether the privilege applies to the client.
* @param client
* @return
*/
boolean isGrantedToClient(T client);
}
In your application class you provide some glue to define how to retrieve the current IClient (e.g. from the session) –
public class MyApp extends Application {
public void init() {
// ...
getSecuritySettings().setAuthorizationStrategy(new com.visural.wicket.security.AuthorizationStrategy(new IClientProvider() {
public IClient getCurrentClient() {
return userService.getCurrentUser(); // for example
}
}));
// ...
}
}
Then any component which implements ISecureRenderInstance or ISecureEnableInstance can define the privilege required to display or enable it –
public class MyPage extends WebPage implements ISecureRenderInstance {
// ...
public IPrivilege getRenderPrivilege() {
return new IPrivilege < User>() {
public boolean isGrantedToClient(User client) {
return client != null && client.isAdmin();
}
};
// instead of returning a anonymous class like this, you could also
// package up common privileges into a singleton instance,
// e.g. return Privilege.ADMIN;
}
}
Wicket and visural-wicket then work in conjunction to ensure that the privileges get evaluated automatically at run-time. Unlike manually coded security which is mixed with other visibility logic, you can guarantee that no component that fails its security check can get rendered to a user that shouldn’t see it. You can also define common security rules as privileges in your code base and refer to them from many pages and components rather than duplicating similar logic across the application.
It’s a simple security mechanism which is designed to fit in with pretty much any app. I hope others find it useful too.
an interesting read about the Atari 2600 (or Atari VCS as it was orginally known).
