Introducing a security layer in your application architecture

Though of course it varies, in most applications you will encounter at least a view layer, a service layer and a data layer. Security will typically be applied on both the business layer as well as the view layer.

On the business layer security restricts access to your data and on the view layer security ensures the user in question only sees those view elements relevant to him/her. Quite often this results in security being implemented twice, violating the DRY (Don’t Repeat Yourself) principle. In this post we will discuss how we can introduce a security layer in your application architecture to facilitate re-use of security code in all layers.

In my previous post I discussed how to use Spring Expression Language (SpEL) in combination with Spring Security to implement complex (beyond role-based), unit-testable security logic. Some of you may have already anticipated that this pattern offers some hidden treasures not yet disclosed. In this post I will describe how we can put the techniques of my previous post to work to create a separate security layer in your applications that is useable in both the view layer and the business layer. In my examples I am using Apache Wicket for my view layer but the general idea should translate to any view technology you might be using.

Suppose we are adding a link in the view layer:
add(new TestSecurityLink("link1", "Possible non-working link") {
@Override
public String callSecuredMethod() {
return testService.getSecuredString(argument);
}
});

The service call is as follows (please refer to my previous post to understand what’s going here to secure the function):
@PreAuthorize("securityBean.isUserAllowedToGetSecuredString(#argument, principal)")
public String getSecuredString(String argument) {
return CLEARANCE_GRANTED;
}

And the security code reads:
public boolean isUserAllowedToGetSecuredString(String argument, User user) {
if (user.hasRole(SystemRoleName.ROLE_ADMIN)) {
if (argument.equals("foo")) {
return true;
}
}
return false;
}

In the current situation a user could potentially see the link even if he/she does not have the proper authentication to call the underlying service, resulting in an unfriendly user interface. So we need to add some logic to the view layer to ensure the link is only presented to the user when it is actually relevant. This is where the danger of duplication of security logic rears its ugly head. Let’s see how we can prevent this.

Reusing business layer security constraints in the view


Should we be implementing security on the business layer in a more traditional fashion, the security logic would be implemented both in the business layer and then once again in the methods determining visibility in the view layer. This is clearly undesirable as it introduces a maintenance nightmare and opens the door to a whole slew of security issues.

But remember that we introduced a mechanism to encapsulate our security code in a separate Java method in my previous post! In my example above you can see that I implemented this pattern in the @PreAuthorize annotation on the service call. We can now re-use this method call to determine the visibility of our sample link:
add(new TestSecurityLink("link1", "Working link") {
@Override
public String callSecuredMethod() {
return testService.getSecuredString(argument);
}

public boolean mayCallSecuredMethod(User user) {
return securityBean.isUserAllowedToGetSecuredString(argument, user);
}
});

The link is now using the same code as is being called from the SpEL expression in the business layer. You can imagine how this is a tremendous help in keeping your applications maintainable and keeping nasty security leaks out the door. You could take this concept even further and re-use the SpEL expression in your view layer… but I’ll leave that as a cliffhanger for a next blog post.

11 comments:

  1. It would be ideal if you proceed with this extraordinary work and I anticipate a greater amount of your marvelous blog entries.
    penetration testing

    ReplyDelete
  2. In this post we will discuss how we can introduce a security layer in your application architecture to facilitate re-use of security code in all layers. 312-50v10 exam dumps

    ReplyDelete
  3. Pretty good post. I just stumbled upon your blog and wanted to say that I have really enjoyed reading your blog posts. Any way I'll be subscribing to your feed and I hope you post again soon. Big thanks for the useful info. t shirt met tekst

    ReplyDelete
  4. I wanted to thank you for this great read!! I definitely enjoying every little bit of it I have you bookmarked to check out new stuff you post. hookah

    ReplyDelete
  5. Thank you very much for this great post. estilo de vida

    ReplyDelete
  6. I would like to thank you for the efforts you have made in writing this article. I am hoping the same best work from you in the future as well. In fact your creative writing abilities has inspired me to start my own Blog Engine blog now. Really the blogging is spreading its wings rapidly. Your write up is a fine example of it. Roblox APK Download Latest & Updated Version

    ReplyDelete
  7. This comment has been removed by the author.

    ReplyDelete
  8. Please continue this great work and I look forward to more of your awesome blog posts. safety n home

    ReplyDelete
  9. While single family homes are appraised by the value of recent sales of similar homes in your neighborhood, commercial real estate doesn't care about the value appreciation of other buildings.Haitch Conveyancing

    ReplyDelete
  10. Most people put a high priority on feeling safe and secure in their own homes, so taking measures to increase safety and protect against intruders when you are at home and burglars when you are away is important and home security door locks are a major consideration. Both the kind of lock and the way it is mounted matter. Iron security doors Melbourne

    ReplyDelete