Architecting Secure Service Oriented WebServices by ides editor

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 1

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 Women’s 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

Abstract—The 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, it’s 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.

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

Index Terms— Security Architectures, Service Oriented Architectures, Web Services Security, WS-Security, WSSecure Conversation.

Lauer 2: Web Services Engine

SERVICE ORIENTED WEB SERVICES SECURITY ARCHITECTURES

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

Layer 3: Web Services Deployment

Layer 4: Services Code

Web User

Attacks and Threats 1. 2. 3. 1. 2. 3. 4.

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

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

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

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

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

Trusted Subsystem Exception Shielding Data Confidentiality Message Replay Detection Data Origin Authentication Message Validator Perimeter Service Router

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]

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]

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.

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

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.

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

Brokered Authentication: The client and service do not attempt to authenticate each other directly. They use an intermediary that validates the client’s identity and then provides a 15

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

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.

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.

StockTrader Client

sends the page

RequestQuote

PlaceTrader StockTraderTyp es

setData()

StockTraderTyp es field : string status : string

field : string status : string

Figure 3. Class diagram for RequestQuote

setData()

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)

client sets the trade details requests StockTrader Client

StockTrader

client sets the data

symbol : string tradeType : string

accNo : string symbol : string share : int price : double tradeType : string

requests

responds

StockTrader

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.

The steps involved are given as: Attach X.509 certificate to the message at client side; Sign the message using the client’s private key; Encrypt the message using the service’s 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 user’s 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

PlaceTrader accNo : string symbol : string share : int price : double tradeType : string

StockTraderTyp es field : string status : string

setData()

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

requests for security checkup

se tToke n() se curity Checkup()

Figure 2. Class diagram for Place trade after UserNameToken.

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

REFERENCES

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

[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. 80–83. [5] Gunnar Peterson and Deborah A.Frincke, “Service-Oriented Security Indications for Use”, IEEE Security and Privacy, March/April 2009, pp. 91–93. [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 2009—3 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. 33–49, 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.30–39.

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 today’s 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.