Design of a Policy-Driven Middleware for Secure Distributed Collaboration

Please download to get full document.

View again

of 8
59 views
PDF
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Document Description
Design of a Policy-Driven Middleware for Secure Distributed Collaboration
Document Share
Document Tags
Document Transcript
  Design of a Policy-Driven Middleware for Secure Distributed Collaboration   Anand R. Tripathi, Tanvir Ahmed, Richa Kumar, and Shremattie JamanDepartment of Computer ScienceUniversity of Minnesota, Minneapolis MN 55455 Abstract We present here the execution model of a policy-drivenmiddleware for building secure distributed collaborationsystems from their high level specifications. Our specifi-cation model supports nested collaboration activities, and uses role-based security policies and event count based co-ordination specification. From the specifications of a col-laboration environment, appropriatepolicy modules are de-rived for enforcing security and coordination requirements. A policy-driven distributed middleware provides services tothe users to join roles in an activity, perform role specificoperations, or create new activities. We describe here thedesign challenges for the middleware and present the run-time structures and protocols supported by it for creatingactivities, roles, and objects. 1 Introduction In a Computer Supported Cooperative Work (CSCW)system, a group of users interact and collaborate usingshared objects towards some common objectives [5]. Suchsystems range from real-time synchronous collaborationslike online conferencing, interactive authoring of docu-ments, to asynchronous workflow like collaboration in anoffice environment. Compared to traditional office automa-tion workflow where activities are predefined, activities inreal-time groupware systems are managed in an ad hocmanner [1]. The key issues in CSCW systems so far havebeen group awareness, multi-user interfaces, concurrencycontrol, and coordination policies within the collaboratinggroups. However, security specification models for CSCWsystems and the realization of the desired policies in an im-plemented system is a relatively new research area. Onlyfew systems have addressed security policy specificationmodels for collaboration systems; moreover, most of themhave mainly concentrated on specific areas of CSCW likeshared window based systems [4]. ✁ This work was supported by National Science Foundation grants ITR0082215 and EIA 9818338. Our goal is to rapidly realize secure distributed collab-oration systems from high level specifications comprisingof security and coordination policies. A policy-driven sys-tem is able to specify the dynamic nature of CSCW activ-ities and enforce coordination and security policies at run-time through a middleware. Existing policy driven CSCWsystems, like COCA [8] and DCWPL [2], do not empha-size security issues in collaborative environments and arebuilt mainly for shared interactive groupware applications.These systems are for smaller time-space limited activities,and therefore the models for describing the desired systemscannot implement large workflow like CSCW environmentswhere multiple CSCW applications may come into exis-tence within a single collaboration framework. Runtime EnvironmentSpecification CollaborationEnvironmentPolicy DrivenProtocols andDistributedMiddlewareServicesof a Modules fromof PolicyDerivationSpecification Figure 1. A framework for distributed collab-oration systems In our model, a policy-driven collaboration system is re-alizedin threesteps as showninFigure 1. Initially, thecoor-dination and security policy for a collaboration is specifiedbased on a schema. From the specification, various pol-icy modules are derived for different kinds of requirements,such as role based security, object level access control, andevent notification for coordination. Finally, through thesemodules, the collaboration environment is realized by ageneric middleware. As a first step towards our approach,we have developed a specification model [11] in which acollaborative system is defined in terms of activities, rolesand objects. The model allows dynamic assignments of roles, “separation of duties” constraints, multiple user par-ticipation in a role, dynamic security policies, and hierar-chical activity definitions.  This paper focuses on the design of a policy-driven mid-dleware, which realizes the desired collaboration environ-ment from its specification by generating policy modulesand providing services and protocols for the runtime sys-tem. Our prototype implementation of this middleware isbased on Java. The constraints and challenges in designingsuch a middleware are as follows:1. All nodes within a distributed system cannot betrusted. Collaborating users work within their own localenvironments, which can be tampered with, and thereforepolicy enforcement and verification cannot be carried out atthe user’s end. However, within the system, certain nodesmay be anointed as ”trusted”. Management activities andstorage of shared data may take place at such nodes.2. Eachuserinthesystemhasaviewofthepolicy, whichis specific to his/her role. These views need to be securelydistributed to the collaborating users. Due to the dynamicnature of the specification, these views may change at run-time and need to be appropriately updated.3. Policies are required for secure storage of shared ob- jects in a collaboration environment. Access control poli-cies for an object can change based on context specific con-ditions for a collaboration. During the life cycle of an ob- ject, the trusted nodes for the object can change.4. Roles within different activities represent different en-tities and need to be managed in their own domain of trust.Role management policies have to be established.5. Operations performed by the users need to be securelycommunicated to other entities for coordination and secu-rity purposes. Enforcement of coordination conditions hasto be delegated only to secure nodes.A brief overview of our specification model is presentedin Section 2 with a detailed example specification of a col-laboration environment. Section 3 presents the challengesand constraints in designing a policy-driven middleware forsecure distributed collaborations. In Section 4, we detailthe distributed execution model of the system using the ex-ample from Section 2. Section 5 presents an overview of activity creation and view management protocols. Section6 outlines how policy modules are derived. Section 7 and 8discuss the related work and the conclusions. 2 Collaboration Specification Model 2.1 Overview of the Model This section gives a summary of the specification modelpresented in [11]. In this model, an activity definition spec-ifies a generic collaboration pattern among a set of roles us-ing some shared objects. These entities are specified andnamed in nested scopes of activities as shown in Figure2. An activity defines a protection domain and a scope forthe roles, objects, and privileges in a collaboration. Impor-tantly, it works like a template and facilitates specificationof dynamic or runtime behavior of a collaboration basedon object types and roles. Any number of instances of itcan be dynamically and concurrently instantiated. Thereare three major elements in specifying a collaboration ac-tivity: shared objects, roles, and operations. Shared objects ACTIVITY ExamSession Role ReflectionParameter Objects ACTIVITY Course Legend: AnswerBook Role Assignment GradeSheet ExamPaper ROLE ExamineeROLE GraderROLE CandidateROLE CheckerROLE Examiner   ROLE AssistantROLE InstructorROLE Student AnswerBook ExamPaper ACTIVITY Examination Figure 2. Hierarchical structuring of collabo-rative activities are represented only in terms of their types and method sig-natures, keeping the semantics and implementation detailstransparent. We can specify access control at the granu-larity of the methods invoked on these objects. User levelaccess control is specified in the scope of a role as part of its operation specifications. The object level access controlspecification is derived from various roles’ privileges for anobject.A role operation may consist of a method invocation ona shared object, a synchronization action, or a role request.A role request is an operation to either  join  or  leave  a role.A synchronization action results in sending a coordinationevent to other entities.In defining a role, we consider three types of constraints.The  role admission condition  puts constraints on admittinga participant to a role. The  role activation condition  must besatisfiedwhenaroleisactivated. The  precondition ofanop-eration must be satisfied for a member in the role to executethe operation. In the specification model, a boolean func-tion  member(role, user)  checks if a participant is present ina role,  members(role)  gives the list of participants in a role,and the number of participants admitted in a role is given by #(members(role)) .Every activity instance has two meta roles:  Creator   and Owner  . The user initiating the activity is admitted to the Creator   role. The owner of an activity may be differentfrom its creator and can be specified in the activity def-inition. If not specified, the owner of the parent activity2  becomes the default owner. The owner of an activity alsoowns the roles encapsulated within its scope.Coordination and dynamic security policies in our spec-ification model are expressed using events and event coun-ters based on the model presented in [9]. Related toeach role operation are three types of events:  request,start,  and  finish . For example,  role-name.op.start   or  role-name.op.finish . These event types are also defined for eachobject method. The corresponding event counters are usedfor synchronization specifications. For a role, events are de-fined for  join ,  leave ,  admit  , and  remove  operations.The multiple occurrences of a given event type are repre-sentedbyalist. Theexpression (eventName) returns alistof all the instances of this type of event. Hence,  #(eventName) returns the number of times the event has occurred. In ourmodel, one can also specify a derived event type by filteringan event list based on its attributes. For example, for a roleoperation execution, we can define a filter based on invokerid, such as  opName.start(invoker=John) . 2.2 An Example of Activity Specification Using the  Course  example of Figure 2, we illustratesome of the key features of the specification model: hier-archical activities, creation of activity instances, and pass-ing of objects and role participants from an activity to itschild activity. In Figure 3, we describe the specification of the nested  Examination  activity shown in Figure 2. In oursystem, these specifications are expressed in XML.An entity (such as an activity, object, object method,role, role operation or event)encapsulatedin the scopeof anactivity can be referenced by a fully qualified name. Withinan activity, one can refer to its current instance using thepseudo variable  thisActivity , and its creator using  parentAc-tivity . The user executing an operation is identified by  this-User  .In Figure 2, a  Course  activity consists of an  Instructor  role, an  Assistant   role with possibly multiple teaching as-sistants as its members, and a  Student   role. In the  Course activity, the  Examination  activity is defined as a nested ac-tivity. A participant in the  Examinee  role within this activitycan create an  ExamSession  activity to take the examination.The participants in the  Grader   role are responsible for grad-ing the students’ answer-books.A nested activity may need to have access to the objectsinitsparentactivity, ortheparticipantsinaroleintheparentactivity may need to be admitted to a role in a nested activ-ity. There are three ways in which users can be admitted toa role within an activity:  role reflection, role assignment  , ora member simply joins a role. Using role reflection, in anactivity definition, a role in an activity can be statically as-signed to a role in a nested activity. This means that all themembers of the parent role become members of the role in ACTIVITY Examination (OWNER Instructor,ASSIGNED_ROLES Examiner) {OBJECT_TYPE ExamPaper (CODEBASE=http://codeserver) {METHOD setPaper {PARAM PaperType}METHOD readPaper {RETURN PaperType}}OBJECT_TYPE AnswerBook (CODEBASE=http://codeserver) {METHOD writeAnswer {PARAM AnswerType}METHOD setGrade {PARAM GradeType}}ROLE Examiner {OPERATION SetPaper {PRECONDITION #(SetPaper.start)=0ACTION { exam=new OBJECT(ExamPaper)exam.setPaper(data)}}}ROLE Examinee (REFLECT parentActivity.Student) {OPERATION StartExam {PRECONDITION #(Examiner.SetPaper.finish)=1& #(StartExam.start(invoker=thisUser))=0ACTION {obj=new OBJECT(AnswerBook)act=new ACTIVITY ExamSession((exam,obj), Canadidate=thisUser)}}}ROLE Grader (REFLECT parentActivity.Assistant,parentActivity.Instructor) {}ACTIVITY ExamSession( OWNER Grader,OBJECTS (Course.ExamPaper exam,Course.Examination.AnswerBook ans),ASSIGNED_ROLES Candidate) {TERMINATION_CONDITION: #(Checker.Grade.finish)>0ROLE Candidate {ADMISSION_CONSTRAINTSmember(thisUser, parentActivity.Examinee)& thisActivity.creator=thisUser& #members(thisRole)<1ACTIVATION_CONSTRAINTSdate > DATE(Jan, 12, 2001, 12:00)& date < DATE(Jan, 12, 2001, 15:00)OPERATION Read {ACTION exam.readPaper()}OPERATION Write {ACTION ans.writeAnswer(data) }OPERATION Submit {PRECONDITION #(Write.finish)>0 }}ROLE Checker {ADMISSION_CONSTRAINTS#members(thisRole)<1& member(thisUser, parentActivity.Grader)OPERATION Grade {PRECONDITION #(Candidate.Submit.finish)=1ACTION ans.setGrade(data)}} } } Figure 3. Specification of an Examination the child activity, at the time of activity creation, subject toits admission constraints. Removal of a participant from thereflected role (i.e. a role in the parent activity), also impliesremoval from the role in the child activity. A participantin the reflected role gains expanded privileges comprisingof the operations of the child activity role. In our example,both the  Instructor   and the  Assistant   roles in the  Course  ac-tivity are reflected in the  Grader   role of the  Examination activity. When an instance of this activity is created, themembers of these two roles are admitted to the  Grader   role.Therefore, an admitted participant in the  Grader   role canperform operations on the  GradeSheet   object in the  Course 3  activity as wellas on theobjects in the  Examination  activity.Similarly, the participants in the  Student   role are reflected inthe  Examinee  role.Participants can also be dynamically assigned to a roleas part of activity creation. The ASSIGNED ROLES tag inan activity definition specifies the roles that need to be as-signed during activity creation. For example, as specified inFigure 3, participants for the  Examiner   role have to be as-signed at the time of an  Examination  activity instantiation.Also, the owner of a role can assign participants to that role.For example, when the  ExamSession  activity is created byan examinee, the  Grader   role becomes the owner of that ac-tivity and the roles within its scope. The  Grader  , being theowner of the  Checker   role, may assign a participant to it.In Figure 3, a student in the  Examinee  role can initiate anexamination session by invoking the  StartExam  operation.However, he/she cannot initiate two sessions of this exami-nation as enforced by the precondition. The  StartExam  op-eration starts an  ExamSession  activity. The  ExamSession activity contains the roles  Candidate  and  Checker  . Onlythe student creating this activity is assigned to the  Candi-date  role. References to two objects, an  ExamPaper   andan  AnswerBook  , are passed as parameters to an exam ses-sion activity. A single  ExamPaper   object is shared by allthe sessions. On the other hand, a new  AnswerBook   objectis created for each student’s exam session. This  ExamSes-sion  activity terminates when the checker finishes gradingthe answer book. The activation constraints ensure that theexamination must be taken during the specified three hourperiod.A candidate can perform operations to read the exampaper and write the answer book. The  Submit   operationcan only be performed when something is written. How-ever,  Submit   does not invoke any method, rather it createsan event subscribed by the  Checker   role for coordination.The checker can only grade after the answer book is sub-mitted. The cardinality of the  Checker   role is one, i.e, onlyone checker can be assigned to an answer book. 3 Middleware Design Challenges The distributed architecture and security considerationsofthepolicy-drivenmiddlewareimposeseveraldesignchal-lenges, as discussed below. Policy module creation and distribution:  Several dif-ferent kinds of policy modules are needed to manage an ac-tivity. Foraroleinanactivity, weneedapolicymodulecon-taining admission and activation constraints. It should alsocontain preconditions for role operations together with thedirectives for subscribing events from other entities in thesystem for evaluating these preconditions. For an object, arole-based access control list is required by its object server.This access control list should identify the method invoca-tion privileges that should be given to a role in a specificactivity instance, together with the role operation context inwhich a method is invoked. Because an invoker may not betrusted, the object server should also verify the operation’sprecondition. For an activity template, we need a policymodule defining the activity creation privileges to be givento certain roles. An activity instance can have templates fornested activities, which need to be made visible to the par-ticipants in various roles within that instance. For example,the  Examination  activity has the  ExamSession  template.From an activity definition, we need to build templatesfor policy modules. When an activity instance is created,the corresponding policy templates also need to be instan-tiated using context specific information pertaining to thenew instance. These modules then need to be communi-cated to the appropriate roles and object servers. Secure sites for policy enforcement:  The creator of anactivity may not always be trusted with the responsibilityfor that activity’s management. In the  ExamSession  activ-ity example, a student in the  Examinee  role creates an  Ex-amSession  activity. However, the student’s node cannot betrusted to enforce security policies for the  ExamSession  ac-tivity, as a student can change and manipulate the activityspecific policies. Only trusted secure sites for a role shouldbe able to maintain its membership information and enforcerole membership operations. Similarly, only trusted sitesshould control who can create an activity instance from atemplate.When there are multiple participants in a role, we needmechanisms to ensure that preconditions for operations areevaluated and enforced consistently and securely. Considerthe precondition for the  Examiner   role’s  SetPaper   opera-tion, which requires that the  SetPaper   operation must nothave been started by anyone else. Initially this preconditionis true for all participants; therefore, we need a mechanismso that only one of them starts this operation. Distributed trust relationship among roles:  Users par-ticipate in a collaboration through roles in the context of activities. The participants may need to be uniquely identi-fied for inter-role coordination, i.e, the participant may needto be uniquely identified in the context of a role. In somecases participants are admitted to a role based on their rolein a parent activity, like the  Grader   role in our example. If membership certificates are used for enforcing such admis-sion conditions, a trust relationship needs to be maintainedamong participating sites to enforce the authenticity of suchcertificates. Different situations may warrant different revo-cationpolicies, whichcouldbe immediate or delayed  . Inthe  ExamSession  activity, a user can be given a  Candidate  rolecertificate, which can be used once per session. Though thecertificate is based on the user’s previous  Student   role cer-tificate, the  Candidate  role certificate need not expire evenif the  Student   role certificate expires. On the other hand, the4  invalidation of the reflected  Assistant   role certificate has tobe propagated immediately to the  Grader   role. Object storage and protection:  The stages of a work-flow can change ownership and other access control poli-cies of an object. Arbitrary storage location of an objectcannot be trusted. If a trusted site is specified during objectcreation, this site may not be trusted at a later stage of theworkflow. In our example, the student in an  ExamSession activity creates an  AnswerBook   object and should be theowner of this object. However, after submitting the answerbook, the student should not be able to make modifications,and the ownership has to be transfered to the  Grader   role.The owner of an object can impose additional discretionaryaccess control on the object.Various versions of an object may reside at different lo-cations. Each object needs to maintain and enforce its ac-cess control policy. A subject needs to be uniquely identi-fied by its activity, role, and often by user identity certifi-cates. Similar authentication is required for modifying thepolicy object itself.Enforcing preconditions of an operation only at theusers’ nodes is not secure and must be enforced at a se-cure site where the object is stored. For example, enforc-ing the precondition  #(Candidate.Submit.finish)=1 of the  Grade  operation only at the  Checker   role’s node doesnot guarantee consistency. It is possible for a malicioususer to tamper with execution environment at his/her nodeand invoke an object method even when the preconditionfor the corresponding operation is not true. Therefore, foreach method invocation we require the object server to ver-ify the invoker’s id, role, and the name of the role operationin which this method is being invoked. It should then verifythe operation precondition and access rights. Secure distributed event service:  The coordination andthe dynamic security policies are specified as preconditionsor constraints based on event counts. Our approach re-quires event subscription-notification policy modules to bederived from the specification. Additionally, event integrityand secrecy need to be guaranteed. Only authorized entitiesshould be able to generate or receive an event. 4 Distributed Execution Model Every activity in our model is represented as an objecttree structure. This tree structure representation is usedbothfor system-level management of an activity as well as forbuilding user-level interfaces for the participants. A nodein the object tree of an activity represents a nested entitysuch as an activity template, an activity instance, an ob- ject type, an object instance, or a role. A node represent-ing a nested activity forms a subtree within its parent ac-tivity’s object tree. The primary function of a node is toprovide access to management functions for the entity thatit represents. For example, the node for an activity templatesupports functions for creating new instances in compliancewith the security policies, and keeping track of all instancesof the activity. For each instance, it maintains child node.A node corresponding to a role is responsible for admit-ting/removing users from the role and enforcing admissionconstraints when a user joins a role. It also provides to theparticipants interfaces for invoking role-specific operationssubject to coordination conditions.Object type nodes have functions similar to the activ-ity template managers, they decide which roles can cre-ate an instance of that type, and maintain references toall the object instances that are created. Nodes repre-senting object instances are responsible for object storage,caching/replication management, and authenticated invoca-tion of its methods. The object tree graph of a collaborationmay change at runtime as new activities or objects are cre-ated.Inadistributedenvironmentthistreestructureispartiallyreplicated to provide each participant a view of the collab-orative environment based on his/her role-based privileges.We refer to this as a  role-specific view . A node representingan entity in the object tree can be visible to multiple par-ticipants. One node among all these nodes, which is main-tained at a trusted site is designated as the  authoritative  or  primary node  for that entity. A primary node is responsiblefor managing all security sensitive functions and event sub-scriptions for the entity it represents. For example, an ob- ject instance’s persistent storage is maintained at an objectserver, which is trusted by the user having the primary nodefor it. All other users which see that entity have a  stub node to communicate with the primary node. The stub node con-tains the protocols for authenticated invocation of functionsat the primary node. In some cases, the primary node of anobject may support caching of the object by its stub nodes.Also, each primary node maintains references to the othercopies (which are stub nodes) for performing any callback functions, for example, role revocation and event commu-nication.The system provides each user with a coordinator onhis/her system, the  User Coordination Interface (UCI) ,which maintains the user’s view of the object tree and pro-vides suitable interfaces to the user. Whenever a user joinsthe environment, he/she first sees only a default root-levelactivity, termed  System . To define a new collaboration sys-tem, a user in the  Convener   role in the  System  activity de-velops an activity template for it and installs it under the System  node. A user can list all the activities that have beendefined under  System  and that he/she can join. The primarynode for the activity is located at the owner’s UCI. It is es-sential that the owner of an activity be trusted. The defaultowner of any activity is the owner of its parent activity, un-less otherwise specified.5
Search Related
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks