Privacy-Enhanced Web Service Composition

Privacy-Enhanced Web Service Composition

ABSTRACT:

Data as a Service (DaaS) builds on service-oriented technologies to enable fast access to data resources on the Web. However, this paradigm raises several new privacy concerns that traditional privacy models do not handle. In addition, DaaS composition may reveal privacy-sensitive information. In this paper, we propose a formal privacy model in order to extend DaaS descriptions with privacy capabilities. The privacy model allows a service to define a privacy policy and a set of privacy requirements. We also propose a privacy-preserving DaaS composition approach allowing to verify the compatibility between privacy requirements and policies in DaaS composition. We propose a negotiation mechanism that makes it possible to dynamically reconcile the privacy capabilities of services when incompatibilities arise in a composition. We validate the applicability of our proposal through a prototype implementation and a set of experiments.

EXISTING SYSTEM:

A typical example of modeling privacy is the Platform for Privacy Preferences (P3P). However, the major focus of P3P is to enable only Web sites to convey their privacy policies. In privacy only takes into account a limited set of data fields and rights. Data providers specify how to use the service (mandatory and optional data for querying the service), while individuals specify the type of access for each part of their personal data contained in the service: free, limited, or not given using a DAML-S ontology.

DISADVANTAGES OF EXISTING SYSTEM:

Two factors exacerbate the problem of privacy in DaaS. First, DaaS services collect and store a large amount of private information about users. Second, DaaS services are able to share this information with other entities. Besides, the emergence of analysis tools makes it easier to analyze and synthesize huge volumes of information, hence increasing the risk of privacy violation. In the following, we use our epidemiological scenario to illustrate the privacy challenges during service composition.

Challenge 1: Privacy Specification.

Challenge 2: Privacy within compositions.

Challenge 3: Dealing with incompatible privacy policies in compositions.

PROPOSED SYSTEM:

We describe a formal privacy model for Web Services that goes beyond traditional data-oriented models. It deals with privacy not only at the data level (i.e., inputs and outputs) but also service level (i.e., service invocation). In this paper, we build upon this model two other extensions to address privacy issues during DaaS composition. The privacy model described in this paper is based on the model initially proposed

ADVANTAGES OF PROPOSED SYSTEM:

v  Privacy-aware Service Composition: We propose a compatibility matching algorithm to check privacy compatibility between component services within a composition.

v  Negotiating Privacy in Service Composition: In the case when any composition plan will be incompatible in terms of privacy, we introduce a novel approach based on negotiation to reach compatibility of concerned services (i.e., services that participate in a composition which are incompatible).

 MODULES:

] e-Epidemiological Scenario

] Privacy Level

] Privacy Rule

] Privacy-aware Service Composition

] Negotiating Privacy in Service Composition

MODULE DESCRIPTION:

e-Epidemiological Scenario

The first module is E-epidemiology scenario module. We develop the scenario of E-epidemiology. E-epidemiology is the science underlying the acquisition, maintenance and application of epidemiological knowledge and information using digital media such as the internet, mobile phones, digital paper, digital TV. E-epidemiology also refers to the large-scale epidemiological studies that are increasingly conducted through distributed global collaborations enabled by the Internet.

The traditional approach in performing epidemiological trials by using paper questionnaires is both costly and time consuming. The questionnaires have to be transformed to analyzable data and a large number of personnel are needed throughout the procedure. Modern communication tools, such as the web, cell phones and other current and future communication devices, allow rapidly and cost-efficient assembly of data on determinants for lifestyle and health for broad segments of the population.

The mediator selects, combines and orchestrates the DaaS services (i.e., gets input from one service and uses it to call another one) to answer received queries. It also carries out all the interactions between the composed services (i.e., relays exchanged data among interconnected services in the composition). The result of the composition process is a composition plan which consists of DaaS that must be executed in a particular order depending on their access patterns (i.e., the ordering of their input and output parameters).

Privacy Level

In this module we define two privacy levels: data and operation. The data level deals with data privacy. Resources refer to input and output parameters of a service (e.g., defined in WSDL). The operation level copes with the privacy about operation’s invocation. Information about operation invocation may be perceived as private independently on whether their input/output parameters are confidential or not. For instance, let us consider a scientist that has found an invention about the causes of some infectious diseases, he invokes a service operation to search if such an invention is new before he files for a patent. When conducting the query, the scientist may want to keep the invocation of this operation private, perhaps to avoid part of his idea being stolen by a competing company. We give below the definition of the privacy level.

Privacy Rule

The sensitivity of a resource may be defined according to several dimensions called privacy rules. We call the set of privacy rules Rules Set(RS). We define a privacy rule by a topic, domain, level and scope. The topic gives the privacy facet represented by the rule and may include for instance: the resource recipient, the purpose and the resource retention time. The “purpose” topic states the intent for which a resource collected by a service will be used; the “recipient” topic specifies to whom the collected resource can be revealed. The level represents the privacy level on which the rule is applicable. The domain of a rule depends on its level. Indeed, each rule has one single level: “data” or “operation”. The domain is a finite set that enumerates the possible values that can be taken by resources according to the rule’s topic. For instance, a subset of domain for a rule dealing with the right topic is {“no-retention”, “limited-use”}. The scope of a rule defines the granularity of the resource that is subject to privacy constraints. Two rules at most are created for each topic: one for data and another for operations.

Privacy-aware Service Composition

We propose a compatibility matching algorithm to check privacy compatibility between component services within a composition. The compatibility matching is based on the notion of privacy subsumption and on a cost model. A matching threshold is set up by services to cater for partial and total privacy compatibility.

In this module we also propose an algorithm called PCM (Privacy Compatibility Matching). The first option is to require full matching and the second is partial matching.

Negotiating Privacy in Service Composition

In the case when any composition plan will be incompatible in terms of privacy, we introduce a novel approach based on negotiation to reach compatibility of concerned services (i.e., services that participate in a composition which are incompatible). We aim at avoiding the empty set response for user queries by allowing a service to adapt its privacy policy without any damaging impact on privacy. Negotiation strategies are specified via state diagrams and negotiation protocol is proposed to reach compatible policy for composition.

SYSTEM REQUIREMENTS:

HARDWARE REQUIREMENTS:

Ø System                          :         Pentium IV 2.4 GHz.

Ø Hard Disk                      :         40 GB.

Ø Floppy Drive                 :         1.44 Mb.

Ø Monitor                         :         15 VGA Colour.

Ø Mouse                            :         Logitech.

Ø Ram                               :         512 Mb.

SOFTWARE REQUIREMENTS:

Ø Operating system           :         Windows XP/7.

Ø Coding Language :         JAVA/J2EE

Ø IDE                      :         Netbeans 7.4

Ø Database              :         MYSQL

REFERENCE:

Salah-Eddine Tbahriti, Chirine Ghedira, Brahim Medjahed and Michael Mrissa “Privacy-Enhanced Web Service Composition”- IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 7, NO. 2, APRIL-JUNE 2014