Differences between revisions 6 and 7
Revision 6 as of 2008-07-09 20:05:23
Size: 8008
Comment:
Revision 7 as of 2009-09-20 23:35:17
Size: 8008
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

Google Summer of Code 2008 : Proposal

Project

Basic Security Profile (BSP) 1.0 Validation for Apache Rampart

Student

Heshan Suriyaarachchi

Email

heshan.suri@gmail.com

Blog

http://heshans.blogspot.com/

Project Title

Basic Security Profile (BSP) 1.0 Validation for Apache Rampart

Abstract

Apache Rampart is the security module of Axis2. It implements Web Service Security, WS-Secure Conversation, WS-Trust and WS-Security Policy specifications. Basic Security Profile 1.0 from web services interoperability organization defines a set of standards that further clarifies the ambiguities in other specifications with details. Even though Apache Rampart adheres to these standards when securing the messages, there is no proper validation done for BSP 1.0 standards in incoming messages. Purpose of this project is to implement a handler in Rampart which validates the incoming messages for BSP 1.0 standards.

Deliverables

1. Implementation of the BSP 1.0 validation handler

2. Junit tests for above module

3. Documentation to support continuation of the project

Overview

Apache Rampart is the security module of Axis2. It secures SOAP messages according to specifications in the WS-Security stack. Rampart currently doesn't validate the incoming SOAP message with Basic Security Profile (BSP) 1.0. This project intends to write a handler to validate the incoming SOAP message with BSP 1.0.

BSP 1.0 is an essential guide for ensuring secure, interoperable Web services. The WS-I Basic Security Profile 1.0 builds on the work already completed in WS-I's Basic Profile 1.1.The WS-I Basic Security Profile is an interoperability profile that addresses transport security, SOAP messaging security and other security considerations for WS-I's Basic Profile 1.1, Simple SOAP Binding Profile 1.0 and Attachments Profile 1.0. It is developed based on a set of guidelines such as interoperability, restriction vs. relaxation, future compatibility, compatibility with deployed services, conformance targets etc. The BSP 1.0 focuses on the interoperability characteristics of two technologies: HTTP over TLS and Web Services Security - SOAP Message Security. SOAP Message Security provides security protection for SOAP messages and applies even when a message passes through several intermediary way points, allowing various levels of protection for selected portions of a message. The BSP1.0 also incorporates Web Services Security: Username Token Profile, Web Services Security: X.509 Certificate Token Profile, Web Services Security: Kerberos Token Profile, Web Services Security: SAML Token Profile and Web Services Security: XRML Token Profile.

In Axis2 Server side the incoming SOAP message is first received by the transport listener and then it is given to the handler (a.k.a. Message Interceptor) chain. A handler will look at the header portion of the incoming SOAP message and it will either read, add or remove header(s). While reading, if the targeted handler cannot execute properly then it will throw an exception.

The BSP 1.0 validation handler will reside in the Rampart security module. It will check the incoming message whether it confirms to BSP 1.0. If it confirms to the BSP 1.0 the message will be sent forward for further processing, else a fault is generated and sent back to the client (without further processing). The user will have the privilege of turning on or turning off the BSP 1.0 validation using the rampart configuration. This handler can be integrated to Rampart build so that it can make sure that the messages generated by Rampart are BSP compliant. This will be an added advantage.

Project Plan

I have planned the project under 4 steps as follows.

Step 1: Initial Planning and Designing

I will have a look at current implementation of Apache Rampart and will create a basic design.

Estimated Completion: 21st May 2008

Step 2: Implementation

I would start working on the code. Deliverable(s): Prototype and documentation for mid evaluation

Estimated Completion: 2nd July 2008

Step 3: Improvements and Testing

Modifications or improvements suggested at the mid evaluation would be completed in this step. Crate Junit tests Deliverable(s): Prototype including Junit tests

Estimated Completion: 6th August 2008

Step 4: Final Product and Documents

With the completion of this step, will finish the handler to validate SOAP messages. Necessary documents would also be present with the final product. Deliverable(s): Final product and documentation

Estimated Completion: 13th August 2008

Biography

I am a 3rd year Computer Science undergraduate of University of Colombo School of Computing (UCSC), Sri Lanka. I have been involved in Open Source development regarding Web Services based on Apache Axis2/java.I would like to mention the open source projects that I have done and will give a brief explanation on them.

Jython Message Receiver I have written a python message receiver for Axis2/java using Jython. The incoming SOAP message is received by the Transport Listener(Axis2) and it is passed through the handler chain(Axis2). Then it is given to the Jython Message Receiver,Jython Message Receiver, will traverse through the AXIOM structure and retrieve the wanted information. This retrieved information is passed in to the python service. Then a AXIOM is created out of the returned object. Then it is sent back, through the handler chain and the Transport Listener.While doing this project I got familiar with Apache Axiom as well.

Python Deployer I have written a deployer for Axis2/java which will enable Axis2/java to expose services written in python. When it comes to the service deployment time, XML Schema should be generated out of the python service. To generate the schema; annotations should be read out of the python script. Python is a dynamically typed language as opposed to Java, which is a statically typed language. Therefore the dynamic python types should be mapped to static java types. This process is called a data binding. After the corresponding matching types are mapped, the XML Schema is created out of the service. The created XML Schema is given to axis2 engine. Then axis2 engine generates the WSDL out of the XML Schema.

Python-Client API for Apache Axis2/Java I have written Axis2/Java Python-Client API.A user can write a web service client in Python, using the Python-Client API. The API will provide support for WS standards such as WS-Addressing, WS-Security, WS-Reliable Messaging. WS-Security is achieved using Apache Rampart and WS-Reliable Messaging is achieved using WSO2 Mercury. This API will construct a Java web service client (with the help of Jython) out of the Python service client. Then the Java service client will get executed and the returned value is passed back to the python service client.

I'm really passionate about Open Source Software development and one of my aims was to participate in GSoC. I found this project appealing because I have been working with Web Services. If given the opportunity I believe that I can successfully complete this project and in return it will help me to enhance my software development experience, learn new things regarding security, test my skills and interact with the Rampart community. In addition to all this my prior knowledge of Axis2 and Axiom will help me to catch up with this project.

Mentor Information

Nandana Mihindukulasooriya

nandana@apache.org

References

http://ucsc.cmb.ac.lk

http://ws.apache.org/rampart/

http://www.developer.com/java/web/article.php/3529321

http://ws.apache.org/axis2/1_3/Axis2ArchitectureGuide.html#bmSOAPPM

http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html

http://www.ibm.com/developerworks/webservices/library/ws-apacheaxis2/

HeshanSuriyaarachchi/GSoC2008/proposal (last edited 2009-09-20 23:35:17 by localhost)