Secure Messaging with Apache Rampart/Java - Ruchith Fernando
- By Ruchith Fernando
- 8 Feb, 2007
- Reads: 16419
Ruchith takes a moment to talk about Apache Rampart and how it implements the security related Web service specifications for Apache Axis2. He also extends an invitation to all those buzzing minds out there to get on the Rampart bandwagon!
Ruchith Fernando is an Apache committer and a PMC member of the Apache Web services project. He actively contributes to Apache Rampart and Apache WSS4J, where he is currently the release manager. He also contributes to the Apache Axiom and Apache Axis2 projects. Ruchith works full time at WSO2 as the product manager of the WSO2 Identity Solution, while representing WSO2 in the OASIS WS-SecureExchange (WS-SX) technical committee and the W3C WS-SecurityPolicy working group.
Oxygen Tank (OT): What is Rampart?
Ruchith: Apache Rampart/Java is the tool kit that provides the implementation of security related WS-* specifications for Apache Axis2/Java. The latest version -1.1 was released in December 2006. This release included implementations of WS-Security, WS-Trust, WS-SecureConversation, and WS-SecurityPolicy specifications.
OT: How does it work with Axis2?
Ruchith: Rampart introduces two sets of handlers to the Security phase of Axis2 inflow and outflow. Developers of the Web services or clients can configure Rampart according to their security requirements using various configuration mechanisms available. Rampart is structured in a way where it mainly relies on Apache XML security and Apache WSS4J that provide the core components to produce and process secured messages. We also use our own DOM (Document Object Model) implementation called DOOM. It also uses opensaml for SAML support.
OT: Why do you use your own DOM implementation?
Ruchith: As you know Axis2 is based on an XML infoset representation called AXIOM. But WSS4J and XML Security use DOM as the API to manipulate XML. We had to find a way to bridge this gap. Therefore, we implemented DOM, which is also an AXIOM implementation. This is called DOOM. The advantage of using DOOM is that we don't have to convert AXIOM to DOM and vice versa before and after processing the messages. This also allows us to enable AXIOM features such as MTOM optimization of base64 content.
OT: What are the main components available in the Rampart distribution?
Ruchith: First of all we have the Rampart module. This module enables a user or a developer to provide the basic security features according to the WS-Security specification. For example, with the Rampart module, you can carry out authentication with a Username Token, ensure message confidentiality with encryption, and establish message integrity and non repudiation using the signature.
Then we have the Rahas module which enables any service to act as a Security Token Service (STS). This module comes into play when configuring a service or a client to exchange messages in a security context according to the WS-SecureConversation protocols.
We also have two sets of samples that demonstrate the Rampart 1.0 configuration in creating and processing secure messages and a new WS-SecurityPolicy based configuration of Rampart.
OT: What are the new features introduced in Apache Rampart 1.1?
Ruchith: The unique feature in this release is that Rampart also provides an implementation of WS-SecurityPolicy, where policies are used as the configuration model. This configuration model also uses a set of Apache Rampart specific policy assertions. This is because the policy assertions provided in WS-SecurityPolicy specification are not sufficient to meet all the configuration requirements of Rampart. However, a service that is configured with Rampart will filter the Rampart specific configuration information when serving meta data requests such as “?wsdl”
We also introduced support for Secure Reliable Messaging scenarios where Rampart works with the Apache Sandesha2 module to establish a security context in which the RM sequence can operate. Rampart will carryout the WS-SecureConversation handshake with the other participant in the message exchange, and then all the subsequent messages will be secured using this established security context.
WS-Trust support introduced in this release provides developers with an Axis2 module to enable a service to act as a security token service. This implementation of WS-Trust allows service developers to issue, renew, or cancel any type of security token as required, by writing simple pieces of Java code that plugs into the security token service framework. It should be noted that the WS-Trust implementation contains experimental support for the WS-SX version of the WS-Trust specification.
OT: How can others contribute to Apache Rampart and what can they work on?
Ruchith: We just moved Rampart out of the Axis2 codebase, and placed it as a sub-project of the Apache Web services project. The subversion repository is available at https://svn.apache.org/repos/asf/webservices/rampart/trunk/java Users and developers can post questions regarding Rampart to email@example.com. We also have a separate issue tracking system project at https://issues.apache.org/jira/browse/RAMPART
If someone wants to contribute, the best approach is to first use Rampart to meet their web services' security requirements. Then, when they come across areas for improvement, they can implement those features and send the patches. Also, if someone finds a bug in Rampart, they can report it using JIRA, our issue tracking system mentioned earlier. In addition to that, just like most other Open Source projects, we can use a lot of help with documentation. So do send your patches!!
OT: Thank you very much for your time and enthusiasm!
Ruchith: You are most welcome!
Apache Rampart/Java- http://wso2.org/projects/rampart/java
Apache Axis2/Java- http://ws.apache.org/axis2
Apache Axis2/Java Modules- http://ws.apache.org/axis2/modules/index.html