Capabilities and Constraints

beansproutscompleteΛογισμικό & κατασκευή λογ/κού

13 Δεκ 2013 (πριν από 3 χρόνια και 7 μήνες)

79 εμφανίσεις

1

of 30



Declarative Policies for Describing Web Service
Capabilities and Constraints

Lalana Kagal

Tim Finin

Anupam Joshi


University of Maryland Baltimore County

UMBC Position Paper

2

of 30

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

of 30

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

of 30

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

of 30

Possible Enforcement

1.
Add enforcement mechanism to a broker or MatchMaker


Centralized

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

3.
Obligation management


Policy framework by forcing the entity to behave a certain way


Reputation servers, penalties etc.

6

of 30

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

of 30

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

of 30


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

Rei Policy Spec Language

9

of 30

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

of 30

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

of 30

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

of 30

Univ:advisedBy

Univ:affiliatedTo

Univ:locatedIn

X

Y

Z

P

IS PERMITTED TO PERFORM ANY ACTION WHOSE TARGET IS

P

IF

X

Building Rei Policies

rdf:type

13

of 30

Rei Specifications


Core specs


Policy


Granting


Action


Deontic Object


Speech Act


Meta Policy


Constraint


Authoring specs


Analysis

14

of 30

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

of 30

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

of 30

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

of 30

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

of 30

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

of 30

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

of 30

Implementation Details


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

XSB

FLORA

YAJXB

JAVA API

FOWL

Image adapted from Mohinder Chopra

REI

REI INTERFACE

POLICY ENGINEER/APPL

21

of 30

1999

2002

2003

2004



Applications


past, present & future

1.
Coordinating access in supply chain management

system
(EECOMS
-

IBM lead)

2.
Authorization policies in a pervasive computing

environment
(UMBC)

3.
Policies for team formation, collaboration, information

flow in multi
-
agent systems
(Genoa II (Topsail)
-

Global Infotek,
UMBC)

4.
Policies for semantic web services
(UMBC, SRI, CMU)

5.
Privacy and trust on the Internet
(UMBC)

6.
Enforcing domain policies on handhelds in pervasive computing
environments
(UMBC, NIST)

7.
Privacy in a pervasive computing environment
(UMBC)

8.
Task Computing
(Fujitsu Labs, UMBC)

9.
Dynamic Policy Management
(Arizona State Univ)

22

of 30

Declarative

Related Work

Non SW

Procedural

KAoS

Rei

PDL

ASL

PolicyMaker
KeyNote
Delegation Logic

Ponder

SPKI

RBAC

XACML

EPAL

SAML
WS*

XML

SW

23

of 30

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

of 30

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

of 30

Case Study : How it Works

Access request +privacy policy
+ privileges + permissions

BravoAir

Web service

Client

P3P policy + (access control
policy) + privileges +
permissions

Broker + Rei engine

26

of 30

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

of 30

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

of 30

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

of 30

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

of 30

For more information





http://rei.umbc.edu