Apache Rampart is the security module of Axis2 which implements the specifications of WS-Security stack. The objective of this Google Summer of Code project is to improve the tests of Rampart in such a way that it covers all the possible scenarios including negative scenarios and the feature additions which do not have tests at the moment. Tests for Binding level policy configuration, code generated stubs and for secure MTOM and tests for negative scenarios will be implemented under this project.
At present with the high adaption rate of SOA, web services technologies play a major role in the SOA arena. With the increasing popularity, the requirement for fulfilling different aspects of web services like security, reliability has become more important than ever. Today, people/organizations are exchanging sensitive information using web services, thus enforcing the security aspect of the web services. It should be ensured that the main properties of information security such as confidentiality, integrity, authentication and non-repudiation are preserved in those operations.
Apache Rampart caters the security requirements enforced on the web services. It is the security module of Apache Axis2 which is a widely used web services engine. Rampart implements the set of specifications in the WS-Security stack such as WS - Security 1.0/1.1, WS - Security Policy - 1.1/1.2, WS – Trust etc. Apache Rampart is currently in version 1.4 for and it has become a stable security implementation for web services.
Testing is crucial for any software and same applies for Rampart as well. Implementing tests for a software module like Rampart is crucial as there are different scenarios to be tested in addition to the features. So it is of great importance to have a solid testing mechanism for Rampart. At the moment, there are some tests are implemented for Rampart. But it has to evolve further to cover all possible scenarios and new feature additions.
The objective of this project is to improve the Rampart tests. New tests will be added or the existing tests will be improved to cover the relevant scenarios and features during the implementation phase. With the help of the Rampart community, it is identified that the tests for the following cases/ scenarios are of higher importance
1. Tests for negative scenarios
- Testing for negative scenarios is crucial in testing of security implementations. The behaviour of the module/application under the non-preferred conditions is tested here. Some of the negative scenarios for testing in Rampart are empty security headers, absence of some of the security headers, improper encryptions, etc.
2. Binding level policy configuration
- According to the WS – Policy specification, security should be enforced in the binding level, and it does not encourage enforcing security at the service level. Axis2 supports enforcing security at the binding level. But the Rampart tests are still using older configurations. So it is required to have tests for the new configuration.
- Also there are three levels in the binding hierarchy, namely Binding level, Binding operation level and Binding message level. So tests should be added to Rampart covering all these levels.
- In addition to this, implementing tests for policies attached at different levels like message level and operation level will add more value into this project.
3. Improving the tests to cover code generated stubs
- Tests should be included so that the stub generated from the WSDL is used rather than the Service Client. These tests will help to check the WSDL generation and code generation capabilities when security policies are attached to the service.
4. Test cases for secure MTOM (Message Transmission Optimisation Mechanism)
- MTOM is a methodology used for transmitting binary data in web services. Securing the messages containing MTOM attachments is an area which needs to have more tests.
With the feedback from Rampart community, I was able to decide on the sequence of implementations for these tests. Already there are some tests implemented for Rampart which is available in the Rampart-test module. So I have started going through them thoroughly to get a proper idea about how to implement the tests. As a start, I have already created a JIRA issue for the unavailability of test cases for SignedElements and submitted a patch containing the test case along with the necessary policy file and services.xml file . And I will keep on submitting patches for the existing JIRAs as it might help me to sharpen my knowledge about Rampart. The above mentioned tests will be implemented independently and submitted to the code repository during the implementation of the project.
In addition to fulfilling the above mentioned functional requirements, I will pay attention to the aspects like coding standards of Rampart, best programming practices and readability and clarity of the code.
Community is the most imperative factor in open source software development. I will try my best to maintain a healthy communication with the Rampart community though out the project duration ensuring the visibility and transparency aspects of the project is preserved. I will try to involve the community in every phase of the project as much as possible. Since Rampart is influenced by Axis2, Axis2 community will be a good source of knowledge in some cases. So I will have to work with two active communities at the same time which would be a great experience for me. I have already started a thread in the Rampart developer list discussing about this project . A wiki page will be maintained separately indicating the progress of the project.
(April 30 – May 22) - Getting further familiarized with the Rampart project.
(May 23 – July 5) – Implementation phase 1
- Test for Binding level policy configuration
- Improving the tests to cover code generated stubs
(July 6 - July 13) - Mid - term evaluation
(July 14 – August 10) - Implementation phase 2
- Tests for negative scenarios
- Test cases for secure MTOM
(August 11 – August 17) – Finalizing the code and necessary documentation
(August 17) - Final evaluation
I am Thilina Mahesh Buddhika, a Final Year Undergraduate of University of Moratuwa, Sri Lanka, specializing in the field of Computer Science and Engineering.
I have been working with Java technologies for almost four years. I have developed a fair amount J2EE and J2ME applications. And I have a good exposure to SOA, especially to web services. I have worked with Apache Axis2, Apache Synapse and Apache Tuscany projects where I have gathered a lot of knowledge. Working in these projects helped me to get myself exposed to the open source development.
I have successfully completed a Google Summer of Code project in 2008, implementing a Geronimo Admin Console Extension for Apache Tuscany under the supervision of Ant Elder. With the experience and exposure I got from last year's GSoC project, I will be able to complete this project successfully.
I have developed a JRuby Binding for Apache Axis2 during my internship period. I also have developed a mediator for Apache Synapse, which is called as URLRewrite Mediator .
With all these projects I have got a good exposure to the open source world, especially to Apache projects. I am familiar with Apache Axiom, Apache Maven, Apache Ant, Subversion and Apache Tomcat which are widely used in Apache projects.
 - https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12421871
 - http://mail-archives.apache.org/mod_mbox/ws-rampart-dev/200903.mbox/%3C930503ab0903280815s6eb7614s3e44fac4b53096e@mail.gmail.com%3E
 - http://code.google.com/soc/2008/asf/appinfo.html?csaid=927C85CCBC3F2802
 - http://esbsite.org/resources.jsp?path=/mediators/thilinamb/URLRewrite%20Mediator