Declarative Policies for Describing Web Service Capabilities and Constraints

1. UMBC Position Paper Declarative Policies for Describing Web Service Capabilities and Constraints Lalana KagalTim FininAnupam Joshi University of Maryland Baltimore County

2. Overview • Current Problem : Describing constraints and capabilities of web services • Our Solution : Describing behavior specification of entities using declarative policies • These specifications include the description of constraints and capabilities of web services

3. Behavior Specifications • We propose the use of declarative policies to describe behavior of entities including agents, web services, and users • Based on deontic concepts • Permission, obligation, power, privilege, claim, etc. • Example • ‘You MUST use HTTP Authentication when accessing this service’ describes how an entity that wants to use the service should behave • Can be modeled as an security policy (or constraint) of a service • An entity is 'permitted' to access the service if it meets the policy i.e. uses HTTP authentication • Example • You SHOULD not use my contact details for marketing of services or products • This is a privacy policy on the website being accessed

4. Behavior Specifications • Constraint of a web service • Permissions, obligations, prohibitions on the accessing entity • Capability of a web service • Claims, privileges, permissions, power of the web service

5. Possible Enforcement • Add enforcement mechanism to a broker or MatchMaker • Centralized • Every entity (agent, user, and web service) is responsible for their own behavior • Peer-to-peer approach • Each entity is capable of reasoning over its own policies and goals, and the policies of the entities it needs to interact with, in order to infer how it should behave • Obligation management • Policy framework by forcing the entity to behave a certain way • Reputation servers, penalties etc.

6. What are Policies ? • We define policies as norms of behavior • Describe ideal behavior (security, privacy, management, etc.) • Positive and negative authorizations & obligations • Policies are defined over ‘classes’ of entities and actions defined by constraints on attributes of the action, actor, target, and the general context – not just on identities • Policy Management • Can be enforced by the policy management system • Can be reasoned over by entities to decide what to do next • Policies allow the behavior of entities to be dynamically modified • Policies provide high-level control of entities in the environment

7. Our Current Work • Rei : A policy specification language • Declarative policy specification language that • Is defined in OWL that uses a rule-based approach • Includes provisional permissions and models consequences of deviating from a policy • Includes an implementation of a policy engine and analysis tools • Includes meta policy specifications for conflict resolution • Includes an integrated approach to using speech acts for dynamic policy modification • Has been used to model different kinds of policies • Security • Privacy • Team formation, collaboration and maintenance • Conversation

8. Rei Policy Spec Language • A declarative policy specification language • Rules over permitted and obligated domain actions • Represented in OWL-Lite + logical variables • Rule-based approach • Increased expressivity as it can express relations like role-value maps that are not currently possible in RDF or OWL • OWL extension is subset of SWRL • Reasons over domain dependent information in RDF and OWL • F-OWL reasoner

9. Rei Policy Spec Language • Policy Engine • Answers queries about policies and domain knowledge • Example : Can X perform action Y on resource Z ? What are the current obligations of X ? What actions can X perform on resource/service Z ? …. • Analysis tools • Verifying whether the given set of test cases is satisfied • Performing what-if analysis for testing the impact of changes to policies or domain knowledge • Interface • Java API • Simple GUI in Protégé • GUI in Eclipse (under construction)

10. Some Rei Examples • Management policies • X is permitted to send dispensations for obligations created by Y under certain situations, as long as X is higher in the organizational hierarchy than Y • Security policies for pervasive computing environments • You cannot use the camera functionality of your handheld device in this domain • You are permitted to access all services on resources located in any lab that your advisor is affiliated to • You are permitted to use the laser printer as long as you refill the paper tray • Privacy policies in the semantic web services framework • I do not want to access any service that requires my SSN number in an unencrypted format

11. Some Rei Examples • Conversation policies • You are obliged to reply to all queries from anyone in your group • Scully is obliged to refuse queries from congressional democrats regarding the estimated cost of the Medicare Bill otherwise he will lose his job • Policies for information flow in multi-agent systems • Only CIA members of rank R or higher can be team leaders for crisis of type C • No members from CIA and FBI can exchange information about topic X unless they are on a top priority team

12. Building Rei Policies rdf:type P X Y Z Univ:advisedBy Univ:affiliatedTo Univ:locatedIn X IS PERMITTED TO PERFORM ANY ACTION WHOSE TARGET IS P IF

13. Rei Specifications • Core specs • Policy • Granting • Action • Deontic Object • Speech Act • Meta Policy • Constraint • Authoring specs • Analysis

14. Deontic Objects • Permission : Not obliged not to (~O~ ) • provision property • Prohibition : Obliged Not To (O~) • sanction propery • Obligation : Obliged To (O) • sanction propery • Dispensation : Not Obliged To (~O) • Common Properties : Actor, Action, Constraint {StartingConstraint, EndingConstraint} • StartingConstraint subproperty of Constraint

15. Example Permission • Example : Students are permitted to print on certain set of printers as long they replace the paper • <deontic:Permission rdf:ID="Perm_StudentPrinting"> • <deontic:actor rdf:resource="#PersonVar"/> • <deontic:action rdf:resource="#ObjVar"/> • <deontic:constraint rdf:resource="#IsStudentAndBWPrinter"/> • <deontic:provision rdf:resource="#Obl_ReplacePaper"/> • </deontic:Permission> <constraint:SimpleConstraint rdf:ID=”IsStudent"> <constraint:subject rdf:resource="#PersonVar"/> <constraint:predicate rdf:resource=”&rdf;type"/> <constraint:object rdf:resource="&umbc;Student"/> </constraint:SimpleConstraint>

16. Speech Acts • Speech Acts • Used to dynamically modify existing policies • Delegation, Revocation, Request, Cancel • Properties : Sender, Receiver, Content (Deontic object/Action), Conditions • Speech acts are valid only if the senders have the appropriate permissions • For example, Marty has the permission to delegate the permission to enter the site of emergency supplies to all members of agency A • It is also possible to modify permissions to perform speech acts • For example, John revokes Marty’s permission to delegate the permission to enter the site of emergency supplies to all members of agency A

17. Example Delegation • Example : Delegation from ’Marty' to all students of the 'CSDept' giving them the permission to perform actions of type ’LaserPrinting’ • <action:Delegation rdf:ID=”MartyToCSStudents"> • <action:sender rdf:resource="Marty"/> • <action:receiver rdf:resource="#PersonVar"/> • <action:content> • <deontic:Permission> • <deontic:actor rdf:resource="#PersonVar"/> • <deontic:action rdf:resource="#ObjectVar"/> • </deontic:Permission> • </action:content> • <action:condition> • <constraint:And> • <constraint:first rdf:resource="#IsStudentOfCS"/> • <constraint:second rdf:resource="#IsLaserPrinting"/> • </constraint:And> • </action:condition> • </action:Delegation>

18. Permission To Delegate • Example : Marty has the permission to perform a delegation speech act to graduate students wrt the LaserPrinting actions • <deontic:Permission rdf:ID="Perm_MartyDelegateFacultyCSPrinting"> • <deontic:actor rdf:resource="Marty"/> • <deontic:action> • <action:Delegation rdf:ID="Perm_Del"> • <action:sender rdf:resource=”#Marty"/> • <action:receiver rdf:resource="#PersonVar"/> • <action:content> • <deontic:Permission> • <deontic:actor rdf:resource="#PersonVar"/> • <deontic:action rdf:resource="#ObjVar"/> • <deontic:constraint rdf:resource="#IsLaserPrinting"/> • </deontic:Permission> • </action:content> • </action:Delegation> • </deontic:action> • <deontic:constraint rdf:resource="#IsGraduateStudent"/> • </deontic:Permission>

19. Analysis • Analysis specifications to describe use-case and whatif analysis • Analysis tools that can be run by policy engineers via the Java API • Use Cases (known as test cases in Software Engineering) • Define a set of use cases that must always be satisfied in order for the policies to be correct • E.g. The dean of the school must always have access to all the grad labs • WhatIf (known as regression testing in Software Engineering) • To check the effects of changes to the policy or ontology before actually committing them • E.g If I remove Perm_StudentPrinting from the GradStudentPolicy, will Bob still be able to print ?

20. Implementation Details POLICY ENGINEER/APPL • XSB • Flora : F-logic over XSB • F-OWL : is a reasoner for RDF, OWL • Java wrapper • Rei engine • Can be used by the policy enforcement component within a policy-based framework to decide permissions and obligations of entities • Can also be used for analysis by policy administrators JAVA API REI INTERFACE YAJXB REI FLORA FOWL XSB Image adapted from Mohinder Chopra

21. Applications – past, present & future • Coordinating access in supply chain management system (EECOMS - IBM lead) • Authorization policies in a pervasive computing environment (UMBC) • Policies for team formation, collaboration, information flow in multi-agent systems (Genoa II (Topsail) - Global Infotek, UMBC) • Policies for semantic web services (UMBC, SRI, CMU) • Privacy and trust on the Internet (UMBC) • Enforcing domain policies on handhelds in pervasive computing environments (UMBC, NIST) • Privacy in a pervasive computing environment (UMBC) • Task Computing (Fujitsu Labs, UMBC) • Dynamic Policy Management (Arizona State Univ) 1999 2002 2003 2004…

22. Related Work SPKIRBAC PDLASL Non SW PolicyMaker KeyNote Delegation LogicPonder Declarative Procedural XACMLEPALSAML WS* XML SW KAoSRei

23. Case Study • A Web service, WS, wishes to stipulate that clients are required support a reliable messaging protocol and encrypt a specific header with WS-Security using a X.509 or user name security token in order to send an acceptable request message • WS defines this requirement as an Rei access control policy over a set of conditions. • Only when the conditions are satisfied, will the requesting client be 'permitted' to access the service. • Information about what it means to be a 'reliable messaging protocol' or 'encrypt specific header with WS-Security' will be expressed as domain ontologies described in RDF or OWL

24. Case Study • The service has a P3P policy associated with its operations • This policy can either be expressed in P3P or can be described as a privacy policy using the P3P RDF ontology. • Let us assume a client, C, has a policy as well, a Rei privacy policy specified over P3P RDF specifications and user context • E.g. You SHOULD not use my contact details for marketing of services or products

25. Case Study : How it Works P3P policy + (access control policy) + privileges + permissions Client BravoAirWeb service Access request +privacy policy + privileges + permissions Broker + Rei engine

26. Case Study : How it Works • Client, C, locates Web service, WS, and contacts it • C sends WS its privacy policy and a description of its privileges and permissions • WS verifies that the C has the permission or privilege to support a reliable messaging protocol and encrypt a specific header with WS-Security using a X.509 or user name security token by checking C's privileges and permissions • WS sends C its access control policy and P3P policy • C verifies that WS meets its privacy requirements by checking the P3P policy against its own privacy requirements • The Rei policy engine currently supports most of the policy compliance testing used in this usecase • A problem with this approach is that each party has to disclose its policy. Another approach is to use a trusted third part for checking policy compliance or use a negotiation protocol, where every entity reveals a little more during every message exchange

27. Open Issues • Can we find the right balance between having a policy language or framework that is • powerful and expressive enough to handle a wide range of uses, (ii) efficient enough for real applications • reasonably easy for real developers to learn and use. • Should the paradigm be dominated by • rule based approach (e.g., using RuleML or SWRL) • an ontology approach (e.g., using OWL) • a hybrid of the two • something else altogether. • What are appropriate mechanisms for enforcement? How can we make them easy for developers to integrate into their systems?

28. Open Issues • How do trust and reputation relate to policies ? • Policy specification • What methodologies, metrics and tools can be developed to support "policy engineering” • Should justification be provided for policy decisions? If yes, how and in what format ? If the policies are private, what kind of justification is possible ?

29. Summary • Declarative policies based on deontic concepts are useful for describing behavior • Describing capabilities and constraints of web services is a subclass of describing behavior • Semantic web languages used, grounding descriptions in sharable, semantically rich, machine understandable ontologies • We have evaluated the utility of Rei policies through prototype applications within and outside UMBC • Semantic web services • Multi-agent systems • Pervasive Computing • Supply Chain Management Systems

30. For more information http://rei.umbc.edu