Testing that Service methods are Secured

Recently I had to quickly secure the service layer of a web application I was working on. I resorted to using AspectJ in order not to have my security related code scattered across the service layer and to also not to touch the service layer code since it was being used in multiple places. Furthermore, Spring was not being used, cause otherwise probably I would have used Spring Security and their annotations. Another benefit that using AspectJ gave us was that we could weave in the security aspects whenever needed. However, this is not the topic of this blog. Since I was the person who wrote the point cuts and the aspects however was not the only one working on the service layer, I wanted to make sure that nobody would add a new method which did not match any of the point cuts and thus is not advised with the security aspects. To make things slightly more complicated, not every method needed to be secured. This approach also helped me while I was defining the point cuts since it automatically identified entry points that have not yet been secured.

What I did was created an abstract test which given a set of interfaces and the service object, will call all the methods on this service object, and fail if any method does not throw a security exception or throws some other exception. I also added the facility to pass a string array of methods that should be ignored. So all I had to do was to extend this test for every service. I still needed to test each service separately to make sure that the methods could be invoked with the right credentials but the abstract test would ensure that all the methods are secured.

If any new method is added which is not captured by any of the security point cuts, then this test will fail and will also identify the method that is not secured.

You can find the code on github here. What I created to illustrate this here is a simple Spring project with a simple service which I accidentally forgot to secure one method. In this project I am using spring security and annotations for ease. The core of the implementation is the AbtractSecurity test.


Then we have a simple test that was implemented which extends the AbstractSecurity test and implements the two required methods, getService which returns the service to be tested and getInterfaceClasses which returns an array of classes.


This might seem like a simple approach, and well, it is and there are a number of ways we could improve on this. For example try to move away from test extension but somehow do this declaratively.

In short, whenever you are developing, think of ways that tests can help you. One should look at tests as tools which empower the developer and aid the developer and not some pesky thing you have to do in order to increase the code coverage report on Jenkins!

Book Review: OSGi in Depth

OSGi in Depth Cover

A few weeks ago I got my hands on OSGi in Depth from Manning. The book is well written and I would give it a 4 out of 5. The book is not targeted for beginners but rather to developers who know the basics of OSGi and are now planning to develop an enterprise application using OSGi. I found the introduction to OSGi slightly lacking in my opinion, however the rest of the book discusses topics which are very interesting and which I had a hard time to find details elsewhere.

The first 4 chapters introduce OSGi and the case study. The interesting parts start from chapter 6 onwards. Chapter 6 introduces events and how they can be used to decouple your modules. I found chapter 7 very useful since it discusses how to do persistence in an OSGi environment. This chapters discusses how to make available database connection factories without needing to import the specific packages and how to do JPA. I will be using this knowledge pretty soon in a project I am working on so I am quite happy to have found this topic discussed in detail here together with the accompanying lab.

Transactions are discussed in the following chapter, chapter 8. What I found interesting was not the discussion about transactions but rather how you can create a container to delegate the transactional related calls to the container instead of having it scattered in your business logic. The method introduced here will be polished as we go through the book, but what I found interesting was that the author showed that any behaviour that you want shared across bundles can be packaged nicely in extensions that can be applied to the bundles through facilities that OSGi provides. I found this refreshing and made me look at OSGi application development in a different way.

Chapter 9 discussed how OSGi can be made to work with JavaEE through JNDI. This was quite an interesting topic but not much to me personally. The same I can say about chapter 10, well written but I typically would use some other mechanism to invoke remote services, but, never the less it was interesting to see how one would invoke remote services using OSGi. The following chapter grabbed my interest again. Material about the best ways to deploy OSGi applications is slightly limiting. The discussion about how to handle misbehaving bundles was quite interesting, but something that I will be probably using is the File Install which the author introduced here. The file install gives you the possibility to manage you application bundles in the same way as you would manage your web applications through an install directory. For more information you can read about the Apache Felix File Install here.

The JMX discussion in chapter 12 was interesting but not as good as chapter 13 where the author extends Blueprint. This was a very interesting chapter cause it shows a very good way of packaging code that cross cuts multiple bundles and how to have it declaratively applied to the business logic in these bundles. The discussion about blueprint is limited, in fact the author directs you to the book OSGi in Action for a more complete discussion of blueprint. However I believe that the author fills in a gap since he explains how blueprint works underneath the hood and shows how you can do a similar extension, but finally this extension is integrated nicely with blueprint, including a custom XML namespace. In short, reading the entire book was worth it for the final chapter!

To wrap things up, this is quite a good book for anybody who wants to implement enterprise OSGi applications. If you are a beginner and would like to learn OSGi for its own right, I would go with some other book, however, from this book, I would say that the chapters about persistence, transactions, deployment and blueprint are very useful. I also liked the way that the author focused on showing how to create application containers which run on OSGi in which you can run your own custom applications. I guess that is why the author called the book, OSGi in depth.

My First Blog

This will be my first blog entry, my first of many hopefully. I thought I would start with a brief description of who I am and what I am interested in. As you might have guessed, I am interested in anything which has to do with Integration and any other garnish which might go well with such topics.

I was introduced to integration and open source in my third year of University when I got employed by Ross Mason the creator of Mule. After that summer, I was hooked, and will always have a soft spot for Mule.

After 5 years of working with Mule and everything related to it, I changed company and the focus shifted to Servicemix. I must be honest, I was slightly hostile to "ServiceMix", however luckily it had past the JBI phase so the combination of OSGI powered by Karaf and routing powered with Camel is quite appealing. So probably my interests will focus a bit more on OSGI.

I am also interested in other topics and technologies. I think I am right now a big fan of Spring Roo, especially with version 1.2 coming up with the Services and multi-module support. I also like to thinker with Android and GWT. Something that I am looking forward to right now is to have some time to play with Vaadin since the creators are just a 2hour train ride from Helsinki in the city of Turku.

Well, I hope you will find interesting topics in this blog and find this blog interesting!