Example Scenario of Semantic Firewall Usage
In order to better illustrate the range of issues that need to be resolved to achieve the aim stated above we begin with a basic interaction scenario between two service providers and a client. The scenario aims to highlight the difficulties arising once just two service providers need to interact to achieve a client's goal and the associated delegations that must take place. We illustrate these interactions in Figure 1, through the use of an interaction diagram. In this example, Client A needs to make use of Service Provider B, in order to perform an operation, but requires that the data for the operation is provided to B by Service Provider C. Each party is operating from a different policy domain and B and C have no prior knowledge of the existence of each other. The required interactions begin with A requesting from C that the data is transmitted to B. Then C must notify A that the data is at B (although B could also potentially notify A), so that A can request from B to run the operation on the data and provide the results.
Figure 1 - Basic Interaction Scenario
Now, as a means for stimulating debate about how we should resolve the various problems that are raised by a scenario as the one above (which is discussed in more detail in the 3-page abstract for the Web Services Symposium) we take a "walk-through" approach, highlighting and discussing some of the relevant issues and possibilities at each step. First we present some relevant policies, then look at how this policy information can be disseminated between the different domains, what reasoning needs to be done by the different domains, and what resulting "unified" policies may emerge.
Example Policy Sets (see used ontology (hyperOWL))
We begin by introducing some policies for the different domains.
Policy Set for Service Provider B
It seems that the default policy for the Service Provider B should be Positive Authorization (hyperOWL).
- Service Provider B cannot accept data from parties that have not been previously authorised by itself or a trusted party that has been delegated such authorisation rights (hyperOWL).
- Service Provider B cannot report back on results from operations from parties other than those which have provided the data, unless the data provider has authorised another party (hyperOWL).
- Service Provider B cannot perform operations on data unless payment for the service has already been received (hyperOWL).
- Service Provider B should deny requests for operations involving more that one interacting party if the entire service provision worth is less than 400 units (hyperOWL).
It seems that the default policy for the Client Ashould be Negative Authorization (hyperOWL).
- Client A can request operations for data from external service providers only if the cost of the operation does not exceed 300 units (hyperOWL).
- Client A can only communicate with service providers if they support authentication with X509 certificates (hyperOWL).
- Client A can only accept results from operations through a communication path using SSLv3 (hyperOWL).
Policy Set for Service Provider C
It seems that the default policy for the Service Provider C should be Negative Authorization (hyperOWL).
- Service Provider C can only send data to other parties that have been authorised and have paid for the service OR to parties that have been authorised by a party that fulfils the first part of the rule (hyperOWL).
- Service Provider C can only send data encrypted with FIPS-approved (Federal Information Processing Standard (FIPS) for the Advanced Encryption Standard) algorithms (hyperOWL).
These policies illustrate a number of relevant issues. The policies imposed by the domain of Service Provider B raise the issue of delegation of rights from A to C so that C can send the data to B (rule 1). At the same time C should be authorised by A to accept the results of the operation (rule 2). Rule 3 imposes a certain flow on the series of interactions where an action before the request for operation should be payment. Rule 4 states that Service Provider b should not bother with complex scenarios (such as ours) because the cost of setting up the scenario is not worth it unless service provision is more than 400 units worth.
With Client A we have policies that limit what Client A can do which are imposed by the domain within which A is operating (rule 1), restrict the kind of services it can access based on their security capabilities (policies 2 and 3).
With Service Provider C, some more necessary steps to any resulting interactions
are added by Rule 1, as well as restrictions on the kinds of services
that can cooperate with Service Provider C. However, the restriction in
this case is more general than in the case of Client A, illustrating the
significance of semantic reasoning.
OWL-S Semantic Firewall Grid Example
Originall written by Ronald Ashri, modified by Andrzej Uszok
Policies and ontologies defined by Andrzej Uszok.
