ACEEE Int. J. on Communication, Vol. 01, No. 03, Dec 2010
Secure Architecture Evaluation for Agent Based Web Service Discovery V. Prasath1, R.Baskarane2 and P.Savaridassan3 1,2
2
Department of CSE, AssistantProfessor,1,2Christ College of Engineering and Technology,Puducherry,India. Email: 1prasathvijayan@gmail.com, 2baskarannew@gmail.com 3 Department of IT, 3Dr.SJS Pauls College of Engineering and Technology,Puducherry,India. Email: 3savari.pecit@gmail.com
Abstract—Web Services can be published, discovered and invoked over the web. Web Services can be implemented in any available technology but they are accessible through a standard protocol. With web services being accepted and deployed in both research and industrial areas, the security related issues become important. In this paper, architecture evaluated for web service on negotiating a mutually acceptable security policy based on web service description language to both consumer and provider [1]. It allows a service consumer to discover and retrieve a service-provider’s security policy for service requests and allows a service consumer to send its own security policy for service responses to the service provider. The service consumer combines its own policy for service requests with that of the service provider to obtain the applied security policy for requests, which specifies the set of security operations that the consumer must perform on the request. The combining takes place in such a way that the applied security policy is consistent with both the consumer’s and provider’s security policies. The service provider also combines its own policy for responses with that of the consumer, to obtain the applied security policy for responses.
service provider and a service consumer. The WSDL document of a web service would include a security policy description representing the types of security operations that are required and supported by the Web-service for its SOAP message exchanges with consumers. II. SYSTEM OVERVIEW A. Service Discovery Web service discovery can be performed based on a web service security policy using agents. It consists of a service provider, a service consumer and a UDDI to include a discovery agent and security agent and use an augmented UDDI that contains security policy information to allow secure web service discovery (as shown in Figure1). The discovery agent acts as a broker between a service consumer, a UDDI registry and a security policy that helps to discover secure web services that satisfy the consumer security requirements. B. Security Agent The security agent describes the security requirement that service provider needs to be registering their WSDL into the registry. Web service security test case describe a testing methodology for web service security and outline a process that can be adopted to evaluate web service security requirements [8]. Test case can be classified according to different categories of threat faced by web services. Security policy can be represented in the UDDI registry which is typically used to specify the security policy details of a web service.
Index Terms—Web Service discovery, Security Service, Security policy, Agent, ATAM, Web Services Security
I. INTRODUCTION Web services are reusable Web components with their programmatic interfaces described in WSDL.WSDL is a XML format standard for describing the interface of a web service. The WSDL description gives information about what exactly a web service does, how to invoke its functions and where to find it. Universal Description, Discovery, and Integration (UDDI) is a registry standard, which allows organizations to publish and discover Web Services using standardised methods [4]. The UDDI is an industry initiative to provide a platform-independent framework for creating a UDDI Business Registry. There are currently several providers of UDDI registers called UDDI Operators. The UDDI specification defines a set of data structures and an Application Programming Interface (API) for registering and finding businesses [5]. The UDDI specification also allows organizations to create their own UDDI registries in order to have more control for the access and the updating of information, and the reliability of the registry content. We concentrate here on one key issue, providing security in Web services architecture. In this paper, we evaluated a technique for deriving mutually acceptable quality of protection for exchanges between a
C. Discovery Agent A discovery agent receives service requests containing specifications for functional and security requirements from the service consumer, finds the services that meet the
Figure 1. Web service discovery using agents
1 © 2010 ACEEE DOI: 01.IJCOM.01.03.43
ACEEE Int. J. on Communication, Vol. 01, No. 03, Dec 2010
IV. EVALUATION OF PROPOSED ARCHITECTURE
specified criteria, and then returns a list of services to the consumer in the order of priority. Discovery should be based on web service security polices for concerned request. The list of available services will be return to the service consumer in order. This avoids the overhead of discovery mechanism to search secure web services over UDDI registry for consumers needs.
The proposed architecture is evaluated by the Software Architecture Tradeoff Analysis Method (ATAM).All the scenarios corresponding to each application of the secure web service discovery and retrieval are listed and evaluated. A. ATAM: Secure Web Service Discovery We put ATAM to the test on our architecture and discuss the findings based on the outputs generated which include lists of risks, non-risks, sensitivities, and tradeoffs made. The findings show that secure web service discovery and retrieval architecture can greatly benefit from using ATAM by revealing its strengths and weaknesses before evolving the architecture further. It generates a number of outputs such as: a prioritised list of quality attributes, a list of architectural decisions made, a map linking architectural decisions to quality attributes, lists of risks and non-risks, and lists of sensitivities and tradeoffs.
III. PROCESS MODEL The model works with the exception that the containers hosting the consumer and provider classes emit a SOAP message, which is intercepted by the security service. The consumer and provider classes could provide the <Security Mechanisms> and <Security Services> elements to their security services, in a WSS header, with the security service module identified as the target role. WSDL binding to support the publication of the security policy in the case that a provider offers a secured interface. Specifically, elements called <Security Mechanisms> and <Security Services> are associated with message definitions in the service’s WSDL instance. In addition, we specify a web service security header for conveying the consumer’s policy for service responses using the same element definitions. The <Security Mechanisms> element describes a set of security mechanism, which may be applied to one or more nodes of the SOAP document [1].
B. ATAM Process Phase 1 Step 1 - Presenting the ATAM Process ATAM stands for Architecture Tradeoff Analysis Method. It is a method that tells how well an architecture satisfies particular goals by providing insight of how quality goals interact and how they trade off. Step 2 - Present Business Drivers •Due to the increase of business-to-business communication between different organizations over internet resources, the current architecture will provide secure service connection establishment between service consumer and provider with added security policy. •Suggest the service provider to accept the service consumer requirements to add new security features to perform secure tasks. Architecture Drivers The major quality attribute are as below Priority
Figure 2. Model for web service security policy Input: User request with specified security criteria Output: Secure match set of services from UDDI u(h): Select all the services which matches the functionality requirements of user request that exists in UDDI. Let u(h)={ws1,ws2…..wsn}wss (h): Choose the set of services which have been registered in UDDI with security specifications. Let wss(h)={ws1(s), ws2(s), ….wsi(s)} Step 1 : For each web services wsi in u(h) //find the services that match the QOS requirements Step 2: QoS based Selection=Qos_Match (u(h) , QWS Parameters); Step 3 : If wss(h) requirements specified then Step4 :{Secuirty_Search=Security_Match (QoS_Search,wss(h) specified); Step5 : If wss(h) ratings found then //find the services that matches security criteria Step6 : return output of available services in wssi in u (h) according to criteria rank} Step7 :{Else return the output of available services wsi in u (h)}
Rationale
1
Security
It is a major concern to this area of the architecture because it should support authentication, encryption and integrity over different communication channel and platform model.
3
Availability
The service should be in need to run at any time even system failure occurs over UDDI registry or service provider.
4
Performance
Continues user request will affect the system response. we will establish the user connection based on token request.
Step 3 - Presenting architecture
Figure 3. Service discovery algorithm
2 © 2010 ACEEE DOI: 01.IJCOM.01.03.43
Quality Attribute Driver
ACEEE Int. J. on Communication, Vol. 01, No. 03, Dec 2010
Scenario#: 2 Attribute(s) Environment Stimulus Response Arch decision Sensitivity Tradeoff Risk Non risk
Scenario: Authentication Security Normal operations Service ticket has way to establish trust relationship with more than one security domain utility certificate are required to verify the user authorization Reasoning Utility certificate More computation time and resource used, Performance, but not too much. Provide certificate to user in more secret Not apply here.
Step 4 - Identify Architecture Approaches Important Approaches of the Secure Web Service Discovery and Retrieval Architectural Approach Layering
Rationale
Trade-offs
It organizes the system in hierarchical structure that allows for easy system modification.
Security potentially reduced risk
Step 5 - Quality Attribute Utility Tree I=Importance, D=Difficulty to achieve, H, M, L = high, medium, low Quality Attribute Security
Attribute Refinement Confidentiality
Integrity
Authentication
Non-reputation
Scenarios
(I, D)
Users' information shall only be visible to users of the system and it is encrypted before transmitting to the server. The system resists unauthorized intrusion and modification of data. This enables the user to access the service with required token It verifies the signed information from valid user
(H,L)
Response Arch decision Sensitivity Tradeoff Risk Non risk
Response
Intermediary has no way to read the message while establishing connection with service provider
Arch decision Sensitivity Tradeoff
Reasoning The encryption algorithm. More computation time and resource used. Performance is the tradeoff with Security.
Risk
Not apply to architecture, but the Encryption algorithm itself, if it is not complex enough, could be hacked by brute force.
Non risk
Not apply here.
(H,M)
Response Arch decision Sensitivity Tradeoff
(H,M)
(H,M)
Risk Non risk
Scenario: Non-reputation Security Normal operations Utility has key certificate to form signed message to verify the user utility key certificate are required to verify the user sign information Reasoning Utility key certificate Need signed key information for operation response Provide certificate to user in more secret Not apply here.
Step 7 - Scenario Prioritization The following table prioritizes the Quality Scenarios for the secure web service discovery and retrieval architecture. The Scenario # refers to the scenario being referenced.
Scenario: Integrity Security Normal operations Unauthorized user without security token cannot able to access the service available in the registry Identity Certificate are required to verify the user authentication Reasoning Identity certificate Need resource to map data, Performance, but not too much. Provide certificate to user in more secret Not apply here.
3 Š 2010 ACEEE DOI: 01.IJCOM.01.03.43
Scenario: Confidentiality Security Normal operations Certificate authority has to provide security token to authenticate
Scenario#: 4 Attribute(s) Environment Stimulus
Step 6 - Architecture elicitation and analysis Scenario#:1 Attribute(s) Environment Stimulus
Scenario#: 3 Attribute(s) Environment Stimulus
Priority 1
Scenario # 3,2 (Security)
4
1,3,4 (Security)
Scenario Stimulus Transmission of the data over secure communication
User information shall only be visible to administrative users of the system and it is encrypted before transmission
Prioritization Rationale It support user data from unauthorized access This is to build users confident on using the system.
ACEEE Int. J. on Communication, Vol. 01, No. 03, Dec 2010
[3] Janette Hicks, Madhusudhan Govindaraju, Weiyi Meng, “Enhancing Discovery of Web Services through Optimized Algorithms” IEEE International Conference on Granular Computing 2007 pp 685 - 698. [4] Colin Atkinson, Philipp Bostan, Oliver Hummel and Dietmar Stoll, “A Practical Approach to Web Service Discovery and Retrieval”,IEEE International Conference on Web Services (ICWS 2007). [5] Slim Trabelsi Jean-Christphe Pazzaglia Yves Roudier, “Secure Web Service discovery: overcoming challenges of ubiquitous computing”, Proceedings of the European Conference on Web Services (ECOWS'06). [6] David Geer, “Taking Steps to Secure Web Services”, Technology News October 2003. [7] “Evaluating a software architecture and its process”, CS471b Software Design and Architecture,Group14NZB electronic banking system April 8, 2005. [8] “A Web Services Security Testing Framework” Version: 1.00 SIFT Information security services,Nov 10, 2006.
V. CONCLUSIONS Universal Description Discovery and Integration has no way to identify the secure web services when multiple service providers are now providing similar functional services. An architecture evaluated called agent based web service discovery to automate secure web service discovery for negotiating a mutually acceptable security policy based on web service description language for both consumer and provider in dynamic nature. REFERENCES [1] Zahid Ahmed, Martijn de Boer,, Monica Martin, Prateek Mishra, Dale Moberg, “Web-Services Security Quality of Protection”, Version 0.9 22 Nov 2002. [2] Kassem Saleh and Maryam Habil, “The Security Requirements Behavior Model for Trustworthy Software”, International MCETECH Conference on e-Technologies 2008 pp 235 - 238.
4 © 2010 ACEEE DOI: 01.IJCOM.01.03.43