Architecting Secure Web Services using
Model Driven Agile Modeling
Dr.B.Padmaja Rani* K.Venkateswar Rao1 K.Mrunalini Devi2
*Associate Professor Department of CSE JNTU CEH Hyderabad A.P. India Email: [email protected]
1
Associate Professor Department of CSE JNTU CEH Hyderabad A.P. India Email: [email protected]
2 JNTU M.Tech CSE PTPG Student and Assistant Professor CS MIPGS Hyderabad A.P. India Email: [email protected]
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 inter-application 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 WS-Security 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, Security,
WS-Secure Conversation.
I. 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 well-defines 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 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.
TABLE 1. WEB SERVICES SECURITY THREAT FRAMEWORK
Web Services Layer Attacks and Threats
Layer 1: Web Services in Transit 1. In transit Sniffing or Spoofing
2. WS-Routing security concern
3. Replay attacks
Lauer 2: Web Services Engine 1. Buffer Overflow
2. XML parsing attacks
3. Spoiling Schema
4. Complex or Recursive structure as payload
5. Denial of Services
6. Large payload
Layer 3: Web Services Deployment 1. Fault Code Leaks
2. Permissions and Access issues
3. Poor Policies
4. Customized error leakage
5. Authentication and Certification
Layer 4: Web Services User Code 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
Refer to Table 2. Which consists of Web Services Security Patterns.
TABLE 2. WEB SERVICES SECURITY PATTERNS
Category Pattern
Authentication Brokered Authentication
Brokered Authentication: Kerberos Brokered Authentication: X509 PKI Brokered Authentication: STS Direct Authentication
Authorization Trusted Subsystem
Exception Management Exception Shielding
Message Encryption Data Confidentiality
Message Replay Detection Message Replay Detection
Message Signing Data Origin Authentication
Message Validation Message Validator
Deployment Perimeter Service Router
Web as a media and Web Services as a technology is emerging as a mode of business-to-business and e-commerce 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 SOAWEB 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 Code-Behind 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
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 SOAWEB SERVICES ARCHITECTURES
Web as a media and Web Services as a technology is emerging as a mode of business-to-business and e-commerce 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 SOAWEB SERVICES WITH WS_SECURITY –ACASE 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 client’s identity and then provides a 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
S t o c k T r a d e r S e c u r e
S t o c k T r a d e r S t o c k T r a d e r
C l i e n t
r e q u e s t s r e s p o n d s
P l a c e T r a d e r
a c c N o : s t r i n g s y m b o l : s t r i n g s h a r e : i n t p r i c e : d o u b l e t r a d e T y p e : s t r i n g s e t D a t a ( )
c l i e n t s e t s t h e t r a d e d e t a i l s
S t o c k T r a d e r T y p e s
f i e l d : s t r i n g s t a t u s : s t r i n g
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.
S t o c k T r a d e r T y p e s
f i e l d : s t r i n g s t a t u s : s t r i n g
S t o c k T r a d e r P l a c e T r a d e r
a c c N o : s t r i n g s y m b o l : s t r i n g s h a r e : i n t p r i c e : d o u b l e t r a d e T y p e : s t r i n g s e t D a t a ( )
S t o c k T r a d e r C l i e n t
r e q u e s t s r e s p o n d s c l i e n t s e t s t h e t r a d e d e t a i l s
S t o c k T r a d e r S e c u r e
t o k e n Va l u e : s t r i n g c l i e n t I d : s t r i n g s e t T o k e n ( ) s e c u r i t y C h e c k u p ( ) g i v e s u s e r n a m e t o k e n
r e q u e s t s f o r s e c u r i t y c h e c k u p
Figure 2. Class diagram for Place trade after UserNameToken.
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.
S to c k T r a d e r T y p e s
fi e l d : s t r i n g s t a t u s : s t r i n g
S t o c k T r a d e r
R e q u e s tQ u o te
s y m b o l : s t r i n g t r a d e T y p e : s t r i n g s e t D a t a ( )
S to c k T r a d e r
C li e n t r e q u e s ts
s e n d s th e p a g e
c l i e n t s e ts th e d a ta
Figure 3. Class diagram for RequestQuote
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 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.
Semantic Based Design for Web Services
Our methodology for designing and composing services in a secure manner. In particular, we are concerned with Safety properties of service behavior. Services can enforce security policies locally and can invoke other services that respect given security contracts. This call-by-contract mechanism offers a significant set of opportunities, each driving secure ways to compose services. We discuss how we can correctly plan service compositions in several relevant classes of services and security properties. With this aim, we propose a graphical modeling framework in this project. Our formalism features dynamic and static semantics, thus allowing for formal reasoning about systems. Static analysis and model checking techniques provide the designer with useful information to assess and fix possible vulnerabilities.(Refer to Figure 5 below)
Figure 5. Case study application fro sematics based Web Servies Design
An Integrated Framework for Security and Dependability
notation, then is validated against the security requirements through construction of a satisfaction argument. The satisfaction argument consists of two parts: a formal argument that the system can meet its security requirements and a structured informal argument supporting the assumptions expressed in the formal argument. The construction of the satisfaction argument may fail, revealing either that the security requirement cannot be satisfied in the context or that the context does not contain sufficient information to develop the argument. In this case, designers and architects are asked to provide additional design information to resolve the problems. We evaluate the framework by applying it to a security requirements analysis within an air traffic control technology evaluation project coding.(Refer to Figure 6)
Figure 6. DFD for Case study application for Security Requirements Engineering Dependability
For details of implementation, source code and detailed UML diagrams, Please refer to the web site,
http://sites.google.com/site/upendramgitcse
ACKNOWLEDGEMENTS
The authors wish to thank the following CSE students of MGIT for implementing these concepts: Preethi Bandaru, Pawar Kavitha and G.Anuradha
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.
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.
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 Service-Oriented 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.
