ACEEE Int. J. on Communication, Vol. 01, No.

03, Dec 2010

Architecting Secure Service Oriented Web Services

D.Shravani1 P.Radhika2 Dr.P.Suresh Varma3 Dr.D.Sravan Kumar4 M.Upendra Kumar 5
Research Scholar R.U. Kurnool and Assistant Professor CS MIPGS Hyderabad A.P. India Email: sravani.mummadi@yahoo.co.in 2 Research Scholar R.U. Kurnool and Assistant Professor CSE VNR VJIET Hyderabad A.P. India Email: jyothisree.manne@gmail.com 3 Principal and Professor Department of Computer Science Adikavi Nannaya University Rajamundry A.P. India Email: vermaps@yahoo.com 4 Principal and Professor CSE KITE Womens College of Professional Engineering Sciences Hyderabad A.P. India Email: dasojusravan@yahoo.co.in 5 Research Scholar JNTUH and Associate Professor CSE MGIT Hyderabad A.P. India Email: uppi_shravani@rediffmail.com
1

AbstractThe importance of the software security has been profound, since most attacks to software systems are based on vulnerabilities caused by poorly designed and developed software. Design flaws account for fifty percent of security problems and risk analysis plays essential role in solid security problems. Service Web Services are an integral part of next generation Web applications. The development and use of these services is growing at an incredible rate, and so too security issues surrounding them. If the history of interapplication communication repeats itself, the ease with which web services architectures publish information about applications across the network is only going to result in more application hacking. At the very least, its going to put an even greater burden on web architects and developers to design and write secure code. Developing specification like WSSecurity should be leveraged as secure maturity happens over firewalls. In this paper, we want to discuss security architectures design patterns for Service Oriented Web Services. Finally, we validated this by implementing a case study of a Service Oriented Web Services application StockTrader Security using WS-Security and WS-Secure Conversation. Index Terms Security Architectures, Service Oriented Architectures, Web Services Security, WS-Security, WSSecure Conversation.

the security characteristics of composites and applications using services is an active research. Organizations should also identify the deployment strategies for the SOA infrastructure, services, composites, and applications because different deployment strategies can entail different security verification practices. Finally, all elements should be verified in their operational contexts. Web Services are the most popular implementation approach for SOA. The elements of a Web Service from a security perspective are the service interface, service implementation, message payload, and service level agreement (SLA). All of these elements are visible to participating parties except for the service implementation, which is usually hidden and known only to the service provider. Refer to Table 1.
TABLE 1. WEB SERVICES SECURITY THREAT FRAMEWORK Web Services Layer Layer 1: Web Services in Transit Lauer 2: Web Services Engine Attacks and Threats In transit Sniffing or Spoofing WS-Routing security concern Replay attacks Buffer Overflow XML parsing attacks Spoiling Schema Complex or Recursive structure as payload 5. Denial of Services 6. Large payload 1. Fault Code Leaks 2. Permissions and Access issues 3. Poor Policies 4. Customized error leakage 5. Authentication and Certification 1. Parameter tampering 2. WSDL probing 3. SQL/LDAP/XPATH/OS command injection 4. Virus/Spyware/Malware injection 5. Brute force 6. Data type mismatch 7. Content spoofing 8. Session tampering 9. Format string 10. Information Leakage 11. Authorization 1. 2. 3. 1. 2. 3. 4.

I.

SERVICE ORIENTED WEB SERVICES SECURITY ARCHITECTURES

Layer 3: Web Services Deployment

Service-Oriented Architectures (SOA) represents a new evolving model for building distributed applications. Services are distributed components that provide welldefines interfaces that process and deliver XML messages.[1-3]. A service-based approach makes sense for building solutions that cross organizational, departmental, and corporate domain boundaries. A business with multiple systems and applications on different platforms can use SOA to build a loosely coupled integration solution that implements unified workflows. Security in an SOA environment involves verifying several elements and maintaining confidence as the environment evolves. Organizations deploying SOA implementations should identify practical strategies for security verification of individual elements, but should be aware that establishing 14 2010 ACEEE DOI: 01.IJCOM.01.03.181

Layer 4: Services Code

Web User

ACEEE Int. J. on Communication, Vol. 01, No. 03, Dec 2010

Refer to Table 2. Which consists of Web Services Security Patterns.

TABLE 2. WEB SERVICES SECURITY PATTERNS Category Authentication Pattern Brokered Authentication Brokered Authentication: Kerberos Brokered Authentication: X509 PKI Brokered Authentication: STS Direct Authentication Trusted Subsystem Exception Shielding Data Confidentiality Message Replay Detection Data Origin Authentication Message Validator Perimeter Service Router

Step 3: Create the Web Service Based on the Type Definition Assembly Step 4: Implement the Business Interface in the Web Service Step 5: Generate a Web Service Proxy Class File Based on the WSDL Document Step 6: Create a Web Service Client III. ARCHITECTING SECURE SOA WEB SERVICES ARCHITECTURES Web as a media and Web Services as a technology is emerging as a mode of business-to-business and ecommerce transactions. Most of these transactions will carry business-critical and sensitive information that must be secured. Like any other technology domain, secure Web Services is complex and possibly overwhelming. Addressing a breach-in that includes cost of liability, public relations, and loss of business could be more expensive than implementing security measures in advance. Also, security should be enforced throughout the infrastructure. Research issues include Web Services technology, its vulnerabilities, enforcing security in this media, emerging security standards incorporating into Web Services applications. [9] IV. SECURE SOA WEB SERVICES WITH WS_SECURITY A CASE STUDY Companies have started the adoption of Web Service technology and the WS-Security specification as an approach to ensure the integrity of transmitted messages and data. [10-13] The WS-Security specification is a joint effort by Microsoft, IBM, and VeriSign to address this most important issue. The WS-Security specification is designed to provide an extensible security implementation that will evolve as Web Services technology becomes more sophisticated. Both WS-Security and WSE 3.0 plays an important role when building Microsoft .NET-based Web Services or Web Services consumers. WS-Security integrates a set of popular security technologies, including digital signing and encryption based on security tokens, including X.509 certificates. It is flexible and is designed to be used as the basis for the construction of a wide variety of security models, including PKI, Kerberos and SSL. Particularly WS-Security provides support for multiple security tokens, multiple trust domains, multiple signature formats, and multiple encryption technologies. A. Case Study We had implemented a case study, a simple example that secures the StockTrader application. We implemented the UsernameForCertificate assertion that secures the WSE Security Settings wizard and created a custom username token manager. Finally we authorized users using either code or a policy file. Brokered Authentication: The client and service do not attempt to authenticate each other directly. They use an intermediary that validates the clients identity and then provides a 15

Authorization Exception Management Message Encryption Message Replay Detection Message Signing Message Validation Deployment

Web as a media and Web Services as a technology is emerging as a mode of business-to-business and ecommerce transactions. Most of these transactions will carry business-critical and sensitive information that must be secured. Like any other technology domain, secure Web Services is complex and possibly overwhelming. Addressing a breach-in that includes cost of liability, public relations, and loss of business could be more expensive than implementing security measures in advance. Also, security should be enforced throughout the infrastructure. Research issues include Web Services technology, its vulnerabilities, enforcing security in this media, emerging security standards incorporating into Web Services applications. [4-6] II. DESIGN PATTERNS FOR SOA WEB SERVICES A. Design Patterns for Building Message-Oriented Web Services There are six steps involved in building message-oriented Web services, which is simply a Web service that exchanges XML schema-based input and output messages rather than simple parameter-oriented values. The steps are described in the following sections.[7] Step 1: Design the Messages and Data Types Step 2: Build the XSD Schema File for the Data Types Step 3: Create a Class File of Interface Definitions for the Messages and Data Types Options step 3A: Generate the WSDL Document Manually Step 4: Implement the Interface in the Web Service CodeBehind File Step 5: Generate a Proxy Class File for Clients Based on the WSDL Document Step 6: Implement a Web Service Client Using a Proxy Class File B. Design Patterns for Building Service-Oriented Web Services Message-oriented web services are the building blocks for service-oriented applications. There are six steps involved in building a message oriented web service that is compatible with SOA.[8] Step 1: Create a dedicated type definition Assembly Step 2: Create a Dedicated Business Assembly 2010 ACEEE DOI: 01.IJCOM.01.03.181

ACEEE Int. J. on Communication, Vol. 01, No. 03, Dec 2010

security token as proof of successful authentication. The client attaches this token to the request and the service uses this token to authenticate the client. There are some authentication brokers such as VeriSign, Windows Active Directory exists. B. Implementation and Validation Refer to Figure 1 which consists of class diagram for Place trade before UserNameToken. Client requests the web page for placing the trade; Stock Trader sends the respond as web page along with the request to enter "accNo., symbol, share, price, tradeType" values; Client enters the values and invokes the page; Trader sends the respond as an xml page acceptance.No security involves in this approach.
PlaceTrader
accNo : string symbol : string share : int price : double tradeType : string setData()

Refer to Figure 3 which consists of class diagram for RequestQuote. Client requests for RequestQuote web page; Trader replies with page by asking the client to enter "symbol, tradeType" values; Client enters the values and invokes; Trader makes a security checkup with StockTraderSecure and sends the reply; Reply consists of all the trade values of particular symbol.
StockTrader Client requests

StockTrader

sends the page client sets the data

RequestQuote
symbol : string tradeType : string

StockTraderTyp es
field : string status : string

StockTraderTyp es
field : string status : string

setData()

Figure 3. Class diagram for RequestQuote

client sets the trade details requests StockTrader Client responds StockTrader

An Active Directory Kerberos ticket has a default of ten hours duration. Client need to request the token once during the session. Brokered Authentication can be implemented in using WSE 3.0 in: Kerberos; X.509 certificates; Custom security token. Brokered Authentication using Mutual Certificate using X.509 certificate option is given as below. (Refer Figure 4)

StockTraderSecure

Figure 1. Class diagram for Place trade before UserNameToken.

Refer to Figure 2 which consists of class diagram for Place trade after UserNameToken. Client requests the web page for placing the trade; Stock Trader sends the respond as web page along with the request to enter "accNo., symbol, share, price, tradeType" values; Client enters the values and invokes the page; Trader requests for security checkup; StockTraderSecure checks the usernametoken value for specified client and generates reply to Trader; Trader sends the respond as an xml page. Security is involved as UserNameToken value.
Figure 4. Class Diagram for Mutual Certificate assertion message flow.
PlaceTrader
accNo : string symbol : string share : int price : double tradeType : string setData()

StockTraderTyp es
field : string status : string

client sets the trade details requests StockTrader C lie nt responds StockTrader

gives use rnam etoken

StockTraderSecure
t okenValue : strin g cli entId : strin g se tToke n() se curity Checkup()

requests for security checkup

Figure 2. Class diagram for Place trade after UserNameToken.

The steps involved are given as: Attach X.509 certificate to the message at client side; Sign the message using the clients private key; Encrypt the message using the services public key; Validate the client certificate; Decrypt the message at service side using private key of service; Validate the signature by decrypting it using public key of client. Brokered Authentication using Kerberos Protocol option is as follows: When user logs in, client encrypts the password using a symmetric key and sends a request to the KDC (Key Distribution Center) for a Ticket Granting Ticket (TGT). If key matches the value stored in Active Directory the KDC sends the TGT and session key. This session key is encrypted by KDC using users long term key. The TGT is encrypted using KDC secret key. The client sends a request to KDC. The KDC decrypts the TGT with long term key, and decrypts the authenticator 16

2010 ACEEE DOI: 01.IJCOM.01.03.181

ACEEE Int. J. on Communication, Vol. 01, No. 03, Dec 2010

using session key. KDC validates and creates new session key. The server receives the request that has the Kerberos security token attached to it. Server will use session key to decrypt the authenticator. For details of implementation, source code and detailed UML diagrams, Please refer to the web site, http://sites.google.com/site/upendramgitcse CONCLUSIONS In this paper, we implemented and validated architecting secure SOA Web Services, with a case study of an application StockTrader Security using WS-Security. Extensions of this work includes usage of WS-Secure conversation. Future work includes, Web Service security represents a key requirement for todays distributed interconnected digital world and for the new Web generations, such as Web 2.0 and the Semantic Web. To date, the problem of security has been investigated very much in the context of standardization efforts; these efforts, however, have dealt mainly with adapting existing security techniques, such as encryption, for use in Web Services. The standards have also focused on addressing the problem of security interoperability through the development of standard formats for security assertions, tokens and credentials. Interoperability is certainly an important issue for Web Services in that easy and flexible service composition requires that security-relevant information be seamlessly transmitted across different services. However, several key issues have not yet been addressed, such as crucial security techniques in the presence of highly fragmented service systems; metrics and methodologies to assess the security provided by an application or system organized according to the SOA paradigm; understanding the impact of security and privacy on service composition; and identifying security and privacy requirements for novel collaborative environments and social networks enabled by the Web and devising solutions to address these requirements. ACKNOWLEDGMENT The authors wish to thank the following for implementing these concepts: A.Madhuri, Lavanya, Ch.Venkatabhilash, Anusha Joga, Y.Apoorva Rani and S.Vamshidher Reddy.

REFERENCES
[1] Stephan Bode, Anja Fischer, Winfried Kuhnhauser and Matthias Riebisch, Software Architectural Design meets Security Engineering, 16 th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems, pp. 109 118, 2009. [2] S.Michelle Oda, Huirong Fu and Ye Zhu, Enterprise Information Security Architecture A Review of Frameworks, Methodology, and Case Studies, IEEE 2009 pp. 333 337, IEEE. [3] E.Bertino et al., Security for Web Services and ServiceOriented Architectures, Springer-Verlag Berlin Heidelberg 2010. [4] Jeremy Epstein, Scott Matsumotto and Gary McGraw, Software Security and SOA: Danger, Will Robinson, IEEE Security and Privacy, January/February 2006, pp. 8083. [5] Gunnar Peterson and Deborah A.Frincke, Service-Oriented Security Indications for Use, IEEE Security and Privacy, March/April 2009, pp. 9193. [6] Asoke K. Talukder and Manish Chaitanya, Architecting Secure Software System. CRC Press, 2009. [7] Soumya Simanta, Ed Morris, Sriram Balasubramaniam, Jeff Davenport and Dennis B.Smith, Information Assurance Challenges and Strategies for Securing SOA Environments and Web Services, IEEE SysCon 20093 rd Annual IEEE International Systems Conference, Vancouver, Canada, March 23 26 2009. [8] K.V.S.N.Rama Rao, Anirban Pal, and Manas Ranjan Patra, A Service Oriented Architectural Design for Building Intrusion Detection Systems, International Journal of Recent Trends in Engineering, Vol. 1, No. 2, May 2009 ACEEE Academy Publishers Poster Paper pp. 11 14. [9] G.Rayana Gouds, M.Sriivasa Rao and Akhilesh Soni , Semantic Firewall: An approach towards Autonomouos Web Security in Service Oriented Environments, International Journal of Recent Trends in Engineering, Vol. 1, No. 1, May 2009 ACEEE Academy Publishers pp. 454 458. [10] Eduardo B.Fernandez, Michael Thomsen, and Minjie H.Fernandez, Comparing the Security Architectures of Sun ONE and Microsoft .NET, Idea Group Inc. 2004. [11] Massimo Bartoletti, Pierpaolo Degano, Gian Luigi Ferrari and Roberto Zunino, Semantics Based Design for Secure Web Services, IEEE Transactions on Software Engineering, vol. 34 no. 1, pp. 3349, January-February 2008. [12] Anoop Singhal and Theodore Winograd, Guide to Secure Web Services. NIST Draft (800-95), September 2006. [13] David Chappell, Introducing Service Component Architecture (SCA), July 2007, Computer Society of India CommunicationsAugust2009,pp.3039.

17 2010 ACEEE DOI: 01.IJCOM.01.03.181