Soa Testing An Approach For Testing Security Aspects Of Soa Based Application

1 Testing Security Aspects of SOA Based application

Service Oriented Architecture Testing: An Approach for Testing Security Aspects of SOA Based application

Authored By: Jaipal Naidu [email protected] Enzen Global Solutions Pvt Ltd # 90, Hosur Road, Madiwala Bangalore - 560 068 Karnataka Tel: +91 80 6712 3002 Fax: +91 80 6712 3003 Uday Kumar Vussainsagar [email protected] AppLabs DLF Building 6th Floor, Plot No. 129-132 APHB Colony, Gachibowli Hyderabad - 500 019 Andhra Pradesh Tel: +91 40 3082 9000


Abstract

SOA is an architectural paradigm which helps organizations to transform

themselves into more flexible entities. Key issues of applications built using SOA are testing these applications and delivering them within expected QoS. Any organization that aims to achieve a high degree of quality in their SOA application is likely to face many challenges

This paper describes an approach to meet the challenges in testing SOA based applications. The main focus would on the testing approach of SOA security aspects such as WS-Security, SAML, WS-Trust, WS-SecureConversation and WS-Security Policy. This solution helps in writing customized Test Assertion Documents based on the specifications provided by OASIS group and parsing these documents with respect to the SOAP messages captured at various levels of interfaces.

1.0 Introduction

Service oriented computing builds upon the existing distributed computing platforms by building in the concept of service orientation. Service oriented attitude brings about uniformity amongst the organizational software assets, which till now were developed with Silo/ Functional based development attitude. More companies are adopting the Service Oriented Methodology to build applications by re-using the loosely coupled and highly cohesive services present under different domains and environments.

SOA has grown from being a concept with disillusioned principles to the phase of

enlightenment where organizations are putting in their R & D teams to come up with a package that can fit in to any existing IT infrastructure. We can see a comparison of Hype Cycles in Figure 1 from 2005 to 2009 and see how SOA has grown to be a matured offering and in to a Game changing proposition for any organization adopting the concept early and realize the competitive advantage/ Business agility that SOA promises.

Traditionally, the Service-Oriented Architecture is nothing new to the IT

industry, the Common Object Request Broker Architecture (CORBA) and Distributed Component Object Model (DCOM) used to provide the same functionality though having pitfalls. In a nutshell the Service-Oriented Architecture is an architectural approach which makes use of applications that are already available by turning them into services. These category of services are governed and standardized to behave specifically and are referred to as inventory of services. It doesn't really matter if these services are built as web services or components. Web services though not obligatory, can be used for implementing SOA by adhering to the standards and it is fast becoming a broad industry acceptance. The web services provide the accessibility of functionality with a request response model over any standard internet protocol independent of any programming language, which makes the SOA a reality.


Figure 1 – Analysis of SOA position using Gartner Hype Cycles

2.0 Security Aspects in Web Services

As discussed in the above section, how the Web Services constitute a fundamental solution in realizing the SOA, the security aspects involved in Web Services is increasingly becoming indisputable factor in implementing the SOA strategy. There are several security standards and new emerging standards have been proposed by many non-profit consortiums (such as OASIS, W3C) to make Web Services development easy. The following Table 2 lists such standards and provides a brief description about each standard Standard Description SAML SAML is a standard which provides authentication and

authorization for the information exchanged between two online parties using XML – based framework.

WS-Security WS-Security is a mechanism which addresses the security within a web service environment.

XML-Encryption XML-Encryption is a process of representing the encrypted data in XML

XML-Signature XML-Signature is a specification of syntax and rules for defining the XML digital signature recommended by W3C.

WS-SecureConversation The Web Service Secure Conversation is used to provide security for the parties that wish to exchange multiple messages by sharing a Security Context between the communication parties for the entire communication session.

WS-Trust The Web Service Trust is a model in which the Web Services require that an incoming message prove a set of claims.


WS-SecurityPolicy WS-SecurityPolicy defines a framework for allowing web services to express constraints and requirements by defining policy assertions

WS-Federation WS-Federation is to allow security principle identities and attributes to be brokered from identity and security tokens issuers to services and other relying parties without user intervention.

Table 1 – SOA Security Specification Standards For each of the standards listed in the above table, the OASIS consortium has

provided specification documents which help both the Development and the Quality Assurance teams alike. These specification documents constitute a decisive factor in writing the customized Test Assertion Documents. The specification document for each standard has been referenced in reference section. With so many security standards specifications evolved and evolving in future, the obvious requirement would be in identifying a test tool strategy. The below section provides a brief overview of the various tools available in the market.

3.0 Existing SOA Security Tools

There are several SOA testing tools available in the market in both the categories – commercial and open source products. The commercial products are Green Hat Tester, Mercury products, Parasoft SOAtest, AdventNet QEngine, Borland SilkPerformer SOA edition LISA WS – Testing. The open source products are SOAP UI, Push To Test TESTMAKER and WS-I tools. These tools provide an excellent support for functional, interoperability, regression and performance testing.

Some of the tools mentioned above also supports the testing of WS-Security including X509, SAML, Username security tokens, XML Signature and Encryption. However, we hardly find a tool which would support the testing beyond the WS-Security. This paper provides an approach in testing the SOA applications beyond the WS-Security specifications. 4.0 Challenges in testing Security Aspects of SOA

Consider a scenario where each Web Service in Service-Oriented Architecture is enforced with a different security policy – it’s a testing nightmare. Any organization having developed a Web Services based SOA application with different security policies is bound to face the following challenges in testing

Is the business objective met when different services are orchestrated? Is end-to-end security maintained when the services are opened, integrated,

or re-factored? Whether services used in building the applications are WS-* Specifications

practitioners or not? Identifying centralized SOA security management approach Identifying a comprehensive testing approach Availability of SOA security tools. Lack of User Interface


5.0 SOA Implementation Scenario

To help the cause and to best explain the testing approach, a scenario has been referred below which would be used again and again in the remainder of the paper The primary business of the retail companies is to meet the customer expectations and sustain a competitive edge. Consider that you’re a CTO of a retail company and you are asked to use the existing application more efficiently to meet the growing demands of the business and competition. To enable quick development of the application the CTO decides to use the existing business logic and customize them into reusable services which follow different WS-* specifications. Though each of the application functions the way it should and provides the result in accordance with the industry standards, there is one more concern that the CTO faces. What is the best approach to test these services which follow different WS * standards? This is a concern because any breach in the security of the applications leads to repercussions which have ripple effect. So, the focus of CTO is to deliver an application whose security is not easy to breach and find the best way to test it.

Figure 2 – SOA Implementation

Security (WS-

SecureConversation)

ESB, Middle Ware Technologies, BPEL, WS-I Security Specifications

Customer Service

Security (WS-Trust)

Shipment Module

Order Service

Billing Module

Security (WS-Security SOAP

Message Security)

Requestor Security Token

Service


As shown in Figure 2 the company makes use of Service-Oriented Approach and embedding various Web Services Security standards for each loosely-coupled service.

The Customer Service engages WS-Trust security mechanism in which it authenticates the incoming request with a set of claims. The requestor can obtain the necessary Security Token (collection of claims) from another service called Security Token Service as shown in the Figure 2. The recipient either trusts the Security Token or requests the STS to validate the Security Token.

The Order Service engages WS-SecureConversation security mechanism where it establishes Security Context with the requestors sending multiple orders thus creating multiple messages.

The Billing Service makes use of WS-Security: SOAP Message Security by protecting and authenticating the SOAP message through the use of security tokens combined with digital signatures.

The Shipment Service does not make use of any security mechanism. 6.0 Approach

The following non-normative approach is used for testing the security aspects (which would otherwise be working fine when tested individually) in conjunction with the SOA implementation scenario presented in the above section. The approach has been broadly divided into three steps Test Assertion Documents

Analyze thoroughly the security specification used by the web services in the SOA application

Prepare a table (though optional) identifying required, optional and recommended elements that the specification has defined

Prepare the Test Assertion XML document using the table defined Capture SOAP messages

Identify or develop a simple SOAP monitor tool Initiate the request Capture the SOAP messages using the SOAP monitor tool

Generate Test Result Report Compare the TAD with the captured SOAP request and response and generate

a result report

6.1. Test Assertion Documents

In this section the focus would be on building the Test Assertion Document for one of the security specification mentioned in the SOA implementation Scenario. This section also helps the test engineers and architects with good understanding of preparing customized test assertion documents according to the needs of the testing. Security Specification – WS-SecureConversation Specification Version – 1.3 WS-SecureConversation – Please refer the Table 2.1 for the brief explanation Notations – In the Table 2 the element is represented within the tag and the attribute is preceded by the symbol @ Test Assertion Document Name – WS-Secure Conversation Test Assertion Document


Pre-Condition – The security context has to be shared by the parties before being used. The security context can be shared by the three approaches listed below. The Table 2 also lists the elements used in SOAP message in creating SCT through the below listed approaches

Approach1: SCT created by a STS Approach2: SCT created by one of the communication parties and propagated

with the message Approach3: SCT created through negotiations/exchanges

Element/Attribute

Name Description Required/Optional

/Recommended <wsc:SecurityContextToken>

The element describes the Security Context

Required

<wsc:Identifier> The element identifies the Security Context using an URI

Required

<wsc:Instance> Provides uniqueness for the value present in the element wsc:Identifier

Optional and Required for subsequent messages

@wsu:Id Specifies a String label for wsc:SecurityContextToken

Optional

<wsc:UnsupportedContextToken>

The element identifies any fault present in the message

Recommended

<wsse:SecurityTokenReferences>

The element is used for referencing the Security Context

Required

<wsse:Reference> This element is used for identifying specific key instance with the use of attribute wsc:Instance

Required

Approach 1, 2 and 3: <wst:RequestSecurityToken>

Request to the Token Service Required

<wst: RequestSecurityTokenResponseCollection>

Contains the Security Context Response

Required

<wst:RequestSecurityTokenResponse>

Child element of wst: RequestSecurityTokenResponseCollection element

Required

<wst:RequestedSecurityToken>

Contains the new Security Context Token

Required

<wst:RequestedProofToken>

Points to the “Secret” for the returned context

Required

Table 2 – WS-SecureConversation elements Having analyzed the specification document, the next step is preparing the

Test Assertion XML document which will be subsequently be used in generating the result report. The below Figure 3 provides a part of Test Assertion Document for the specification WS-SecureConversation used in the order service.


Figure 3 – Test Assertion Document

The following table lists the details about the Test Assertion XML Document. It explains about each and every tag that is being used in the Test Assertion Document. One thing it has to be kept in mind that this Test Assertion Document is not a standard document and one can modify the elements by either adding or removing the elements according to the requirements. However, the Test Assertion document should be in the XML format as this would form a base document in reporting the test results. To make the TAD more secure the XML document can be referenced by an XSD or by a DTD document.

<testAssertion id="WSC0001" entryType="anySecureEnvelope" type="required" enabled="true"> <context>For any secure envelope, that describes Security Context meant for SOAP message

security with wsc:SecurityContextToken</context> <assertionDescription>Every SOAP message that describes Security Context SHOULD have the wsc:SecurityContextToken element specified.</assertionDescription> <failureMessage>One or more SOAP messages in the message is without the wsc:SecurityContextToken element.</failureMessage> <failureDetailDescription>The wsc:SecurityContextToken element in question.</failureDetailDescription> <additionalEntryTypeList> <messageInput>none</messageInput> <wsdlInput>none</wsdlInput> </additionalEntryTypeList> <referenceList> <reference>none</reference> </referenceList> <comments></comments> <prereqList/> </testAssertion> <testAssertion id="WSC0002" entryType="anySecureEnvelope" type="required" enabled="true">

<context>For any secure envelope, that contains a wsc:SecurityContextToken meant for SOAP message security with wsc:Identifier child element.</context>

<assertionDescription>The wsc:SecurityContextToken element MUST have the child element wsc:Identifier specified.</assertionDescription>

<failureMessage>The wsc:SecurityContextToken elements present in the message without their child element wsc:Identifier.</failureMessage>

<failureDetailDescription>The wsc:SecurityContextToken element in question.</failureDetailDescription>

<additionalEntryTypeList> <messageInput>none</messageInput> <wsdlInput>none</wsdlInput>

</additionalEntryTypeList> <referenceList>

<reference>none</reference> </referenceList> <comments></comments> <prereqList/>

</testAssertion>


Element Name Description <testAssertion> This element contains the assertion for each element

identified in table 2 @id Used to provide unique id for the assertion @entryType Used to identify the type of SOAP message @type It describes whether the element is required or not @enabled <context> The element defines the context in which the element is

being used <assertionDesription> Contains the description of the assertion <failureMessage> Contains the failure message <failureDetailDescription> Contains the detail description of the failure <additionalEntryTypeList> Contains any additional information about the SOAP

message <messageInput> Contains the input values provided to the message <wsdlInput> Contains the WSDL URL <referenceList> Contains the list of references if the specification is

referring to <reference> It’s the child element of <referenceList> <comments> Contains any additional comments <prereqList/> Contains the list of pre-requisites if any

Table 3 – Test Assertion Document Elements Description

6.2. Capture SOAP Messages

The Service Provider and Requestor in Web Services communicate the information with each other in a structured manner through a protocol specification called SOAP. The SOAP protocol usually exchanges information over the application layer protocols HTTP and HTTPS with the information being transmitted using XML. The SOAP message constitutes the following major elements An Envelope, A Header, A Body and A Fault, the details of which are beyond the scope of this paper.

In the SOA implementation scenario described in section 5.0 the Customer Service communicates all the details of the Customers to the Order Web Service securely in order to process the orders. Therefore, the Customer service will become the Web Service Consumer and the Order Services becomes the Web Service. The two communicating parties establish a Security Context by a token called SCT. The following figure 4 shows the SOAP message that is captured during the communication between the two communicating parties. It illustrates the use of SCT by referencing.

(001) <?xml version="1.0" encoding="utf-8"?> (002) <s11:Envelope xmlns:s11=”http://www.w3.org/2003/05/soap-envelope” xmlns:ds=”http://www.w3.org/2000/09/xmldsig#” xmlns:wsse=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd” xmlns:wsu=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd” xmlns:wsc=”http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512”>


Figure 4 – Sample WS-SecureConversation SOAP Message The above SOAP message is captured when client initiates the request. The

SOAP message can be captured either using any of the open source SOAP Monitor tools or by writing code in any language.

6.3. Generating the Test Result Report

The last and important step is generating the test results. The test results can be easily generated by comparing each element in the SOAP Header with the TAD developed using the specification. The results can be documented as given in table 4 below. The comparison of XML documents can be done using DOM or SAX parsers in JAVA or the users can use the library native to the selected programming language. The result report can also be saved in HTML or XML format after the parsing is done.

Comparison Status True Pass – Provide the description given in the

<assertionDesription> element of TAD False Fail - Provide the description given in the <failureMessage>

and <failureDetailDescription> elements of TAD Table 4 – Test Result Report

7.0 Why accept the solution

Let us start referring to section 5.0 and ponder over the scenario's that existed in front of the CTO.

Using the existing IT infrastructure, deliver/ customize applications which provide results as per the marketplace requirements

Tackle the situation with no or very less capital expenditure Choose the best way to secure the changes made and deploy the solution

with less lead time than other potential solutions would have taken

(003) <s11:Header> (004) <wsse:Security> (005) <wsc:SecurityContextToken wsu:Id="MyID"> (006) <wsc:Identifier> uuid:20189D76AA5794EBCA1214227

5347662</wsc:Identifier> (007) </wsc:SecurityContextToken> (008) <ds:Signature> (009) <ds:Signature> (010) <ds:KeyInfo> (011) <wsse:SecurityTokenReference> (012) <wsse:Reference URI="#MyID"/> (013) </wsse:SecurityTokenReference> (014) </ds:KeyInfo> (015) </ds:Signature> (016) </wsse:Security> (017) </s11:Header> (018) <s11:Body wsu:Id="MsgBody"> (019) ……….. (020) </s11:Body>


Approach analysis: By choosing the Web Services based SOA approach, most of the challenges that existed were resolved. Let’s see how

Intrinsic Interoperability of all Web Services coupled with the feature that they were governed/ federated by a common service contract helped in designing a solution that was compatible with the existing IT infrastructure. The system built was flexible and adaptive to any ad-hoc business requirements that would arise intermittently.

With no new IT products being purchased to achieve the fore stated flexibility, there were fewer IT vendors to interact and lesser integration challenges.

Merits of any solution are measured in the terms of how the new approach maximizes the ROI, induces new agility in the system and there by reducing the burden of new investment in trying times. Maximum ROI:

The approach presented in section 6.0 enables organizations to maximize ROI because of the fact that system gives the all important competitive advantage in terms of faster product turnaround, enhanced decision making capabilities and streamlining the operations by fewer changes in the IT infrastructure.

Increased Agility: The quality assurance team need not wait for the new versions of SOA testing

tools to be released because the solution provides core details of testing the security aspects of web services

The QA team can also use the approach for testing individual as well as integrated web service using the principles of SOA and V-model testing

The testing team can customize the approach at any stage. For example, XPath can be used in the <assertionDescription> element of TAD.

IT Investment: The investment on new skills will be greatly reduced because the existing

resources having skills in testing and xml technologies can be utilized to work on the solution. For those with no experience can be utilized after providing some basic training.

The overall IT infrastructure cost is also very less because the solution can be easily integrated with the infrastructure used for the development of SOA application

There are certain steps that have to be additionally followed when implementing the solution.

The test assertion document is not a conventional test case document that is followed in testing traditional web applications to make it simpler and user friendly

The test engineers have to spend time to prepare TAD, capture the SOAP messages and generate the test result.

In short, we can say that the solution demands better Test engineers to carry out the job. It has been estimated that over 60% of the companies are trying to establish center of excellence in testing space of SOA. Adopting the open source solution prescribed will certainly help the companies in implementing a cost effective approach of testing the security aspects of web services beyond WS-Security. Organizations will benefit by following this non-normative approach by paying less for testing the web services. The approach will also enable the test architects to implement a user – friendly SOA security tool which can be customized according to the needs of testing requirements. There is also a very high probability of extending


this tool to cover the other aspects of SOA testing such as Functionality, Interoperability and Performance. Reference: http://www.gartner.com/ http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversation-1.3-os.pdf http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf http://www.w3.org/Submission/WS-Policy/ http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.3/os/ws-securitypolicy-1.3-spec-os.pdf http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf http://www.oasis-open.org/specs/#samlv1.1 http://docs.oasis-open.org/security/saml/v2.0/sstc-saml-approved-errata-2.0.pdf http://saml.xml.org/ http://msdn.microsoft.com/en-us/library/ms951273.aspx http://www.w3.org/TR/xmlenc-core/ http://www.w3.org/TR/xmldsig-core/ http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-fed/WS-Federation-V1-1B.pdf?S_TACT=105AGX04&S_CMP=LP http://www.applabs.com/

Authors Biography Uday Kumar Vussainsagar

Uday Kumar has three and half years of experience in IT and Software Quality Assurance. He is currently working as a senior software engineer in the software quality assurance division of AppLabs. Manual testing and automation testing in various domains is his forte.

He is currently pursuing Post Graduate Diploma in M.Tech from International Institute of Information Technology, Hyderabad and is a Graduate Engineer in Computer Science Engineering from JNTU. Jaipal Naidu Lingutla

Jaipal Naidu has over three and half years of experience in IT and Business Consulting. He is presently with Enzen Global Solutions pvt Ltd as a Business Analyst in their Utilities Consulting division. Prior to Enzen, he worked with Satyam Computer Services Ltd towards virtualization of Business Processes, and Implementation of back-office operations by leveraging Virtual Shared Service capabilities and service redesign.

He holds a Post Graduate Diploma in Management from Symbiosis Institute of Management Studies and is a Graduate Engineer in Computer Science and Information Technology from JNTU.


Appendix:

Acronyms

OASIS – Organization for the Advancement of Structured Information

Standards

W3C – World Wide Web Consortium

STS – Security Token Service

SCT – Security Context Token

XSD – XML Schema Document

DTD – Document Type Definition

TAD – Test Assertion Document

SOAP – Simple Object Access Protocol

XML – Extensible Markup Language

SAML – Security Assertion Markup Language

ROI – Return on Investments

Soa Testing An Approach For Testing Security Aspects Of Soa Based Application

Documents

Transcript of Soa Testing An Approach For Testing Security Aspects Of Soa Based Application