1 of 30

1
Declarative Policies for Describing Web Service
Capabilities and Constraints
UMBC Position Paper

• 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
rdftype
P
X
Y
Z
UnivadvisedBy
UnivaffiliatedTo
UnivlocatedIn
IS PERMITTED TO PERFORM ANY ACTION WHOSE TARGET IS
P
IF
X
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

ltdeonticPermission rdfID"Perm_StudentPrinting"gt
ltdeonticactor rdfresource"PersonVar"/gt ltdeont
icaction rdfresource"ObjVar"/gt ltdeonticconstr
aint rdfresource"IsStudentAndBWPrinter"/gt ltdeon
ticprovision rdfresource"Obl_ReplacePaper"/gt lt
/deonticPermissiongt
ltconstraintSimpleConstraint rdfIDIsStudent"gt
ltconstraintsubject rdfresource"PersonVar"/gt lt
constraintpredicate rdfresourcerdftype"/gt lt
constraintobject rdfresource"umbcStudent"/gt lt
/constraintSimpleConstraintgt
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 Martys 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

ltactionDelegation rdfIDMartyToCSStudents"gt
ltactionsender rdfresource"Marty"/gt
ltactionreceiver rdfresource"PersonVar"/gt
ltactioncontentgt ltdeonticPermissiongt
ltdeonticactor rdfresource"PersonVar"/gt
ltdeonticaction rdfresource"ObjectVar"/gt
lt/deonticPermissiongt lt/actioncontentgt
ltactionconditiongt ltconstraintAndgt
ltconstraintfirst rdfresource"IsStudentOfCS"
/gt ltconstraintsecond rdfresource"IsLaserPri
nting"/gt lt/constraintAndgt lt/actionconditiongt
lt/actionDelegationgt
18
Permission To Delegate

• Example Marty has the permission to perform a
  delegation speech act to graduate students wrt
  the LaserPrinting actions

ltdeonticPermission rdfID"Perm_MartyDelegateFacu
ltyCSPrinting"gt ltdeonticactor rdfresource"Marty
"/gt ltdeonticactiongt ltactionDelegation
rdfID"Perm_Del"gt ltactionsender
rdfresourceMarty"/gt ltactionreceiver
rdfresource"PersonVar"/gt ltactioncontentgt
ltdeonticPermissiongt ltdeonticactor
rdfresource"PersonVar"/gt ltdeonticaction
rdfresource"ObjVar"/gt ltdeonticconstraint
rdfresource"IsLaserPrinting"/gt lt/deonticPer
missiongt lt/actioncontentgt lt/actionDelegation
gt lt/deonticactiongt ltdeonticconstraint
rdfresource"IsGraduateStudent"/gt lt/deonticPerm
issiongt
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

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)

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
BravoAirWeb service
Client
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