a policy specification language for governing open, dynamic distributed environments
Post on 31-Dec-2015
26 Views
Preview:
DESCRIPTION
TRANSCRIPT
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 CountyLalana Kagal, University of Maryland Baltimore County
2 of 59
OutlineOutline 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 of 59
Characteristics of the DomainCharacteristics of the DomainCharacteristics
1. Resources and clients are not pre-determined
2. Constantly evolving
3. Usually very large number of resources, services and clients
4. Presence of semi-autonomous entities
5. Span several domains
6. Entities belong to several domains
Restriction on mechanism1. Mechanism cannot list access rights of
individuals
2. Run-time modification should be possible
3. It should be possible to control sets of clients and services grouped by certain common characteristics
4. Mechanism should be automated
5. Mechanism should be easily extensible to be usable for any domain-specific information
6. Mechanism should include some way to handle conflicts in behavior specifications
4 of 59
Key IdeaKey IdeaRestriction 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
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 of 59
What are Policies ?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 of 59
An early policy for agentsAn early policy for agents1 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 of 59
On policies, rules and lawsOn 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 of 59
Rei Policy Spec LanguageRei 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 of 59
Some Rei ExamplesSome 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 of 59
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 LanguageRei Policy Spec Language
11 of 59
Rei Policy Spec LanguageRei 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 of 59
Rei SpecificationsRei Specifications Rei Ontologies
Core specs Policy Granting Action Deontic Object Speech Act Meta Policy Constraint
Authoring aid specs Analysis
13 of 59
ConstraintConstraint 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 of 59
PolicyPolicy 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 of 59
GrantingGranting 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 of 59
GrantingGranting 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 of 59
Deontic ObjectDeontic Object Deontic objects
Permissions, Prohibitions, Obligations, Dispensations (waiver for obligations)
Common Properties : Actor, Action, Constraint {StartingConstraint, EndingConstraint}
StartingConstraint subproperty of Constraint
18 of 59
PermissionPermission ~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 of 59
Example PermissionExample 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 of 59
ProhibitionProhibition 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 of 59
ObligationObligation 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 of 59
Example ObligationExample 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 of 59
DispensationDispensation ~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 of 59
ActionAction 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 of 59
ActionAction 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 of 59
Speech ActsSpeech 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 of 59
DelegationDelegation 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 of 59
Example DelegationExample 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 of 59
Permission To DelegatePermission 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 of 59
RequestRequest 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 of 59
RevocationRevocation 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 of 59
CancelCancel 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 of 59
Meta PolicyMeta 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 of 59
PriorityPriority 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 of 59
Modality PrecedenceModality 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 of 59
AnalysisAnalysis 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 of 59
UseCase AnalysisUseCase 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 of 59
UseCase AnalysisUseCase 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 of 59
What-If AnalysisWhat-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 of 59
What-If AnalysisWhat-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 of 59
Implementation DetailsImplementation Details XSB
Flora : F-logic over XSB
F-OWL : is a reasoner for RDF, OWL
Java wrapper
XSB
FLORA
YAJXB
USER
JAVA API
FOWL
Image adapted from Mohinder Chopra
REI
REI INTERFACE
42 of 59
1999
2002
2003
2004…
Applications – past, present & future
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)
43 of 59
COLLABORATIVE MULTI-AGENT SYSTEMS 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 of 59
PERVASIVE COMPUTINGPERVASIVE COMPUTING
Should I allow this access ?
Should I trust this service ?
45 of 59
ApplicationsApplications1. 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
2. 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
47 of 59
SEMANTIC WEB SERVICESSEMANTIC 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
48 of 59
Our ApproachOur 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
49 of 59
Example policiesExample 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
50 of 59
ExampleExample 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
51 of 59
MaryMary<!-- 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>
52 of 59
BravoAir PolicyBravoAir 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"/>
<deontic:Permission 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>
53 of 59
How it worksHow it works
Bravo Service OWL-S Desc
URL to foaf desc+ query request
<sws:policyEnforced rdf:resource = "&bravo-policy;AuthPolicy"/>
BravoAirWeb serviceMary
Matchmaker+
Reasoner
54 of 59
How it worksHow it worksMary’s query = BravoAir ? YESExtract Bravo’s policyDoes Mary meets Bravo’s policy ?Authorization enforcement complete
<foaf:currentProject rdf:resource = ”&some;SWS-Project"/>
<constraint:SimpleConstraint rdf:about = "&bravo-policy;GetJohnProject” constraint:subject="&john;John" constraint:predicate="&foaf;currentProject" constraint:object="&bravo-policy;var2"/>
var2 = &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
<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>
MaryBravoAir
Web service
55 of 59
Related WorkRelated Work WS-* SAML XACML : OASIS eXtensible Access Control
Markup Language EPAL : IBM Enterprise Privacy Authorization
Language Ponder KeyNote KAoS : Knowledgeable Agent-oriented System
56 of 59
Contributions of ReiContributions of Rei 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
57 of 59
Future WorkFuture Work 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
58 of 59
SummarySummary 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
top related