Multi-Level Secure Architecture for Distributed Integrated Web Services

Multi-Level Secure Architecture for Distributed Integrated Web Services

J.G.R.Sathiaseelan

S.Albert Rabara

J.Ronald Martin

Department of Computer Science Bishop Heber College (Autonomous) Tiruchirappalli – 620 017, India [email protected]

Department of Computer Science St Joseph’s College (Autonomous) Tiruchirappalli – 620 002, India [email protected]

Department of Computer Science St Joseph’s College (Autonomous) Tiruchirappalli – 620 002, India [email protected]

web portals etc. Such domains using web services have made the software vendors and the web developers to design, develop and deploy the complex web applications for the diverse organizations. While Web services offer several benefits, security is still a major concern. Hence, Web developers and the researchers felt the need of providing the secured web services for the web users. There have been quite a lot of research initiatives in the field of Web services for enterprise applications. However, none of the initiatives have attempted for academic related applications using Web services technology. This paper proposes a Multi-level Secured Architecture (MLSA) for the academic institutions that provides multiple secured web services such as student admission service, fees payment service, course details service, personalized service for the students, staff and management etc. This system provides the integrated Web services through Integrated Web Services Manager (IWSM). This framework is designed and well suited for the academic institutions to handle the educational related services with multi-level security. The rest of this paper is organized as follows: Section 2 presents the review of research papers on the various issues of Web services and Web services security. In section 3, the architectural design for the proposed system is presented. Section 4 describes the security issues pertaining to the Multi-level Secured Architecture (MLSA) for the academic institutions. In Section 5, protocol and sequence diagram for MLSA are presented. Section 6 provides the conclusion of this paper.

Abstract—The recent development in the field of Web services technology has transformed the software industry radically by integrating a wide range of web users, vendors, and enterprise applications worldwide. There are various research initiatives made in Web services security which is an emerging trend in the field of Web services technology for the development of a large variety of enterprise applications. However, none of the initiatives made an attempt for the development of web applications intended for the academic institutions using integrated Web services technology. Extensive studies reveal that there is no attempt made so far to provide multi-level security for such web applications. The main objective of this paper is to propose a generic architecture called Multi-Level Secure Architecture (MLSA) exclusively for the academic institutions that provides integrated web services in a secured manner. In addition, MLSA has been designed to integrate as well as distribute a variety of web services to the users with multi-level security. Keywords-Web engineering; Web Services; Multi-level Security; Authentication; Encryption.

I.

INTRODUCTION

There is an exorbitant growth in the emerging field of Web engineering in the recent years which leads to the establishment and use of sound scientific, engineering, and management principles and disciplined and systematic approaches to successfully develop, deploy, and maintain high quality web applications [1]. Web developers, clients, academicians, researchers and government agencies have increasingly become interested in the new field of Web engineering. By and large, web applications are grouped into seven broad categories based on their scope and complexity [2]. A practical approach to develop large, complex Web applications is to follow a sound development process and methodology. This scenario has motivated Web developers, academicians and researchers to focus upon the better web development methodologies, techniques, and tools. Ten key steps for the successful Web development are recommended in [3]. Ginige [4] has proposed a systematic approach for the development of large complex web applications. However, there has been no considerable focus rendered towards the wide range of web services used in the web application developed for an organization. Web services technology delivers a new generation of enterprise applications such as e-shopping, on-line banking,

II. WEB SERVICES Web service is a software application designed primarily to provide support for an interoperable machine-to-machine communication through Internet using three major XMLbased standards such as Simple Object Access Protocol (SOAP) [5], Web Services Description Language (WSDL) [6] and Universal Description Discovery and Integration (UDDI) [7]. A. Web Service Architecture A typical web service technology encompasses three basic elements: • Service Requester – A client or web user who makes request for the execution of web services.

_____________________________________

978-1-4244-5539-3/10/$26.00 ©2010 IEEE

180

•

Microsoft, etc proposed Web Services Security specifications [9], [10]. Several languages are developed for the same purpose. One such language is Web Services Security Language i.e. WS-Security which is the extension of SOAP used for integrity and confidentiality. Other languages which are the extensions of XML are • XML Signature [11] provides integrity, message authentication and signer authentication. • XML Encryption [12] gives details to encrypt the XML document and sends the same securely. • XKMS [13] specifies protocols for distributing and registering public keys used in conjunction with XML Signature. • XACML [14] is a markup language which is an industry accepted standard that provides a well defined structure to specify policies to perform complex authorization decisions. There are other technologies also for making secure communications over HTTP like SSL and TLS. The usage of IPsec is another way of securing web service messages that provides confidentiality, integrity, peer authentication and replay protection [15]. However none of the initiatives have made an attempt to provide secured web services in a distributed web application at multi-level in the academic field. This situation has urged us to propose an architectural design exclusively for an academic related web application in a more secured manner.

Service Provider – A platform that provides a set of services to the client. • Service Registry – A storehouse where a service provider publishes its services. The interaction among the three elements of web service architecture is shown in Fig. 1.

Service Registry

Publish

Find

Bind Service Requester

Service Provider

Figure 1. Web Service Architecture

In a typical web service scenario, a web service provider initially describes a web service and then publishes it to a service registry. A service requester who is a client or web user obtains the web service description from the service registry and calls the web service from the service provider which then gets executed. The major success of web service technology is primarily based on the usage of standard communication protocols particularly HTTP and XML. Furthermore, the other standard protocols that a full-fledged web service requires are: • SOAP: It is a protocol which defines a uniform way of passing an XML message [5]. A SOAP message that has the name and parameters of the method invokes the service provider and returns the values to the client. Thus SOAP message can work with any operating system, programming language or platform. • WSDL: It is a description language [6] used to describe the location of a web service and how to access it. • UDDI: It offers a storage service [7] and provides a mechanism for the service requesters to find services published by service providers. Thus it has both service providers and service requesters as its clients to publish and to find web services respectively. This architectural structure of web service has been implemented in our previous work [8] that has become the pioneer for the development of a new architecture for integrated web services exclusively for academic institutions.

III. ARCHITECTURAL DESIGN FOR THE PROPOSED MODEL The Multilevel Secure Architecture (MLSA) has been proposed primarily for making use of academic related web services where secure communication becomes paramount. There are two types of web users namely External Users (EU) and Internal Users (IU) involved in this proposed model. The External User (EU) is the web client and the consumer of the web services provided by different academic institutions. The Integrated Web Services Manager (IWSM) is acting as a gateway for providing an interface only to the external users. The Internal User (IU) could be a student, a faculty member, or an employee of a particular academic institution and is using the web services provided directly by that institution without the intervention of IWSM. The Integrated Corporations (IC) are huge group of academic institutions that are located in different geographical area which are represented as Corporate-1, Corporate-2 … Corporate-n as found in the proposed model. Thus, MLSA is designed principally for the academic institutions to provide integrated web services for the clients. The architectural design of MLSA is depicted in Fig. 2.

B. Web Service Security Security has become a main concern now-a-days for the deployment of web services in a secure manner. Therefore, web service security needs to have more concern for the key security issues such as authentication, authorization, confidentiality and integrity. Recently, a variety of organizations and standards groups including OASIS, IBM,

181

4. Service Execution: The IC executes the web services and sends the service response to CWSM. If the web services require database access, then the connection is established with the institution Database Security Manager (DBSM). The DBSM validates the access privileges and returns the data with data service to CWSM. 5. Service Response: The CWSM encrypts the service response and returns the encrypted response to IWSM using the Public Key Infrastructure (PKI) [16]. If the web services do not require data access, then the service is executed. The IWSM decrypts the service response and forwards it to the external user. An Internal User (IU) is a student, a faculty member, or an employee of a particular academic institution e.g. Corporate-i who is directly using the web services provided only by Corporate-i. Being the part of the Corporate, the internal user need not pass through the interface IWSM. The Institution Security Manager (ISM) of IC authenticates the internal user with username and password. After successful authentication, the IC executes the web services and sends the service response to the internal user. If the web services require database access, then the connection is established with the institution Database Security Manager (DBSM). The DBSM validates the access privileges and returns the data with data service to the internal user

Figure 2. Multi-Level Secure Architecture for Distributed Integrated Web Services

In MLSA, the external user initially submits the queries for the web services to IWSM in an encrypted form. IWSM decrypts and validates the queries for free of virus or spam. In case of virus or spam, IWSM returns the queries to the external user. In case of no virus or spam, the queries are encrypted by IWSM and forwarded to the appropriate CWSMs on the basis of load balancing. Each CWSM has both the Client Security Manager (CSM) and Service Security Manager (SSM). The CSM would then authenticate the IWSM. After the successful authentication, the SSM defines and configures the queries and forwards them to the respective IC. After authorization of queries, IC executes the appropriate web services and sends the service response or data back to respective CWSM. The CWSM would compose those web services and forward the composite web service to the IWSM in an encrypted form. Finally, the IWSM provides the composite web service for the use of external user in a decrypted form. IV.

V. PROTOCOL AND SEQUENCE DIAGRAM FOR MLSA The entire functional activities of Multi-level Secured Architecture (MLSA) are graphically depicted in the following protocol and sequence diagram. A. Protocol for MLSA The following protocol illustrates an entire process of the proposed architecture MLSA. Let UQry – User Queries EUQry – Encrypted User Queries DUQry – Decrypted User Queries CWS – Composite Web Service ESResp – Encrypted CWS response DSResp – Decrypted CWS response 1. EU  EUQry  IWSM IWSM DUQry; IWSM  filters (Spam, Virus) If (DUQry spam, virus) { IWSM  EUQry  CWSM } Else { IWSM  DUQry  EU }

SECURITY ASPECTS OF MLSA

The key feature of our proposed architecture MLSA is to enhance the security at various levels such as user level, web services manager level, institutional services level and database level. In MLSA, the external user request is processed in 5 stages using the web service technology: 1. Request Initiation: Initially, the external user submits the queries to the IWSM in the form of encryption. 2. Authentication: The authentication process between IWSM and CWSM is carried out in 4 phases: i) Session between IWSM and CWSM is created. ii) X.509 certificate with public key is exchanged between IWSM and CWSM. iii) Certificate is validated. iv) User request is forwarded. 3. Service Configuration: After successful authentication between IWSM and CWSM, the SSM defines, configures, and binds the services and sends the queries to the respective IC.

2. CSM  Auth  IWSM If (Auth is valid) { IWSM  UserIC  CSM CSM  UQry  SSM } Else { CSM  UQry  IWSM }

182

3. SSM  CWS = Config (UQry) { If (UQry in ServiceRegistry found) { Log (UQry)  UQryLogId Split (UQryLogId, UQry) CWS } Else { SSM  Send (failure_msg1)  IWSM } } 4. SSM  CWS  IC If (CWS in ServiceRegistry found) { If (DataReq = 1) { DBSM  Y = Access_Validate (CWS) If (Y is valid) { DBSM Data_service ServiceResp } Else { DBSM Send (failure_msg2) IC }

VI.

RELATED WORK

Qi Yu et al [17] proposed a concrete Web service foundation called Web Service Management System (WSMS) that offers a solid framework for effectively developing, deploying, discovering, publishing, composing, monitoring and optimizing access to Web service. The security/privacy component in the WSMS architecture ensures the implementation of typical security functionalities such as auditing, authentication, access control, and data encryption. While these security issues were described as a summary, none of these issues has been discussed at length. S. Chollet et al [18] presented a tool for supporting and facilitating the integration of Web services. The major security concepts pertaining to Web service composition are authentication, integrity and confidentiality which are handled by login/password authentication, signature with an X.509 certificate and encryption respectively. However, the other important security issues such as authorization of Web services, non-repudiation, etc have not been highlighted. G. Hwang et al [19] proposed an operational model to provide support for securing the Web service transactions. In addition to fulfilling the essential security requirements such as authentication, confidentiality, data integrity and nonrepudiation, this model provides support for security mechanisms like element-wise encryption and temporalbased element-wise digital signatures. This model also supports an explicit key definition which defines three types of keys such as static keys, dynamically selected keys, and keys applied to digital signatures. This model has still limitations and needs to be experimented with distributed enterprise applications. Weiliang Zhao et al [20] proposed trust management architecture for web services to build a trust management layer which extends WS-Trust and covers existing trust mechanisms including credentials, reputation, data storage, etc. Since the primary focus of this work is to provide highlevel guidelines for the development of trust management solution in web services, the other security issues such as

} Else { Execute (CWS) ServiceResp } } Else { IC Send (failure_msg3) SSM } 5. IC  ServiceResp  CWSM CWSM ESResp = Encryption (ServiceResp)  IWSM IWSM  DSResp = Decryption (ESResp)  EU

B. Sequence Diagram for MLSA The following sequence diagram exhibits the various security aspects that are carried out throughout the execution of the proposed architecture MLSA.

183

authentication, confidentiality, data integrity and nonrepudiation have not been exposed. Wei She et al [21] proposed a security model to support the control of information flow through service chains occurred as composite web services. This model also extends the basic security models by introducing the concepts of delegation and pass-on policies to secure interactions in a composed web services. Still this work has provided a foundation for further development of a widespread security model for well-controlled secure web service interactions. Therefore, we have proposed a generic architecture for academic institutions called Multi-Level Secure Architecture (MLSA) which provides integrated web services such as student’s admission service, fees payment service, course details service, personalized service for the students, teaching faculty and the staff employed in a secured manner.

[6]

VII. CONCLUSION

[17]

[7] [8]

[9] [10] [11] [12] [13] [14] [15] [16]

The Web Services technology has gained the impetus towards the development of the web applications for the wide range of domains. The integration of composite web services with higher level of security has become the major demand of the diverse organizations. This paper proposes a Multi-level Secured Architecture (MLSA) for academic institutions that provides multiple secured web services such as admission service, fees payment service, course details service, personalized service for the students, staff and management etc. This architecture provides the secured integrated academic composite web services for the web users through Integrated Web Services Manager (IWSM) that acts as an intermediary between the users and the various academic institutions located in different geographical area. The MLSA has also been designed to enhance the security at multilevel such as user level, web services manager level, institutional services level and database level. This model can provide a foundation for further research and development of a universal security paradigm for integrated composite web services pertaining to academic institutions spread out world-wide.

[18]

[19]

[20]

[21]

REFERENCES [1]

[2] [3]

[4]

[5]

S. Murugesan, Y. Deshpande, S. Hansen and A. Ginige, “Web Engineering: A New Discipline for Development of Web-based Systems,” Proceedings of the First ICSE Workshop on Web Engineering, International Conference on Software Engineering, Los Angeles, May 1999. A. Ginige and S. Murugesan, “Web Engineering: An Introduction,” IEEE Multimedia, vol. 8, no.1, pp. 14-18, Jan.–Mar. 2001. A. Ginige and S. Murugesan, “The Essence of Web Engineering – Managing the Diversity and Complexity of Web Application Development,” IEEE Multimedia, vol. 8, no.2, pp. 22-25, Apr.–Jun. 2001. A. Ginige, “Web Engineering: Managing the Complexity of Web Systems Development,” Proceedings of SEKE 02, Ischia, Italy, ACM Press, July 2002. SOAP Version 1.2, http://www.w3.org/TR/2003/REC-soap12-part020030624/ (2003)

184

Web Services Description Language (WSDL)Version 2.0, http://www.w3.org/2002/ws/desc Universal Description, Discovery and Integration (UDDI), http://www.oasis-open.org/committees/uddi-spec/ J. G. R. Sathiaseelan, S. A. Rabara and J. R. Martin, “Multi-Level Secure Framework for Composite Web Services,” ACM International Conference Proceedings (ICIS), pp. 580–585, 2009. OASIS, http://docs.oasis-open.org IBM, Microsoft, RSA, and Verisign, http://specs.xmlsoap.org XML Signature, http://www.w3.org/TR/xmldsig-core/ XML Encryption,http://www.ibm.com/developerworks/xml/library/sxmlsec.html/index.html#h5816 XKMS, http://www.w3.org/TR/2001/NOTE-xkms-20010330/ XACML, http://www.oasis-open.org/events/xacml-interop-2008/ IPsec, http://csrc.nist.gov/publications/nistpubs/800-77/sp800-77.pdf P. Gutmann, “PKI: It’s Not Dead, Just Resting,” IEEE Security, pp. 41–49, 2002. Q. Y. Xumin Liu, A. Bouguettaya, and B. Medjahed, “Deploying and Managing Web Services: Issues, Solutions, and Directions,” VLDB Journal, Springer, 2008. S. Chollet and P. Lalanda, “An Extensible Abstract Service Orchestration Framework,” IEEE International Conference on Web Services (ICWS), 2009. G. H. Hwang, Y. H. Chang and T. K. Chang,“An Operational Model and Language Support for Securing Web Services,” IEEE International Conference on Web Services (ICWS), 2007. W. Zhao and V. Varadharajan, “Trust Management for Web Services,” IEEE International Conference on Web Services (ICWS), 2008. W. She, I. L. Yen, B. Thuraisingham, “Enhancing Security Modeling for Web Services using Delegation and Pass-on,” IEEE International Conference on Web Services (ICWS), 2008.