Soa Testing An Approach For 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
Jaipal.naidu@enzenglobal.com
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
Uday.vussainsagar@applabs.com
AppLabs
DLF Building
6th Floor, Plot No. 129-132
APHB Colony, Gachibowli
Hyderabad - 500 019
Andhra Pradesh
Tel: +91 40 3082 9000

1 Testing Security Aspects of SOA Based application

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.

Security Security (WS-
(WS- Security SOAP
SecureConversa Message
tion) Security)

Order Service Billing Module

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

Customer Service Shipment
Module

Security
(WS-Trust)

Security Token
Requestor
Service

Figure 2 – SOA Implementation


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 Description Required/Optional
Name /Recommended
<wsc:SecurityContex The element describes the Security Required
tToken> Context
<wsc:Identifier> The element identifies the Security Required
Context using an URI
<wsc:Instance> Provides uniqueness for the value Optional and
present in the element wsc:Identifier Required for
subsequent messages
@wsu:Id Specifies a String label for Optional
wsc:SecurityContextToken
<wsc:UnsupportedCo The element identifies any fault Recommended
ntextToken> present in the message
<wsse:SecurityToken The element is used for referencing Required
References> the Security Context
<wsse:Reference> This element is used for identifying Required
specific key instance with the use of
attribute wsc:Instance
Approach 1, 2 and 3:
<wst:RequestSecurit Request to the Token Service Required
yToken>
<wst: Contains the Security Context Required
RequestSecurityToke Response
nResponseCollection>
<wst:RequestSecurit Child element of wst: Required
yTokenResponse> RequestSecurityTokenResponseColle
ction element
<wst:RequestedSecur Contains the new Security Context Required
ityToken> Token
<wst:RequestedProof Points to the “Secret” for the Required
Token> returned context
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.


<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>
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.


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”>


(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>

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


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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

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

Similar a Soa Testing An Approach For Testing Security Aspects Of Soa Based Application (20)

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