Security using AspecJ
Today I will explain how I will be using AspecJ for security in my Ozkey Photo Album.
If you don’t know what aspects are I recommend you read about Aspect Oriented Programming first.
To explain why and how I will use aspects for security first I need to explain what ZK framework is and how the ZK framework actually works. In a nutshell ZK is the leading open source Ajax framework and in it’s core it has an event-driven engine. I will use a simple example to illustrate how it works.
We create the user interface a bit like HTML (but it is not HTML)
<?page title="Login" contentType="text/html;charset=UTF-8"?>
<zk>
<window title="Login" border="normal" width="400px" apply="security.LoginFowardComposer">
<grid>
<rows>
<row>Login: <textbox id="login"/></row>
<row>Password: <textbox id="password"/></row>
</rows>
</grid>
<button label="Login" id="loginBTN" />
<button label="Send money" id="sendMoneyBTN" />
</window>
</zk>
This is how it will look like

We then implement the “LoginFowardComposer” that extends the ZK “GenericForwardComposer”. This Class will be responsible for the definition and registration of the event listener for the “Login” and “Send money” button.
package security;
import ...
public class LoginFowardComposer extends GenericForwardComposer{
private static final long serialVersionUID = 1L;
private Textbox login;
private Textbox password;
private Button loginBTN;
private Label sendMoneyBTN;
public void onClick$loginBTN(Event event) throws Exception{
//check login and set the user
System.out.println("Login");
}
public void onClick$sendMoneyBTN(Event event) throws Exception{
// Send the money
System.out.println("$$$ send money $$$");
}
}
As you can see the there is nothing stopping the user from pressing the “send money” button at the moment. The correct thing to do would be to only enable the button after the user has logged in but in some cases disabling the button only looks like the function is disabled but the listener is still listening for the event so a hacker could send an Ajax request and trigger the event so we want to enforce security using aspects.
I will also use annotations so that we defined what events require no security e.g. login and what events require an “admin” role or an “owner” role.
Below is the enum for security roles:
public enum Role {ADMIN,OWNER,PUBLIC,MEMBER,NONE}
Below is the annotation interface that we will use to specify what role is needed for the event:
package security.aspect;
import java.lang.annotation.*;
public interface Security {
@Retention(RetentionPolicy.RUNTIME)
public @interface SecurityCheck {
Role level();
}
}
Now that we defined the roles and the annotation interface we can annotate each method in the login composer with the new annotations.
package security;
import ...
public class LoginFowardComposer extends GenericForwardComposer{
private static final long serialVersionUID = 1L;
private Textbox login;
private Textbox password;
private Button loginBTN;
private Label sendMoneyBTN;
@SecurityCheck(level=Role.NONE)
public void onClick$loginBTN(Event event) throws Exception{
//check login and set the user's role
if(login.getValue().equalsIgnoreCase(password.getValue())){
Sessions.getCurrent().setAttribute("ROLE",Role.OWNER);
}
}
@SecurityCheck(level=Role.OWNER)
public void onClick$sendMoneyBTN(Event event) throws Exception{
// Send the money
System.out.println("$$$ send money $$$");
}
}
As you can see the login event requires no security and once you login it assigns you a role. in this example you are assigned the “OWNER” role. this role needs to be checked for the “sendMoney” event and this check will be done in an aspect.
Below is the aspects that will enforce the security defined in the annotation.
pointcut checkSecurityLevel(security.aspect.Security.SecurityCheck annotation ):
execution(@SecurityCheck * *..*(..)) &&
@annotation(annotation);
void around( security.aspect.Security.SecurityCheck annotation):
checkSecurityLevel(annotation){
Role role = (Role) Sessions.getCurrent().getAttribute("ROLE");
if(role==null)role=Role.NONE;
System.out.println(">level Required:"+annotation.level());
System.out.println(">level actual:" + role.toString() );
if(Role.NONE.toString().equalsIgnoreCase(annotation.level().toString())){
proceed(annotation);
}else{
if(role== annotation.level()){
System.out.println("LOGIN TRUE");
proceed(annotation);
}else{
System.out.println("LOGIN FALSE");
}
}
As you can see above unless your ROLE is the same as the role needed the code will not execute. the problem with this method is that in the future a developer who does not know about how all this works could write a new event and not put a security annotation.
Security using AspecJ
Today I will explain how I will be using AspecJ for security in my Ozkey Photo Album.
If you don’t know what aspects are I recommend you read about Aspect Oriented Programming http://ozkey.com/notes/2010/aop101/ first.
To explain why and how I will use aspects for security first I need to explain what ZK framework is and how the ZK framework actually works. In a nutshell ZK is the leading open source Ajax framework and in it’s core it has an event-driven engine. I will use a simple example to illustrate how it works.
We create the user interface a bit like HTML (but it is not HTML)
<?page title=”Login” contentType=”text/html;charset=UTF-8″?>
<zk>
<window title=“Login” border=“normal” width=“300px” apply=“security.LoginFowardComposer”>
<grid>
<rows>
<row>Login: <textbox id=“login”/></row>
<row>Password: <textbox id=“password”/></row>
</rows>
</grid>
<button label=“Login” id=“loginBTN” />
<button label=“Show me the money” id=“showMoneyBTN” />
</window>
</zk>
We then implement the “LoginFowardComposer” that extends the ZK “GenericForwardComposer”. This Class will be responsible for the definition and registration of the event listener.
As you can see the there is nothing stopping the user from pressing the “send money” button at the moment. The correct thing to do would be to only enable the button after the user has logged in but in some cases disabling the button only looks like the function is disabled but the listener is still listening for the event so a hacker could send an Ajax request and trigger the event so we want to enforce security using aspects.
I will also use annotations so that we defined what events require no security e.g. login and what events require an “admin” role or an “owner” role.
Below is the enum for security roles:
Below is the annotation interface:
Below is the login composer with the new annotations.
Below is the aspects that will enforce the security defined in the annotation
the problem with this method is that in the future a developer who does not know about how all this works could write a new event and not put a security annotation.