A policy specification language for governing open dynamic distributed environments
Download
1 / 58

A Policy Specification Language for Governing Open, Dynamic Distributed Environments - PowerPoint PPT Presentation


  • 115 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'A Policy Specification Language for Governing Open, Dynamic Distributed Environments' - lala


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
A policy specification language for governing open dynamic distributed environments l.jpg

A Policy Specification Language for Governing Open, Dynamic Distributed Environments

Lalana Kagal, University of Maryland Baltimore County


Outline l.jpg
Outline Distributed Environments

  • Environments under consideration

  • Key Idea

  • Rei : a policy specification language

  • Examples

    • Collaborative MAS

    • Pervasive Computing

    • Internet Privacy

    • Semantic web services

  • Related Work

  • Contributions

  • Summary


Characteristics of the domain l.jpg

Characteristics Distributed Environments

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


Key idea l.jpg

Restriction on mechanism Distributed Environments

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


What are policies l.jpg
What are Policies ? Distributed Environments

  • 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


An early policy for agents l.jpg
An early policy for agents Distributed Environments

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.


On policies rules and laws l.jpg
On policies, rules and laws Distributed Environments

  • 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?


Rei policy spec language l.jpg
Rei Policy Spec Language Distributed Environments

  • 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


Some rei examples l.jpg
Some Rei Examples Distributed Environments

  • 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


Rei policy spec language10 l.jpg
Rei Policy Spec Language Distributed Environments

  • 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 ? ….


Rei policy spec language11 l.jpg
Rei Policy Spec Language Distributed Environments

  • 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)


Rei specifications l.jpg
Rei Specifications Distributed Environments

  • Rei Ontologies

    • Core specs

      • Policy

      • Granting

      • Action

      • Deontic Object

      • Speech Act

      • Meta Policy

      • Constraint

    • Authoring aid specs

      • Analysis


Constraint l.jpg
Constraint Distributed Environments

  • 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


Policy l.jpg
Policy Distributed Environments

  • 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>


Granting l.jpg
Granting Distributed Environments

  • 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


Granting16 l.jpg
Granting Distributed Environments

  • 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>


Deontic object l.jpg
Deontic Object Distributed Environments

  • Deontic objects

    • Permissions, Prohibitions, Obligations, Dispensations (waiver for obligations)

    • Common Properties : Actor, Action, Constraint {StartingConstraint, EndingConstraint}

    • StartingConstraint subproperty of Constraint


Permission l.jpg
Permission Distributed Environments

  • ~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


Example permission l.jpg
Example Permission Distributed Environments

  • 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>


Prohibition l.jpg
Prohibition Distributed Environments

  • 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


Obligation l.jpg
Obligation Distributed Environments

  • 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


Example obligation l.jpg
Example Obligation Distributed Environments

  • 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>


Dispensation l.jpg
Dispensation Distributed Environments

  • ~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


Action l.jpg
Action Distributed Environments

  • 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>


Action25 l.jpg
Action Distributed Environments

  • 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>


Speech acts l.jpg
Speech Acts Distributed Environments

  • 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


Delegation l.jpg
Delegation Distributed Environments

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


Example delegation l.jpg
Example Delegation Distributed Environments

  • 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>


Permission to delegate l.jpg
Permission To Delegate Distributed Environments

  • 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>


Request l.jpg
Request Distributed Environments

  • 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


Revocation l.jpg
Revocation Distributed Environments

  • 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>


Cancel l.jpg
Cancel Distributed Environments

  • 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


Meta policy l.jpg
Meta Policy Distributed Environments

  • 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


Priority l.jpg
Priority Distributed Environments

  • 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


Modality precedence l.jpg
Modality Precedence Distributed Environments

  • 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>


Analysis l.jpg
Analysis Distributed Environments

  • 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 ?


Usecase analysis l.jpg
UseCase Analysis Distributed Environments

  • 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>


Usecase analysis38 l.jpg
UseCase Analysis Distributed Environments

  • 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>


What if analysis l.jpg
What-If Analysis Distributed Environments

  • 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


What if analysis40 l.jpg
What-If Analysis Distributed Environments

  • 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>


Implementation details l.jpg
Implementation Details Distributed Environments

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


Applications past present future l.jpg
Applications – past, present & future Distributed Environments

  • 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…


Collaborative multi agent systems l.jpg
COLLABORATIVE MULTI-AGENT SYSTEMS Distributed Environments

  • 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


Pervasive computing l.jpg
PERVASIVE COMPUTING Distributed Environments

Should I allow this access ?

Should I trust this service ?


Applications l.jpg
Applications Distributed Environments

  • 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


Semantic web services l.jpg
SEMANTIC WEB SERVICES Distributed Environments

  • 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


Our approach l.jpg
Our Approach Distributed Environments

  • 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


  • Example policies l.jpg
    Example policies Distributed Environments

    • 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


    Example l.jpg
    Example Distributed Environments

    • 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


    Slide50 l.jpg
    Mary Distributed Environments

    <!-- 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>


    Bravoair policy l.jpg

    <deontic: Distributed EnvironmentsPermission rdf:ID=”AccessPermission">

    <deontic:actor rdf:resource=”#var1"/>

    <deontic:action rdf:resource="&bravo-service;BravoAir_ReservationAgent"/>

    <deontic:constraint rdf:resource=”#AndCondition1"/>

    </deontic:Permission>

    ………

    <rdf:Description rdf:about="&bravo-service;BravoAir_ReservationAgent">

    <sws:policyEnforced rdf:resource=”#AuthPolicy"/>

    </rdf:Description>

    BravoAir Policy

    <entity:Variable rdf:ID="var1"/>

    <entity:Variable rdf:ID="var2"/>

    <constraint:SimpleConstraint rdf:ID="GetJohnProject"

    constraint:subject="&john;John"

    constraint:predicate="&foaf;currentProject"

    constraint:object=”#var2"/>

    <constraint:SimpleConstraint rdf:ID="SameProjectAsJohn"

    constraint:subject=”#var1"

    constraint:predicate="&foaf;currentProject"

    constraint:object=”#var2"/>

    <!-- constraints combined -->

    <constraint:And rdf:ID="AndCondition1"

    constraint:first=”#GetJohnProject"

    constraint:second=”#SameProjectAsJohn"/>


    How it works l.jpg
    How it works Distributed Environments

    BravoAirWeb service

    Mary

    URL to foaf desc+ query request

    <sws:policyEnforced rdf:resource = "&bravo-policy;AuthPolicy"/>

    Matchmaker+Reasoner

    Bravo Service OWL-S Desc


    How it works53 l.jpg
    How it works Distributed Environments

    Mary’s query = BravoAir ? YES

    Extract Bravo’s policy

    Does Mary meets Bravo’s policy ?

    <deontic:Permission rdf:about="&bravo-policy;AccessPermission">

    <deontic:actor rdf:resource="&bravo-policy;var1"/>

    <deontic:action rdf:resource="&bravo-service;BravoAir_ReservationAgent"/>

    <deontic:constraint rdf:resource="&bravo-policy;AndCondition1"/>

    </deontic:Permission>

    <policy:Granting rdf:about="&bravo-policy;AuthGranting">

    <policy:to rdf:resource="&bravo-policy;var1"/>

    <policy:deontic rdf:resource="&bravo-policy;AccessPermission"/>

    </policy:Granting>

    <sws:AuthorizationPolicy rdf:about="&bravo-policy;AuthPolicy">

    <policy:grants rdf:resource="&bravo-policy;AuthGranting"/>

    </sws:AuthorizationPolicy>

    <rdf:Description rdf:about="&bravo-service;BravoAir_ReservationAgent">

    <sws:policyEnforced rdf:resource="&bravo-policy;AuthPolicy"/>

    </rdf:Description>

    Authorization enforcement complete

    <constraint:SimpleConstraint

    rdf:about = "&bravo-policy;GetJohnProject” constraint:subject="&john;John"

    constraint:predicate="&foaf;currentProject" constraint:object="&bravo-policy;var2"/>

    var2 = &some;SWS-Project

    BravoAirWeb service

    Mary

    <foaf:currentProject rdf:resource = ”&some;SWS-Project"/>

    <constraint:SimpleConstraint

    rdf:about="&bravo-policy;SameProjectAsJohn"

    constraint:subject="&bravo-policy;var1"

    constraint:predicate="&foaf;currentProject"

    constraint:object="&bravo-policy;var2"/>

    Is the constraint true when var2 = http://www.somewebsite.com/SWS-Project.rdfvar1 = http://www.cs.umbc.edu/~lkagal1/rei/examples/sws-sec/MaryProfile.rdf


    Related work l.jpg
    Related Work Distributed Environments

    • WS-*

    • SAML

    • XACML : OASIS eXtensible Access Control Markup Language

    • EPAL : IBM Enterprise Privacy Authorization Language

    • Ponder

    • KeyNote

    • KAoS : Knowledgeable Agent-oriented System


    Contributions of rei l.jpg
    Contributions of Rei Distributed Environments

    • Rei Methodology

      • Domain knowledge represented in ontology languages

      • Declarative policies

    • Rei Policy Specification Language

      • Expressive and Extensible

      • Dynamic policy modification

      • Dynamic conflict resolution

      • Analysis specifications

    • Rei Tools

    • Used in a variety of applications within and outside of UMBC


    Future work l.jpg
    Future Work Distributed Environments

    • Enhancements

      • Formal semantics

      • Use of Courteous Logic

      • Static conflict detection

      • Provide explanation for failed decisions

        • Example

          • Policy : Only users who belong to the CS dept are permitted to use Y

          • X is in the Bio dept

          • Does X have the permission to perform Y ? Ans : No, Explanation : Because X does not belong to the CS dept

    • Applications

      • Digital Rights Management

      • HIPAA

      • Content Filtering


    Summary l.jpg
    Summary Distributed Environments

    • Declarative policies are useful for constraining autonomous behavior in open, distributed systems

    • The Rei policy language and associated tools have provided a good base

    • Semantic web languages (e.g., OWL) used, grounding descriptions in sharable, semantically rich, machine understandable ontologies

    • We’re evaluating and exploring the utility of policies through prototype applications


    For more information l.jpg
    For more information Distributed Environments

    http://rei.umbc.edu/


    ad