Policy Management of Enterprise Systems: A Requirements Study Tim Finin, Yelena Yesha Kelly Lyons,...

16
Policy Management of Enterprise Systems: A Requirements Study Tim Finin, Yelena Yesha Kelly Lyons, Jen Hawkins, Stephen Perelgut Pranam Kolari 2006 IEEE Workshop on Policies for Distributed Systems and Networks 7 June 2006 /ebiquity.umbc.edu/paper/html/id/279/

Transcript of Policy Management of Enterprise Systems: A Requirements Study Tim Finin, Yelena Yesha Kelly Lyons,...

Policy Management of Enterprise Systems: A Requirements Study

Tim Finin, Yelena Yesha

Kelly Lyons, Jen Hawkins, Stephen Perelgut

Pranam Kolari

2006 IEEE Workshop on Policies for Distributed Systems and Networks 7 June 2006

http://ebiquity.umbc.edu/paper/html/id/279/

State of the Art, Motivation

• Policy 2005– Security, Trust, Privacy, Policy-based

Management – Network management, Pervasive

Computing, Multi-agent coordination

• Policy 2006– Similar themes this year– Scope of policy management– Panel on Singleton Policies

The Problem

• Policy Management of an Enterprise Web Application– Identify Policy Decision/Influence Points– Domain specific requirement characteristics– Applicability of existing research/tools

• An application case-study– Elicit requirements from users

• GOAL: Abstract out policy management requirements for a new class of applications

CASSIS

• Used by IBM Centers for Advanced Studies (CAS), a university facing department

• Artifact, The Project Proposal• Actors and their Roles

– CAS Research Staff Members (CRSM) initiate proposal from Professors

– Professors/Researchers submit proposal/s– CRSM assigns Reviewers and Evaluators to

proposal– CAS Head approves proposal– CRSM and CAS Head monitor project

• Workflow - Actors interact with the Artifact

Management Requirements

• Tuning and adaptability– Address rotational management

• Accountability– To Proposal submitters– To higher level management– Comply to organizational and regional statutory

requirements

• Along two axes– Privacy– Business

CASSIS Privacy Policies (1)

(i) Java Server Page (JSP) templates common to all roles (ii) Field specific decisions hidden in implementation

CASSIS Privacy Policies (2)

• Role Based Access Control– E.g. Evaluators have access to all reviews, but not

to other evaluations

• Adaptability– Policy Management Autonomic Computing

(PMAC) toolkit– Autonomic Computing Policy Language (ACPL)– Rules hidden in “java” code were now made

explicit

• Accountability– To users, translation to P3P vocabulary– To the enterprise, organization specific vocabulary

CASSIS Business Policies (1)• Directly influences actions in current

state– E.g. CAS RSM – When choosing reviewers,

reviewer location and their IBM department are important

• Influences future actions incrementally– E.g. CAS Head – Past collaboration with

IBM could potentially improve proposal merit

Business Policies (2)

• Event triggering for policy guidance– Screens used by the role players to work on the

artifact

• Conditions based on Knowledge Base (KB)– IBM Intranet, e.g. Employee databases available

within IBM, access APIs available (SOA vision), trustworthy

– Web KB, e.g. publication databases available on the Web, XML data dumps, not trustworthy

– (Intranet+Web) KB , not trustworthy

• Result of Policies– Act as guidelines (recommendations) to role-players

Business Policies (3)

• Traditional Business Policies– Actions directly executed by machines– Typically ECA, Event Condition Action– Trustworthy underlying knowledge base (KB)– Application area -- resource management– Policies are actionable

• How are CASSIS Policies different?– Actions filtered by humans– Policy results influence actions, guidelines– Underlying KB not necessarily trustworthy– Potentially large KB

In the Workflow Context

WWWJustification/Accountability

44

Policy Decision

Point

11

SPARQL

22

44

Knowledge Base

Auditability

Justification

Users

Management

33

Workflow Context - Example• Policy: CAS Head – Past collaboration

with IBM could potentially improve proposal merit

• SPARQL on KB used by Policy Rule

SPARQL

Policy Rule

Workflow Context - Example

PREFIX ibm <http://ibm.com/> PREFIX citeseer <http://citeseer.pst.edu/> PREFIX cas <http://ibm.com/cas>ASK { “[email protected]” ibm:email ?email . ?y citeseer:coauthor ?x . ?y cas:author <cas:Proposal-1> }

PREFIX ibm <http://ibm.com/> PREFIX citeseer <http://citeseer.pst.edu/> PREFIX cas <http://ibm.com/cas>CONSTRUCT { ?x ibm:email ?email . ?y citeseer:coauthor ?x . ?y cas:author <cas:Proposal-1> }WHERE { ?x ibm:email ?email . ?y citeseer:coauthor ?x . ?y cas:author <cas:Proposal-1> }

ASK – Queries as Conditions

CONSTRUCT – Query returns graph patterns, used to display to the user during on a policy recommendation and for later auditing

Continuing Work

• ECR[J] - Event Condition Recommendation [Justification]

• The exact nature of modeling “Recommendation”

• Policy Language Overlaying SPARQL • Details of Justification Repository• Elicit explicit policy rules from

enterprise management

Conclusions

• Enterprise Web Applications amenable to privacy policy enablement

• Interoperability across policy vocabularies continues to be a bottleneck

• Business Policy Enablement raises interesting future challenges– Underlying Knowledge Base– Policies or Guidance?– Auditing/Accountability– Iterative Refinement of Business Policies

Questions?