1 / 58

A Policy Specification Language for Governing Open, Dynamic Distributed Environments

A Policy Specification Language for Governing Open, Dynamic Distributed Environments. Lalana Kagal, University of Maryland Baltimore County. Outline. Environments under consideration Key Idea Rei : a policy specification language Examples Collaborative MAS Pervasive Computing

plato-russo
Download Presentation

A Policy Specification Language for Governing Open, Dynamic Distributed Environments

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Policy Specification Language for Governing Open, Dynamic Distributed Environments Lalana Kagal, University of Maryland Baltimore County

  2. Outline • Environments under consideration • Key Idea • Rei : a policy specification language • Examples • Collaborative MAS • Pervasive Computing • Internet Privacy • Semantic web services • Related Work • Contributions • Summary

  3. Characteristics Resources and clients are not pre-determined Constantly evolving Usually very large number of resources, services and clients Presence of semi-autonomous entities Span several domains Entities belong to several domains Restriction on mechanism Mechanism cannot list access rights of individuals Run-time modification should be possible It should be possible to control sets of clients and services grouped by certain common characteristics Mechanism should be automated Mechanism should be easily extensible to be usable for any domain-specific information Mechanism should include some way to handle conflicts in behavior specifications Characteristics of the Domain

  4. Restriction on mechanism Mechanism cannot list access rights of individuals Run-time modification should be possible It should be possible to control sets of clients and services grouped by certain common characteristics Mechanism should be automated Mechanism should be easily extensible to be usable for any domain-specific information Mechanism should include some way to handle conflicts in behavior specifications Key Idea Solution • Declarative policies that are described in terms of attributes of entities • Speech act support for dynamic modification • Policies can be described over sets of entities • Policies represented in a machine-understandable language • Policy specification language grounded in an ontology language • Meta policies to handle conflicts in policies

  5. What are Policies ? • Policies are rules of behavior • Describe optimal 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 (and its actor and target) and the general context – not just on their identity of the actor and action • 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

  6. An early policy for agents 1 A robot may not injure a human being, or,through inaction, allow a human being tocome to harm. 2 A robot must obey the orders given it by human beings except where such orders would conflict with the First Law. 3 A robot must protect its own existence as long as such protection does not conflict with the First or Second Law. -- Handbook of Robotics, 56th Edition, 2058 A.D.

  7. On policies, rules and laws • The interesting thing about Asimov’s laws were that robots did not always strictly follow them • This is a point of departure from more traditional “hard coded” rules like DB access control, and OS file permissions • Policies increase autonomy • They describe “norms of behavior” that entities should follow to be “good citizens” • So, it’s natural to worry about issues like • When an entity is governed by multiple policies, how does it resolve conflicts among them? • How can we define penalties when entities don’t fulfill their obligations? • How can we relate notions of trust and reputation to policies?

  8. Rei Policy Spec Language • Developed several versions of Rei, a policy specification language, encoded in (1) Prolog, (2) OWL • Models deontic concepts of permissions, prohibitions, obligations and dispensations • Uses meta policies for conflict resolution • Uses speech acts for dynamic policy modification • Used to model different kinds of policies • Security • Privacy • Team formation, collaboration and maintenance • Conversation

  9. Some Rei Examples • Management policies • You are permitted to send dispensations for obligations created by Y under certain situations, as long as you are 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 • 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 • Conversation policies • You are obliged to reply to all queries from anyone in your group • Policies for information flow in multi-agent systems • No members from CIA and FBI can exchange information about topic X unless they are on a top priority team

  10. Rei Policy Spec Language • A declarative policy specification language • Rules over permitted and obligated domain actions • Currently represented in OWL-Lite + logical variables • 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 • Can include any other ontology language as long as the appropriate reasoner is hooked into the policy engine • Policy tools • 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 ? ….

  11. Rei Policy Spec Language • Policy Tools (cont.) • Analysis tools • Verifying whether the given set of test cases is satisfied • Returning list of satisfied/unsatisfied test cases • 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)

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

  13. Constraint • Simple Constraints • Triple(Subject, Predicate, Object) • Example : Group of entities that are affiliated to the LAIT lab <entity:Variable rdf:ID=”Var1”/> <constraint:SimpleConstraint rdf:ID=”IsMemberOfLait"> <constraint:subject rdf:resource="#Var1"/> <constraint:predicate rdf:resource="&univ;affiliation"/> <constraint:object rdf:resource="&univ;LAITLab"/> </constraint:SimpleConstraint> • Boolean Constraints : And, Or, and Not

  14. Policy • Properties : Context, Grants, Default Policy, Priorities • A Policy is applicable if the Context is true • Example <policy:Policy rdf:ID=”CSDeptPolicy"> <policy:context rdf:resource="#IsMemberOfCS"/> <policy:grants rdf:resource="#Perm_StudentPrinting"/> <policy:defaultBehavior rdf:resource="&metapolicy;ExplicitPermExplicitProh"/> <policy:defaultModality rdf:resource="&metapolicy;PositiveModalityPrecedence"/> <policy:metaDefault rdf:resource="&metapolicy;CheckModalityPrecFirst"/> </policy:Policy>

  15. Granting • Links deontic rules to policies with additional constraints • Allows for reuse of deontic objects with different constraints • Encourages modularity • Deontic objects and constraints can be defined by technical staff • Policy administrator can drag and drop appropriate deontic objects and add constraints

  16. Granting • Example : Same permission used in Policy example with extra constraints <policy:Granting rdf:ID="Granting_PhStudentLaserPrinting"> <policy:to rdf:resource="#PersonVar"/> <policy:deontic rdf:resource="#Perm_StudentPrinting"/> <policy:requirement rdf:resource="#IsLaserPrinterAndPhStudent"/> </policy:Granting> <policy:Policy rdf:ID=”BioDeptPolicy"> <policy:grants rdf:resource="# Granting_PhStudentLaserPrinting"/> </policy:Policy>

  17. Deontic Object • Deontic objects • Permissions, Prohibitions, Obligations, Dispensations (waiver for obligations) • Common Properties : Actor, Action, Constraint {StartingConstraint, EndingConstraint} • StartingConstraint subproperty of Constraint

  18. Permission • ~O~ : Permission(X, Y, Constraint/ StartingConstraint, {EndingConst}, {Provision}) • X is said to have the permission to perform action Y if the Constraint or StartingConstraint is true and until EndingConstraint is true. • Additional property : Provision • These are obligations that are come into effect when the permission is used • After the permission is used, Provision comes into effect

  19. 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>

  20. Prohibition • O~ : Prohibition(X, Y, Constraint/StartingConstraint, {EndingConst}, {Sanction}) • X is said to be have a prohibition from performing action Y if the Constraint (or StartingConstraint is true) and until EndingConstraint is true. • Additional property : Sanction • In case prohibitions are violated, additional obligations or prohibitions are usually applicable • Or a certain action that is taken against the actor • If the prohibition is violated, the Sanction comes into effect • If the Sanction is an obligation or prohibition, it is imposed on X

  21. Obligation • O : Obligation(X, Y, Constraints/StartingConstraint, {EndingConst}, {Sanction}) • X is said to be have a obligation to perform action Y if the Constraint (or StartingConstraint is true) and until EndingConstraint is true. • If the obligation is not fulfilled before EndingConstraint is true, it is said to have been violated. • Additional property : Sanction • In case obligations are violated, additional obligations or prohibitions are usually applicable • Or a certain action could be performed on the actor • If the obligation is violated, the Sanction comes into effect • If the Sanction is an obligation or prohibition, it is put into effect

  22. Example Obligation • If you borrow a book from the library, you’re obliged to return it before the due date, otherwise you must pay a fine <deontic:Obligation rdf:ID=”Obl_ReturnBook"> <deontic:actor rdf:resource="#PersonVar"/> <deontic:action rdf:resource=”&inst;ReturnBook"/> <deontic:StartingConstraint rdf:resource="#IsMemberAndBorrowedBook"/> <deontic:EndingConstraint rdf:resource="#BeforeDueDate"/> <deontic:sanction rdf:resource=”&inst;PayFine"/> </deontic:Obligation>

  23. Dispensation • ~O : Dispensation(X, Y, Constraints/StartingConstraint, {EndingConst}) • X is said to be have a dispensation from performing action Y if the Constraint (or StartingConstraint is true) and until EndingConstraint is true. • After Constraint/StartingConstraint is true and until EndingConstraint is true, X is no obliged to perform Y

  24. Action • Two kinds of actions : Domain Actions and Speech Acts • Domain Actions • Properties : Actor, Target, Effects, PreConditions • Action(Actor, Target, PreConditions, Effects) • Action can be performed on Target only when the PreConditions are true and oncce performed the Effects are true. • Example : Based on Rei <action:Action rdf:ID=”EbiquityDeviceUsage"> <action:actor rdf:resource="#PersonVar"/> <action:target rdf:resource="#ObjVar"/> <action:location rdf:resource="&inst;EbiquityLab"/> <action:precondition rdf:resource="#DeviceBelongsToEbiqLab"/> <action:Action>

  25. Action • Example : <owl:Class rdf:ID="CSPrinting"> <rdfs:subClassOf rdf:resource=”&univ;Printing"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="&action;location"/> <owl:allValuesFrom rdf:resource=”&inst;CSDept" /> </owl:Restriction> </rdfs:subClassOf> </owl:Class>

  26. Speech Acts • Speech Acts • Delegation, Revocation, Request, Cancel • Properties : Sender, Receiver, Content (Deontic object/Action), Conditions • Used to dynamically modify existing policies • Speech acts are valid only if the entities that make them have the appropriate permissions

  27. Delegation • Delegation(Sender, Receiver, Permission(Receiver, Action, Constraints, {EndingConst}, {Provision}), Conditions) • The Sender grants to the Receiver the Permission as long the Conditions are true. • If valid, leads to a permission.

  28. 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="&inst;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>

  29. 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="&inst;Marty"/> <deontic:action> <action:Delegation rdf:ID="Perm_Del"> <action:sender rdf:resource="&inst;Marty"/> <action:receiver rdf:resource="#var1"/> <action:content> <deontic:Permission> <deontic:actor rdf:resource="#var1"/> <deontic:action rdf:resource="#var2"/> <deontic:constraint rdf:resource="#IsLaserPrinting"/> </deontic:Permission> </action:content> </action:Delegation> </deontic:action> <deontic:constraint rdf:resource="#IsGraduateStudent"/> </deontic:Permission>

  30. Request • Request(Sender, Receiver, Permission(Receiver, Action), Constraints) • The Sender asks the Receiver for the Permission • If accepted, leads to a delegation • Request(Sender, Receiver, Action, Constraints) • The Sender asks the Receiver to perform the Action. • If valid, leads to an obligation

  31. Revocation • Revocation(Sender, Receiver, Permission(Receiver, Action, Constraints, {EndingConst}, {Provision}), Conditions) • The Sender revokes from the Receiver the Permission as long the Conditions are true. • If valid, leads to a prohibition. • Example : ’Marty' revokes the permission to use a specific action ’HP123Printing from 'George' <action:Revocation rdf:ID=”MartyFromGeorge"> <action:sender rdf:resource="&inst;Marty"/> <action:receiver rdf:resource="&inst;George"/> <action:content> <deontic:Permission> <deontic:action rdf:resource ="&inst;HP123Printing"/> </deontic:Permission> </action:content> </action:Revocation>

  32. Cancel • Cancel(Sender, Receiver, Permission(Receiver, Action), Constraints) • The Sender does not need the earlier requested Permission from the Receiver. • Leads to a revocation. • Cancel(Sender, Receiver, Action, Constraints) • The Sender no longer wants the Receiver to perform the Action. • Leads to a dispensation

  33. Meta Policy • Meta policies • Behavior • ExplicitPermImplicitProh • ImplicitPermExplicitProh • ExplicitPermExplicitProh • Priority • Priority between rules in the same policy • Priority between policies • E.g. Federal policy overrides State policy • Modality precedence • E.g. Positive modality holds precedence over negative for CSDept policy • Meta policy Default • CheckModalityPrecFirst • CheckPriorityFirst

  34. Priority • Example : To specify that the Federal policy has higher priority that the State policy <metapolicy:PolicyPriority rdf:ID="PriorityFederalState"> <metapolicy:policyOfGreaterPriority rdf:resource="&gov;Federal"/> <metapolicy:policyOfLesserPriority rdf:resource="&gov;State"/> <metapolicy:PolicyPriority> • Priorities for policies and rules must be acyclic (it is possible to check this but currently not implemented) • Rei does not allow • University policy overrides department policy • Department policy overrides lab policy • Lab policy overrides university policy

  35. Modality Precedence • Example : To state that negative modality holds for the CSDept and in case of conflict modality precedence should be checked before priorities <policy:Policy rdf:ID=”CSDeptPolicy"> <policy:context rdf:resource="#IsMemberOfCS"/> <policy:defaultModality rdf:resource="&metapolicy;NegativeModalityPrecedence"/> <policy:metaDefault rdf:resource="&metapolicy;CheckModalityPrecFirst"/> </policy:Policy>

  36. Analysis • 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 • 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 ?

  37. UseCase Analysis • Use cases : Statement and Deontic UseCases • Statement UseCase checks the value of a property • True or false statements can be checked • Example : BobJones is affiliated with the CS department <analysis:TrueStatementUseCase rdf:ID="BobJonesIsInCS"> <analysis:subject rdf:resource="&inst;BobJones"/> <analysis:predicate rdf:resource="&univ;affiliation"/> <analysis:object rdf:resource="&inst;CSDept"/> </analysis:TrueStatementUseCase>

  38. UseCase Analysis • Deontic UseCase checks whether the specified actor has the specified deontic on the target and the action • Example : Marty should not be able to perform any action on the HP-Printer <analysis:ProhibitionUseCase rdf:ID="MartyCannotUseHP-Printer"> <analysis:actor rdf:resource="&inst;Marty"/> <analysis:target rdf:resource="&inst;HP-Printer"/> </analysis:ProhibitionUseCase>

  39. What-If Analysis • What-if analysis : Property and PolicyRule analysis • Subclasses : WhatIfIAddProperty and WhatIfIRemoveProperty • Allows the property value associated with an instance to be temporarily added or removed • Example : To test the effects of removing the 'CSDept' value of the 'affiliation' property from 'Marty' <analysis:WhatIfIRemoveProperty rdf:ID=”RemoveMartyCS"> <analysis:instance rdf:resource="&inst;Marty"/> <analysis:property rdf:resource="&univ;affiliation"/> <analysis:value rdf:resource=”&univ;CSDept"/> </analysis:WhatIfIRemoveProperty> • To remove all values of a property, no value is specified

  40. What-If Analysis • Rule analysis • Is used for checking the effect of changing a policy • WhatIfIAddRule and WhatIfIRemoveRule • Example : In order to test the effects of adding a policy rule, 'Perm_Joe', to a policy, 'CSPolicy' <analysis:WhatIfIAddPolicyRule rdf:ID="AddPermToCSPolicy"> <analysis:policy rdf:resource="&inst;CSPolicy"/> <analysis:granting rdf:resource="Perm_Joe"/> </analysis:WhatIfIAddPolicyRule> <deontic:Permission rdf:ID="Perm_Joe"> <deontic:actor rdf:resource="&inst;Joe"/> <deontic:action rdf:resource="&inst; SomeAction"/> </deontic:Permission>

  41. Implementation Details USER • XSB • Flora : F-logic over XSB • F-OWL : is a reasoner for RDF, OWL • Java wrapper JAVA API REI INTERFACE YAJXB REI FLORA FOWL XSB Image adapted from Mohinder Chopra

  42. 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) - GITI lead) • Security in 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) 1999 2002 2003 2004…

  43. COLLABORATIVE MULTI-AGENT SYSTEMS • Agents facilitate collaboration within inter-agency human teams that are formed to handle a crisis • Agencies and teams have policies that guide behavior of their agents • Policies are used for • Team formation (selecting a leader, choosing team members) • Collaboration • Information flow • Workflow component of an agent takes into account relevant policies and its goals to decide what to do next • Lead: Global Infotek Inc. for DoD

  44. PERVASIVE COMPUTING Should I allow this access ? Should I trust this service ?

  45. Applications • Access control for Smart Spaces • Physical world is divided into Smart Spaces • Each smartspace has a controller that enforces the access control policy of the smartspace • SmartSpaces in an organization are connected and it is possible to traverse the hierarchy and access services in another SmartSpace • Enforcement of domain policies • Domain policies are enforced on mobile devices • Restricts functionality of mobile devices within domains • E.g. You cannot use the IR or BT functionality while you are in an untrusted domain • Enforcement • Rei policies stored within policy servers • Rei policies instantiated to give ACL • ACL enforced on mobile device

  46. SEMANTIC WEB SERVICES • Is mainly at the specification level • Extension of OWL-S profile with an attribute for describing policies • policyEnforced • subPropertyOf securityRequirement which is a subproperty of profile:parameter • Range: Policy in Rei ontology • Ontology for describing cryptographic characteristics of service parameters • Encrypted/Signed object

  47. Our Approach • Authorization, Privacy and Confidentiality Policy are subclasses of Policy in Rei • Authorization policies are usually associated with services • Can be enforced during discovery • Privacy policies are usually associated with clients • Only matching done during discovery • Algorithm for matching policies • Integration of the algorithm into CMU’s Matchmaker and OWL-S Virtual Machine (future work) • Earlier version was integrated into the Matchmaker

  48. Example policies • Authorization • Access control rules based on constraints over the requester, the action, the target and the general context • Example 1 : Stock service is not accessible after the market closes • Example 2 : Only members of the LAIT lab who are Ph.D. students can use the LAIT lab laser printer • Privacy • User restricts his access to services as constraints over input/output of services • Example 3 : Do not disclose my SSN • Confidentiality • User specifies the cryptographic protocols required for the input and output of the service • Policy 5 : Do not use a service that doesn’t encrypt all input/output • Policy 6 : Use only those services that require my SSN if it is encrypted

  49. Example • Mary is looking for a reservation service • foaf description • BravoAir is a reservation service • OWL-S description • Authorization policy • Only users belonging to the same project as John can access the service

  50. Mary <!-- Mary's FOAF description --> <foaf:Person rdf:ID="mary"> <foaf:name>Mary Smith</foaf:name> <foaf:title>Ms</foaf:title> <foaf:firstName>Mary</foaf:firstName> <foaf:surname>Smith</foaf:surname> <foaf:homepage rdf:resource="http://www.somewebsite.com/marysmith.html"/> <foaf:currentProject rdf:resource=" &some;SWS-Project "/> <sws:policyEnforced rdf:resource="&mary;ConfidentalityPolicy"/> </foaf:Person> </rdf:RDF>

More Related