Rampart2. 1. Introduction. 2. Rampart

Transcription

1 Saliya P. Ekanayake, Sameera M. Jayasoma, Kalani C. Ruwanpathirana, and Isuru E. Suriarachchi Department of Computer Science & Engineering University of Moratuwa {esaliya, sameera.madushan, isurues, Abstract Apache Axis2, being the popular open source Web service middleware supports Web services security via a module named Apache., however, has performance issues due to its architecture and dependency over two external Apache projects. This paper talks on, which is the newly architected replacement for. The strengths of over are (i) high performance, (ii) improved Web services security measures based on Web services security related specifications, and (iii) new architecture supporting better extensibility. achieves these by means of its architecture and the use of Apache Axiom as the object model in manipulation of XML data. 1. Introduction Web services are used in many business applications today around the globe. Thus the security of Web services has become very important. The software industry has been developing middleware supporting secure Web service integration to business applications, as a result, in the past couple of years. Apache Axis2 (The term Apache will be omitted in future references to Apache Axis2. Moreover, this convention will be continued for all the Apache projects mentioned hereafter) [1] is the popular open source middleware, provided by the well known The Apache Software Foundation [2], which supports Web services integration with business applications. Axis2 is able to generate and process SOAP (formerly known as Simple Object Access Protocol) [3] messages leaving the user to consider only about the business logic (see Figure 1). The SOAP based web services are vulnerable to security attacks due to the fact of SOAP messages are being plain text. End-to-end protection measures provided by the HTTPS (Hyper Text Transfer Protocol over Secure Socket Layer) [4] are simply not enough to secure SOAP messages. Therefore, a separate set of specifications addresses the Web services security, of which implementations are mandatorily provided by Web services engines like Axis2. The extensible architecture of Axis2 consisting of handlers is responsible for generating and processing of SOAP messages (see Figure 2). A module developed for Axis2 can insert an additional set of handlers into the handler chain at a desired place to extend its functionality. Among other many extended features, Web services security too is provided by means of a module in Axis2. Apache [5], which is the particular module of interest, is stable in its functionality, yet suffers severely from low performance. We developed with the solely intention of providing a high performance replacement for. Additionally, overcomes several other drawbacks associated with as presented later in the paper. The following two sections of the paper introduce and the problem associated with it. The sections 4, 5, and 6 provide the insight into the design and development, evaluation, and test results of. The paper winds up with a discussion and conclusion on. 2. provides the implementations of many Web services security specifications. A few examples of such specifications are WS-Security [6], WS-Policy [7], WS- SecurityPolicy [8], and WS-Trust [9]., however, does not implement all these on its own, instead it relies on two other external libraries known as Apache WSS4J [10] and Apache XMLSec [11].

2 Request SOAP Web service client s business logic Axis2 Response SOAP Axis2 Web service provider s business logic Internet Figure 1: Web services integration with Axis2 3. Problem Axis2 API implementation is in fact a thin layer abstracting the functionality needed to secure SOAP messages. This is due to the fact that it depends on WSS4J and XMLSec which implements the core functionality of Web services security. The architecture of is illustrated in the following diagram. Handlers Transport Sender/Receiver Figure 2: Axis2 handler chain WSS4J is an implementation of the WS-Security specification. It takes care of SOAP level security features such as Encryption, Signature, Username Token and Timestamp. This project uses the object model DOM (Document Object Model) [12] in manipulating XML (extensible Markup Language) [13] documents (in this case, SOAP messages). It depends on the XMLSec library to provide XML encryption and XML signature support. XMLSec library implements both XML-Encryption [14] and XML-Signature [15] specifications. These specifications focus on generic XML documents (i.e. not necessarily SOAP documents) in providing encryption and signature functionality. XMLSec too, uses DOM as its object model in manipulating XML documents. Axis2 uses Apache Axiom (Axis Object Model) [16] in manipulating XML documents in order to increase performance. Thus uses an object model converter utility known as DOOM (DOM over OM) [17] in order to fit in with Axis2 and other two external libraries (i.e. WSS4J and XMLSec). DOOM WSS4J XMLSec Figure 3: Existing architecture of The DOOM component sits in between and WSS4J. Thus each XML document received by from Axis2 is converted to DOM representation and handed over to the WSS4J component for processing. The inverse happens when the processed document is received by from WSS4J. This particular architecture of has several drawbacks as mentioned below. 1) The introduction of DOOM, though seems to handle the problem of mapping between DOM and Axiom, degrades the performance of and eventually the performance of Axis2. Axiom which is based on

3 StAX (Streaming API (Application Programming Interface) for XML) is optimized for the benefits of pull-parsing. DOM on the other hand is based on push-parsing. Thus the conversion of object models adds a great overhead. Thus DOOM is just a temporary solution introduced to glue the pieces of the puzzle. 2) supports WS-Policy, but the validation of certain elements are done only after the completion of all the Web services security related processing steps. This post processing of validation leads to the problem of unnecessary computation when the message does not meet the requirements specified by WS-Policy. 3) The architecture of is hard to extend. There are many new specifications for different security features coming up. So the extensibility is a must, yet current implementation lacks this. overcomes these issues of through its design and development as given in the following section. 4. Design and development In the new architecture, all components of including Web services security implementation, XML security implementation and interface are implemented purely based on Axiom. This will completely remove the need of DOOM and increase the performance of the module. Additionally the SOAP security layer is also made WS- SecurityPolicy aware (see Figure 4). Thus the overhead associated with post Policy validation is also removed. Axis2 Layer (Handlers and SOAP-Security) XML security provider Sec Policy Figure 4: Proposed high level architecture for As the main intention of is to achieve high performance, after some experiments the decision was made to merge the Handler layer and SOAP-Security layer. If two separate layers were used, some operations like extraction of information to suite the particular layer should be done twice. The existing implementations providing SOAP security and XML security in WSS4J and XMLSec respectively contain very stable code and logic. Thus we wanted to reuse some of the code to keep the new implementation simple yet powerful. We could either reuse the logic or the code itself. Reusing, the code, however, leads to bad smell in the end product since the original code was designed to suit and not. The second choice was to reuse the logic but not the code. We could do this by re-implementing the logic purely based on Axiom. This way we are able to achieve a stable implementation. Thus after seeing the future benefits of this method we decided to move on with the Axiom based re-implementation. The Sec-Policy component shown in Figure 3 implements the WS-SecurityPolicy specification. The SecPolicy implementation used in written based on Axiom. Therefore s implementation directly reuses that module. The detailed architecture of the layer in figure 4 is given in figure 5. Handlers: Consists of two main handlers which are used in inflow and outflow of Axis2. This is the interface of to the outside world. Engine: This is the main component of which uses the functionality of almost all other components. This consists of interfaces to build and process secure SOAP messages. First of all, additional data which are needed in are extracted from data structures which are given by Axis2. They are stored in specific structures for later retrieval. Most importantly WS-SecurityPolicy specific data are also properly formatted here and given to SOAP security related classes. Message: This component consists of SOAP security related classes. In other words, it implements the WS- Security specification. The wsse:security header defined in this specification can consist of tokens such as Timestamp, UsernameToken, EncryptedKey, Signature, BinarySecurityToken etc. This component provides builders and processors for all these tokens. Those builders and processors are made WS- SecurityPolicy aware increasing the performance of. Policy: The Policy component of is different from the WS-SecurityPolicy implementation shown in Fig 4. This component extracts Policy data from it and makes a specific Policy structure. It is used to retrieve Policy data within other components whenever needed. Crypto: This component handles the crypto information needed to retrieve certificates used in encryption and signature. Utilities: This is a collection of utility classes which are used by all other components.

4 4.1. Building secured SOAP messages WS-SecurityPolicy specification defines three types of Bindings namely, TransportBinding, AsymmetricBinding and SymmetricBinding depending on the security scenario. Message building is done entirely according to this division. Building steps depend on the Binding. Therefore implements three different builders for these three Bindings. After the correct Builder is selected by the Engine according to the Policy, building process is assigned to that particular Binding Builder. In the selected Binding builder, tokens are included into the wsse:security header of the SOAP message according to what is specified in the Policy document. Each token is built by the corresponding token builder. For example, Timestamp Builder is used to include a Timestamp. Policy Handlers Engine Utilities Exit from SOAP Message StAX Parser (Axiom) WS-Security Processors Signature Processor Timestamp Processor Username Token Processor Policy Validation after Processing Enters into Policy Model WS- SecurityPolicy implementation Message (Builders and Processors) Crypto SOAP Message XML Security Figure 5: Components of 4.2. Processing secured SOAP messages This is the most important part of when it comes to achieving high performance. As explained above, does the Policy based validation after processing all security tokens., however, tries to discard an invalid message as early as possible. It avoids unnecessary processing and leads to a more efficient memory and CPU (Central Processing Unit) usage. s WS-SecurityPolicy based processing model is shown in Fig 6. In order to achieve this, all the s message processors are made Policy aware. Security header is processed in the order of tokens present in it. For example, if a Timestamp is the first token in the Security header, Figure 6: Policy based message processing model Timestamp processor is called first and the second token is considered only after processing it. In each processor, the received token is checked with the Policy and the message is discarded immediately if the received token does not match with the Policy. For example, consider a situation where a service receives a message with a Security header with Timestamp, UsernameToken, EncryptedKey and Signature tokens in the same order. If according to the Policy document of the service, UsernameToken should not be there and if the policy validation is done after processing all tokens, processing of EncryptedKey and Signature will be a waste as the whole message can be discarded after knowing that the UsernameToken is unnecessary. As processors are Policy aware in, UsernameToken processor will find that the token is unnecessary and it will discard the whole message. Although most of the policy validations can be done within the processors themselves, there are some

5 validations which should be done after processing all tokens in the Security header. For example, say a Timestamp should be included according to the Policy document. A Timestamp can be at any position within the Security header (if there is no signature). Therefore to check whether the Timestamp is included, has to wait until all tokens are processed XML security XML security addresses the general security concerns regarding XML documents. This includes mainly XML signature and XML encryption. The XML security provider developed for is kept as a separate package so it can be used in other projects as well in future if necessary. The architecture of the XML security provider is shown in figure 7. XML Signature XML Canonicalization XML Security Provider API XML Encryption Figure 7: XML security provider s architecture The XML Security Provider API is the API given to the outside world. The users of this library can access XML signature and XML encryption facilities through this API. The XML Signature package implements the XML- Signature specification. There are three types of XML signatures defined in the specification, i.e. enveloped signature, detached signature and enveloping signature. will mostly require the detached signature facility. The architecture of XML security provider is made such that the other two implementations of XML signature can easily be plugged in. The XML-Canonicalization [18] is a separate specification used to represent XML documents in a standard manner. The XML specification [19] allows many physical representations of the same XML infoset. Thus applications like XML signature will provide different results for the same document if the physical representation is different. XML-Canonicalization will provide a unique representation for a given XML document (note: there are certain limitations as well). The implementation of this specification was decided to distribute as a value added package for Axiom. Thus it was kept aside from the XML security provider. The XML Encryption package implements the XML- Encryption specification. This specification enables the encryption of both text and binary data. After performing encryption the encrypted data is put inside a defined XML structure with necessary key information. 5. Evaluation We developed a performance testing framework which compares and to verify that Axiom based implementation is faster than the DOM based implementation. It consists of following testing mechanisms. We used ApacheBench [20] and sent 1000 requests at a concurrency level of 20 for two Axis2 instances running and. The test was performed for 3 different payload sizes (i.e. 1, 50, and 100KB). The tests were performed under 4 different scenarios including both valid and invalid messages. Thus, in summary per each scenario the test consisted of 3 payload sizes with 1000 requests per each size. Statistics were collected using the results given ApacheBench. JConsole (a tool which is included in jdk 1.5) [21] was used to compare the memory footprints of and. We tested for messages which contain a security validation failure. This tool shows a graph which indicates the memory usage with time, of the connected process (JVM). To compare the times spent for comparable operations in and, we added a mechanism to print time logs into a file. Then compared the times for each operation. 6. Test Results We found positive results for under evaluation criteria. Here we are presenting the results we obtained from the response time tests for and considering the main purpose of high performance. Scenario 1: AsymmetricBinding is used in this scenario in which message protection is provided by means defined in WS- Security. Here are the requirements and constraints described in the security policy. Include an X509 token as the [Initiator token], an X509 token as the [Recipient Token], an algorithm suite, a requirement to encrypt the message parts before signing, a requirement to encrypt the message signature, a requirement to include tokens in the

6 message signature, and a requirement to encrypt and sign the message body. In this policy, it is not a requirement to include a timestamp. Therefore according to WS-Security a Timestamp element MUST NOT be added. If a Timestamp is added in a SOAP request, it should be rejected. In this scenario, the Web service expects the SOAP requests to be compliant with security policy. But client sends service requests with Timestamps included. Therefore the Web service should reject the request and send an error message. Here we measured the execution time taken to process the SOAP request and sends SOAP response message. Apache Bench tool calculates the execution times and the request per second. The following table shows the requests per second property for varying payload sizes for and. A bar chart is drawn to graphically illustrate this fact. Payload Size 1KB KB KB takes more time when the payload increases. It is clearly shown in the above graph and the table. The requests/sec reduced drastically when the payload increases. 2. has removed the DOOM conversion by implementing the XML Security Provider layer purely in Axiom. Moreover, validate the message against the security policy in parallel with processing steps of WS-Security elements. Therefore reject this SOAP request early in the processing chain without further wasting of resources. Scenario 2: In this scenario we used the same security policy as used in the scenario 1. But this time we sent valid SOAP requests. Both and has to process the requests completely and generate SOAP responses. Following table shows the requests per second property for varying payload sizes for and. A bar chart is drawn to graphically illustrate this fact. Payload Size 1KB KB KB Table 1: Results for scenario 1 Table 2: Results for scenario 2 Requests/sec Requests/sec KB 50KB 100KB 5 Payload size 0 1KB 50KB 100KB Graph 1: vs. for scenario 1 This graph clearly shows that the number of requests/sec handled by is around six times the number of requests/sec handled by. There are several reasons for this kind of a difference to exist as given below. 1. completely processes the SOAP request before validating against the policy. This processing involves heavy cryptographic operations such as decryption and signature validation. This processing Payload size Graph 2: vs. for scenario 2 Scenario 3: The security policy used in this scenario is bit different from the policy used in the scenario 2. The requirement to encrypt the message parts before signing is removed and a new requirement to sign the message parts before

7 encrypting is introduced. The requirement to encrypt the message signature is also removed. The client, however, sends SOAP request in which body is only signed and not encrypted. But the Web service expects messages with the body is encrypted and signed. Therefore this message is invalid and should be rejected as soon as possible. Following table shows the requests per second property for varying payload sizes for and. A bar chart is drawn to graphically illustrate this fact. Requests/sec Payload Size 1KB KB KB Table 3: Results for scenario KB 50KB 100KB Payload size Graph 3: 3 : vs. for scenario 3 The performance of is similar to that of scenario 1. It detects that the message is invalid without completely processing the SOAP requests. s performance has increased too when compared with the scenario1. This is because it detects the invalidity early in its post policy validating process. Scenario 4: The security policy used in scenario 1 is used here as well. There is a requirement to encrypt the message signature. But the client sends SOAP request without encrypting the message signature. Therefore these requests are invalid and they should be detected early without further processing. Following table shows the requests per second property for varying payload sizes for and. A bar chart is drawn to graphically illustrate this fact. Requests/sec Payload Size KB KB KB Table 4: Results for scenario 4 0 1KB 50KB 100KB Payload size Graph 4: vs. for scenario 4 The client send invalid SOAP requests, yet in this scenario and rampart cannot detect it earlier. also does this validation step as a post policy validation task. Therefore the number of requests per second is reduced when the payload is increased. The types of messages processed by both and can be broadly classified into two categories, i.e. valid and invalid messages. The validity is assessed based on the given WS-SecurityPolicy document. The server drawback of is the waste of resource when processing invalid messages. The lack of WS- SecurityPolicy awareness in its components leads to wasteful processing of the message and discarding it eventually. with its WS-SecurityPolicy aware processing model takes advantage in such situations. The results obtained for such invalid messages clearly shows that Ramaprt2 utilizes resources very effectively compared with. Processing a valid message in both and tends to follow an equivalent number of steps. The performance difference may become small as a reason., however, has shown a considerable performance gain over even when processing valid messages.

8 7. Discussion DOM uses the concept of push parsing in parsing an XML stream. Thus once a stream representing an XML infoset is presented, DOM parsers consume the entire stream and build the object tree in memory. Thus there is high memory footprint in using DOM. This really becomes an issue when processing XMLs of sizes ranging from mega-bytes to giga-bytes. Axiom uses the concept of pull parsing in parsing an XML stream. Thus an XML stream is not consumed at once. The application, which relies on top of a pull parser, requests certain portions of the XML infoset. The pull parser then goes on consuming the stream up to that point and builds the object tree partially in memory. Thus it has a low memory footprint and also Axiom is specifically targeted to be lightweight. This is achieved by reducing the depth of the hierarchy, number of methods and the attributes enclosed in the objects. This makes the objects less memory intensive. In addition to that, Axiom uses Deferred Building. By far this is the most important feature of Axiom. The objects are not made unless a need arises for them. This passes the control of building over to the object model itself rather than an external builder. The two parsing mechanisms used in DOM and Axiom leads to performance differences between them in processing XML documents. Experiments show that Axiom is far in front when compared to DOM. Therefore usage of Axiom in Axis2 has added a huge value to Axis2. As more and more business applications move towards Axis2, it is almost a must to provide Security facilities within Axis2 itself. But using a DOM based Security module definitely reduces the advantage gained by Axis2 through the usage of Axis2. provides a perfect solution to this problem as it is totally Axiom based Optimization points in Ramart2 1) As already stated under design and development, merging the Handler layer and SOAP-Security layer is an optimization point in. In, those are two layers since WSS4J is an external dependency. So the additional data needed in the security module should be handled twice in two layers. But by merging those two layers, removes those data extracting overheads. 2) When the top layer communicates with the XML Security layer, takes a better approach. In encryption and signature, the particular element to be encrypted or signed is taken out in the top layer by traversing the Axiom object. This extracted object itself is transferred into the bottom layer to reduce the overhead of traversing the tree again to find the particular element. In, only the attribute called Id was transferred into the bottom layer and it searches the tree again. This is also a major improvement in Ramaprt2. 3) The processing model shown in Fig 6 is also a major optimization point. Some previous researches [22], [23] have proposed a two pass processing model where the first pass is to process security tokens and the second to validate those according to Policy. uses this two pass model. We also accept the fact that it can t be done by only using a single pass for processing and validation. But the point we are trying to emphasize is that most of the validation steps can be done parallel to processing and it leads to a better processing model. does Policy based validation up to some extent parallel to token processing and the rest after token processing. We strongly believe that this architecture leads to earliest disposal of invalid messages. 4) The DOM based XML signature implementation performs the verification of the signature value only after validating the digest values of all the references. This is a waste of processing power in the case of a DDOS (Distribute Denial of Service). For an example consider a person sending a large list of invalid references in the XML signature. If processed according to the specification it will waste a lot of CPU power in calculating the digest values of the lengthy reference list. Thus in our implementation we first validate the signature value and will proceed to the validation of references only if it validates correctly. Thus saves computational power in the case of invalid signature documents. 8. Conclusion removes the inefficiencies associated with the existing Web services security provider,. It removes DOOM and implements the features of both WSS4J and XMLSec projects purely based on Axiom. makes SOAP level sub components WS- Policy aware. Thu WS-Policy validation is done efficiently. Additionally, it provides a less complex extensible interface. Thus future extensions would encounter less hassle. WSS4J and XMLSec were used as guides and the logic was reused up to some extent but not the code itself. Reuse of code adds bad smell to the code. The end product, Ramapart2, successfully achieves its goal of being a high performance Web services security module for Axis2.

9 Acknowledgement We would like to thank Dr. Shantha Fernando and Mr. Indika Perera for providing us with enormous support and guidance on matters related to the project. Next we would like to thank Dr. Sanjiva Weerawarana and Mr. Ruchith Fernando for their invaluable continuous support and supervision on project. [22] N. Gruschka, R. Herkenhöner, and N. Luttenberger, WS- SecurityPolicy Decision and Enforcement for Web Service Firewalls. [online]. Available: References [1] Apache Axis2 [online]. Available: [2] The Apache Software Foundation [online]. Available: [3] SOAP [online]. Available: [4] HTTPS [online]. Available: [5] Apache [online]. Available: [6] WS-Security [online]. Available: [7] WS-Policy [online]. Available: [8] WS-SecurityPolicy [online]. Available: [9] WS-Trust [online]. Available: [10] Apache WSS4J [online]. Available: [11] Apache XMLSec [online]. Available: [online]. Available: [12] DOM [online]. Available: [13] XML 1.0 [online]. Available: [14] XML-Encryption [online]. Available: [online]. Available: [15] XML-Signature [online]. Available: [online]. Available: [16] Apache Axiom [online]. Available: [17] F. Ruchith. How can I convert an LLOM AXIOM tree into a DOOM AXIOM tree? [online]. Available: [18] XML-Canonicalization [online]. Available: [19] Apache Bench [online]. Available: [20] JConsole [online]. Available: e.html/ [21] N. Gruschka, N. Luttenberger, and R. Herkenhöner, Eventbased SOAP Message Validation for WS-SecurityPolicy- Enriched Web Services. [online]. Available: