Exchanging Policies Between Web Service Entities Using Rule Languages
Total Page:16
File Type:pdf, Size:1020Kb
Exchanging Policies between Web Service Entities using Rule Languages Nima Kaviani1, Dragan Gašević2, Marek Hatala1, Gerd Wagner2, Ty Mey Eap1 1Simon Fraser University Surrey, Canada 2Athabasca University, Canada 2Brandenburg University of Technology at Cottbus, Germany {nkaviani, mhatala, teap}@sfu.ca, [email protected], [email protected] Abstract demonstrate the importance of using a rule language in addition to ontologies. This allows run-time discovery, Web rule languages with the ability to cover various composition, and orchestration of Semantic Web ser- types of rules have been recently emerged to make in- vices by defining preconditions or post-conditions for teractions between web resources and broker agents all Web service messages exchanged. For instance, possible. The chance of describing resources and users OWL-S recommends using OWL ontologies along with of a domain through the use of vocabularies is another different types of rule languages (SWRL, KIF, or feature of Web rule languages. Combination of these DRS), while SAWSDL is fully agnostic about the use two properties makes Web rule languages an appro- of a vocabulary (e.g., UML, ODM, OWL) or rule lan- priate medium to make a hybrid model of representing guage (e.g., OCL, SWRL, RuleML). It is worth noting both contexts and rules of a policy-aware system, such that there is no agreement upon which rule language to as a web service. In this paper, we describe how use for Semantic Web services or what type of reason- REWERSE Rule Markup Language (R2ML) can be ing (open or closed world assumption) to support. employed to bridge between different policy languages Besides satisfying clients’ goals when using Seman- using its rich set of rules, vocabulary, and built-in con- tic Web services, trust is another important aspect that structs. We show how the concepts of the KAoS and should be established between a client and a service. Rei policy languages can be transformed to R2ML and Addressing this problem, researchers proposed the use then from R2ML to the other policy languages. Follow- of policy languages. A policy is a rule that specifies ing these mappings, we have implemented transform- under which conditions a resource (or another policy) ers, which enable us not only to share policies between might be disclosed to a requester [13]. To define po- KAoS and Rei, but also to transform policies onto lices on the Semantic Web, various policy languages other rule languages (e.g., F-Logic) for which trans- have been proposed including KAoS [21], Rei [8], and formations from/to R2ML are already developed. PROTUNE [2]. As [13] reports, trust management poli- 1. Introduction cies are also defined as parts (most commonly precon- ditions) of Semantic Web service descriptions. Semantic Web services (SWS), as the augmentation It is obvious that besides various Semantic Web of Web service descriptions through Semantic Web service description languages, we have various policy annotations, facilitate the higher automation of service languages and rule languages. All these languages are discovery, composition, invocation, and monitoring on based on different syntactic representations and formal- the Web. Semantic Web ontologies and ontology lan- isms with no explicitly defined mapping between them. guages (OWL and RDF(S)) are recognized as the main This hampers the use of Semantic Web services from means of knowledge representation for Semantic Web two different perspectives. One is automatic negotia- services [18]. Such ontology-enriched web service de- tion between service client agents and service providers scriptions are later used during negotiation process and automatic matchmaking, where agents and match- between service clients and service providers, which is makers should be able to “understand” various defined by a set of abstract protocols of Semantic Web rule/policy/service web service description languages. Service Architecture (SWSA) [3]. Another perspective is that of a knowledge manage- However, the current proposed standards for de- ment worker who prefers to express the rules and poli- scribing Semantic Web services (i.e. OWL-S, WSDL- cies in a single form rather than in a broad variety of S, and Semantic Web Service Language – SWSL) forms. To attempt to represent the same rules and poli- cies in many forms is cumbersome, time consuming cies. In this scenario, we assume that the service pro- and error prone but it is the only choice available if a vider has its policies defined in Rei and the broker broad base of interoperability is required. agent has the policies defined in KAoS (cf. Section 3). In our approach, we propose the use of REWERSE Suppose that the broker agent has a policy which says: Rule Markup Language (R2ML) [23], which addresses “Client A can only communicate with service providers almost all use-cases and needs for a Rule Interchange that support authentication with X509 certificates and Format (RIF) [4], along with a set of transformations have already been approved as trusted entities for Cli- between Semantic Web service description (e.g., ent A to communicate with.” Figure 1 represents the WSDL-S), rules, and policy languages. We illustrate policy in KAoS defined by the broker agent. Now sup- the benefits of our approach using a Semantic Web pose that during the process of trust negotiation the Service Architecture example where R2ML is used to client needs to ask the service provider whether it could share policies in the process of matchmaking, trust ne- provide any support for the X509 certificate authentica- gotiation, and failure explanation. In the next section, tion. If there is no constraint on releasing the policy, we motivate our research by describing a trust negotia- this can possibly happen by sending the policy of Fig- tion scenario for using Web services. ure 1 to the service provider. In case that there is no understanding about Rei by the client or no knowledge 2. Motivations about KAoS by the service provider, the communica- Web services in general and Semantic Web services tion would fail. So, either the broker agent or the ser- in particular, are of the most important domains for vice provider must be able to exchange the policy to an applying Web policy rules. Policies can be regarded as equivalent Rei policy. The result of transformation can constraints to be combined with Web services to iden- be similar to the policy defined in Figure 2. <entity:Variable rdf:ID="ActorVar"/> tify explicitly conditions under which the use of a ser- <policy:Policy rdf:ID="policy_N100CE"> <deontic:actor rdf:resource="#ActorVar" /> vice is permitted or prohibited [7]. However, due to the <policy:grants rdf:resource="#Policy_CommunicationCertificate" /> <policy:context rdf:resource="#CommunicationActionConstraint" /> diversity of existing policy languages, chances are that </policy:Policy> <deontic:Permission rdf:ID="Policy_CommunicationCertificate"> the policies used to protect the services or resources are <deontic:action rdf:resource="&KAoSAction;CommunicationAction"/> <deontic:actor rdf:resource="#ActorVar"/> not defined in the same language, which makes the <deontic:constriant rdf:resource="#ActionApprovalConstraint"/> </deontic:Permission> process of communication impossible. <constraint:And rdf:ID="ActionApptovalConstraint"> As an example, let us consider a scenario in which a <!--Conjunction of Constraints for the preconditionst plus the CommunicationActor constraint--> </constraint:And> Web service provider and a broker agent, with two <!-- Constraints for the TrustedEntity and CarryMessage different policy languages, need to negotiate their poli- to control the behavior of the system --> <owl:Class rdf:ID="Policy_CommunicationCertificate_Action"> <constraint:SimpleConstriant rdf:ID="CommunicationActor"> <owl:intersectionOf> <constriant:subject rdf:resource="#ActorVar"/> <owl:Class rdf:about="&KAoSAction;CommunicationAction"/> <constriant:object rdf:resource="&rdfs;type"/> <owl:Class> <constraint:predicate rdf:resource="&KAoSActor;ClientA"/> <owl:Restriction> </constraint:SimpleConstriant> <owl:onProperty rdf:resource="&KAoSAction;performedBy"/> <owl:someValuesFrom> <constraint:SimpleConstriant rdf:ID=" CommunicationActionConstraint"> <owl:Class> <constriant:subject rdf:resource="#ActionVar"/> <owl:oneOf rdf:parseType="Collection"> <constriant:object rdf:resource="&KAoSActor; <owl:Thing rdf:about="&InstanceElem;ClientA"/> ServiceProviderSupportingX509Certificates"/> </owl:oneOf> <constraint:predicate rdf:resource="&KAoSPolicy;hasPartner"/> </owl:Class> </constraint:SimpleConstriant> </owl:someValuesFrom> </owl:Restriction> Figure 2. An equivalent Rei policy of Figure 1 </owl:Class> <owl:Restriction> <owl:onProperty rdf:resource="&KAoSPolicy;hasPartner"/> In a general case either the Web agent or the service <owl:allValuesFrom rdf:resource="&KAoSActor; #ServiceProviderSupportingX509Certificates"/> provider must be able to negotiate to the other re- </owl:Restriction> </owl:intersectionOf> sources and agents with different languages for sharing </owl:Class> <!--Checks on whether the entity that is receiving the request by Client their resources and policies as well. However, consid- A is a trusted entity--> <owl:Class rdf:about=" Policy_TrustedEntity "> ering the number of available policy languages and <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="&KAoSAction;ApproveAction"/> services, it would be a lot of effort to develop one-to- <owl:Restriction rdf:about="#checkOnCarryingMessages"> <!—Similar