Specification and Implementation of Secure Distributed Collaboration Systems

Specification and Implementation of Secure DistributedCollaboration SystemsAuthor NameAuthor AffiliationStreet NameCityABSTRACTWe present the design and development of a policy-based framework for the construction of distributed runtime envi-ronments for secure collaboration systems from their speci-fications.We identify the important requirements of security and coordination in role-based collaboration systems,and then develop a specification model to support expression of these requirements.The specifications for a collaboration system are interfaced with a policy-driven middleware to build the distributed runtime environment for it.We present here the core set of facilities of this middleware to support secure management of activities,roles,and objects in a system. INTRODUCTIONThe focus of this paper is on the design and development of a policy-based framework for building secure CSCW systems from their high level specifications.Our main focus is on two important requirements in CSCW systems:coordination and security.The nature of coordination among the participants can range from tightly coupled real-time interactions,as in online conferencing and shared whiteboard environments,to loosely coupled interactions,which are largely characterized by workflow environments.Coordination policies enforce synchronization and precedence constraints on user activi-ties.Security policies on the other hand address requirements related to secrecy and integrity of the shared data,confiden-tiality,auditability and non-repudiation of users’actions,and the integrity of operations to ensure that only authorized par-ticipants perform certain sensitive tasks.Such requirements are specified as which users are allowed to join certain col-laborative activities,what privileges are assigned to them, which tasks can be executed by a user,and which user nodes within a distributed collaboration environment can be trusted. In our approach,from the specification of a collaboration system we derive policies for coordination and security,us-ing which a middleware constructs a distributed execution environment.This kind of policy-based approach decouples the coordination and security aspects of a collaboration from the implementation of its functionalities.This makes it easy for different policies to be plugged in,allowingflexibility in designing a collaboration environment.Several factors mo-tivate this approach.Collaboration environments often span multiple administrative domains.The requirements of a col-laboration system may evolve with changes in administrative policies and user experience.With advances in technology, new devices,tools or artifacts may need to be integrated into a collaboration environment.This can warrant a reconfigura-tion of the system with changes in the governing policies. The primary focus of this paper is on developing techniques for constructing secure distributed collaboration environments from their high level specifications capturing coordination and security requirements.The objective of this work is to support rapid construction of a secure collaboration environ-ment from its specification.We present a role-based model for specifying a collaboration environment and describe the security architecture of a middleware to construct the target environment from these specifications.Only few systems, such as COCA[12]and DCWPL[3],have taken this kind of approach of building a collaboration environment by cou-pling its high level specifications with a middleware.In con-trast to our work,these systems do not have a security model for supporting meta-policies for role management,discre-tionary access control for an object,and active security poli-cies like dynamic“separation of duty”constraints.Another limitation of these systems is that all user nodes are trusted. Our approach sharply contrasts with the commonly used ap-proaches for building computer based collaboration systems. In the past,a large number of collaboration systems have been built by extending a single-user application to multiuser shared execution model[10].Another commonly used ap-proach is to build an environment by composition of objects (such as JavaBeans)or library modules[1].Usually,such constructions are not driven by any formal model for secu-rity and coordination requirements.There is also WfMC (Workflow Management Coalition)effort to develop speci-fication languages for enterprise-wide workflow systems,but presently these efforts are far from any practical realization.The important contributions of this paper are as follows: Identification of the important security requirements in role-based collaboration systems and development of a speci-fication model that supports expression of these require-ments for CSCW applications.Trust relationships among various entities in the application can be expressed to de-termine which users can be trusted to manage an activity. This specification model also supports definition of nested activities that can be created dynamically.Design of a policy-driven middleware and its runtime struc-tures for securely managing activities,roles,and objects in a CSCW application.This requires derivation of policy modules from the specifications and their secure distribu-tion by the the runtime system.Protocols for secure interactions among users,role man-agers,and object managers.These protocols support dif-ferent paradigms of interactions between a user and shared objects.The following section presents our model of role-based col-laboration systems,which is followed by the section identi-fying the important security and coordination requirements in this model.Next,we present our specification model.The section titled“Middleware Execution Environment and Ser-vices”presents the details of how policy based components are created and orchestrated by the middleware to manage activities in a collaboration.Finally,we present the related work and conclusions.COLLABORATION MODELIn our collaboration model,an activity is an abstraction of a shared task.An activity defines how a group of users coop-erate towards some common objectives by performing their individual tasks on a set of shared objects.It represents a pro-tection domain and a scope for the roles,objects,and privi-leges in a collaboration.In an activity,users are represented by their roles,and roles within an activity are assigned priv-ileges to perform certain tasks.We term these role specific tasks as operations.An operation can be method invocations on shared objects,synchronization actions,or activity man-agement actions.Besides the application-defined roles in an activity,there are several administrative roles or meta-roles, like Creator and Owner of an activity.An activity can be structured hierarchically,consisting of multiple nested con-current activities.An activity template specifies a generic collaboration pattern among a set of roles using some shared objects.Activities are instantiated from templates.Any number of instances of a template can be dynamically and concurrently created.In a collaboration environment,users may be distributed over a network,and they may be associated with different admin-istrative domains.In a typical situation,a user participates in a collaboration by joining a role in an activity.A role op-eration can result in a sequence of interactions between the invoker and a set of shared objects.This represents a session in the context of that role operation.Our model assumes that there can be different interaction mechanisms like RMI or cached objects.REQUIREMENTS FOR SECURE COLLABORATIONA collaboration system is required to provide services to sup-port coordination and communication among users,manage-ment of shared objects,and enforcement of security policies. The traditional concerns of confidentiality and integrity of shared data are naturally present in collaboration systems. However,access rights,privileges,and ownership of objects may change in collaborative environments as activities progress. Privacy can also become an issue when one may need to hide the identity of one participant from another.In such cases, the presence of a participant may only be visible through his/her role or a pseudonym in a role but not by name.We identify here several important security requirements for col-laboration systems,which need to be supported by our role based specification model and the runtime environment. Separation of DutiesTo eliminate conflict-of-interest,the principle of“separation of duties”requires that an individual should not be allowed to perform all critical functions in a business transaction.We require that the specification model supports the following kinds of constraints as identified in[15,13].The notion of static separation of duty requires that two given roles should never be assigned to the same person or,in some cases,to persons related to each other.Another example in this cat-egory is user-user conflict,which disallows two particular users to be assigned to the same role.Similarly,user-role conflict specifies that certain users should never be assigned to a given role.The concept of dynamic separation of duty re-quires that two given roles cannot be concurrently activated by the same person.In object based separation of duty,a user may not access the same object through two different roles.The operational separation of duty disallows a single participant in a role from performing all operations related toa business transaction.Role Admission and Activation ConstraintsThe security policies determine who should be admitted ina role,when a role should be activated or deactivated,how many members should be present in a role,or which roles a user is allowed to join or activate concurrently.Role admis-sion and activation constraints are motivated by three impor-tant requirements of a dynamic collaboration environment: user authorization,role participants’coordination,and sepa-ration of duties.Role admission constraints are required to specify the condi-tions that need to be satisfied before a user can join a role. These constraints can be based on:a list of users allowed to join a role,a list of those who should never be admitted, previous qualifications,role membership cardinality,or oc-currence of certain events.Role activation constraints are conditions that have to be sat-isfied when a participant performs a role operation.When a user is simultaneously admitted to multiple roles,there are various models for the set of privileges to be given to that user.The obvious option is that the user acquires the union of all the privileges.However,in some cases the roles may conflict,and the user’s privileges may need to be reduced for “separation of duties”.Conversely,in some cases a user may be required to be present in multiple roles to be able to in-voke some role operation–this we call“role coupling”.One way to express these requirements is through activation con-straints.Multiple User Participation in a RoleCoordination between participants in different roles within an activity is referred to as inter-role coordination,which is mostly supported in role based coordination systems[12,3]. However,intra-role coordination is required when multiple users in a role need to coordinate among themselves.Intra-role coordination can be based on independent or coop-erative models of role operation execution by a participant. In independent participation,a role specific task responsibil-ity is assumed individually by a participant,irrespective of the presence of the other participants.For example,every participant in the conference reviewer role has to indepen-dently write a review.In this model,a participant can have an independent workspace of private objects,and these ob-jects may be made public at later coordination points.On the other hand,when the participants in a role are assum-ing task responsibilities cooperatively,they need to coordi-nate among themselves.For example,in a hospital patient ward,several nurses may be present in the role of nurse-on-duty.However,some medical procedure on a patient may be needed to be performed only once by any of the mem-bers.Another type of cooperation may require a task to be performed jointly in a coordinated manner by all of the par-ticipants of a role,like jointly opening a bank vault.More-over,in some collaboration environments there may be no coordination among user activities,e.g.in an unrestricted whiteboard sharing.Dynamic Access Control PoliciesAccess control policies may depend on the runtime context of a collaboration environment.For example,only during a specified period of time,certain operations may be per-formed.History based access control policies,like various “separation of duties”constraints,fall into this category.The privileges assigned to a user in a role may change with time due to the actions executed by other participants.Sometimes permissions may change due to the user’s own actions,such as making afinal agreement on a document,after which the creator of the document may not have the right to modify it. In such cases,dynamic security policies are required,which depend on execution states of a collaboration.Dynamic ac-cess control requirements are addressed by Dewan and Shen [4]with a primary focus on shared GUI based co-editing ap-plications.Moreover,in a collaboration environment,objects may move from one object server to another or from one activity to an-other,possibly across administrative domains.In such cases, security requirements may change based on the object’s lo-cation,and access control policies may need to be updated at runtime.Meta-level Security PoliciesAn activity requires many administrative security policies: who can define new activities or instantiate an activity;dur-ing the lifetime of an activity,who can change various poli-cies and enforce additional constraints on shared objects.These meta level administrative policies need to be specified based on meta roles,such as Creator and Owner for various entities like activities,roles,and objects.Policies need to be speci-fied on who can join or leave these meta roles.Management responsibilities of these meta roles may need to be delegated to different entities for runtime administration.System level Security RequirementsDistributed Trust Management:In collaboration systems, activities and participants are inherently distributed.An ac-tivity may have participants from different administrative do-mains.In such a case,a single domain may not be trusted to manage all the activities.In a distributed collaboration,all users’nodes may not be equally trusted to maintain shared objects or enforce coordination and security policies.The runtime system needs to enforce a trust model among these distributed nodes.Managing the activities at a globally trusted server has the pitfalls of single point of failure and single point of attack,and may not scale well for large collabora-tion environments.System Integrity:All interactions between the users,roles and shared objects must be authenticated to ensure integrity. For authentication,a secure name service needs to uniquely identify all the entities of the runtime middleware.If pseudo-nyms are used to conceal a user’s identity,the name service needs to securely map pseudonyms to the user.Secure Distribution of Policies:Management services are needed for enforcing various policies like role admission and activation,activity creation and distribution,object access control and storage,and user-object interaction.These poli-cies must be enforced at trusted sites,and need to be securely distributed to these sites.Secure Event Service To enforce coordination and dynamic security policies,user actions may need to be communicated to participating entities.All events generated by these ac-tions need to be distributed securely and only to authorized entities.The event service needs to ensure integrity and con-fidentiality of events for secure collaboration.Object Storage and Access Control:Shared objects must be located at trusted and reliable sites.As new activities are created access control policies for objects may need to be updated by authorized entities.If access control depends on coordination constraints,the object server may need to verify object method preconditions.SPECIFICATION MODELWe have devised an XML schema,which facilitates collabo-ration specifications.Here,rather than using XML,we use a notation that is simple to read and conceptually easy to fol-low.We use an example to illustrate our specification model.Figure 1shows an example of a course activity,named chem-istry ,an instance of the Course template.This course activ-ity contains three roles:Instructor ,Assistant ,and Student .It also has a nested midterm examination activity,an instance of the Examination activity template.Members of the In-structor and the Assistant roles are admitted to the Grader role in the midterm activity.A grader can perform opera-tions on the GradeSheet object in the chemistry course as well as the objects in the midterm examination.Members of the Student role of the chemistry course join the Exami-nee role in the midterm examination.Each examinee creates an instance of the ExamSession activity template to take the exam.An exam-session activity contains the roles Candidate and Checker .Only the examinee creating this activity can be admitted to the Candidate role.References to two objects –ExamPaper and AnswerBook –are passed as parameters to an exam session activity.A single ExamPaper object is shared by all the sessions.On the other hand,a new AnswerBook object is created for each exam session.Static Role AssignmentLegend: Dynamic Role Assignment Parameter ObjectsFigure 1:Hierarchical Structuring of Collaborative Ac-tivitiesAn activity template is specified in terms of roles,opera-tions,and object types.A skeleton of the Course activity template is shown in Figure 2.The entities encapsulated in the scope of an activity template can be referenced by a fully qualified name.In the Course template used in the example of Figure 1,the Assistant role has the fully qualified name Course.Assistant .When an instance chemistry of the Coursetemplate is created,it is named Course.chemistry ,and the As-sistant role in that instance is named Course.chemistry.Assistant .In the specification model,within an activity,one can refer to its current instance using the pseudo variable thisActivity ,and its creator using parentActivity .Similarly,pseudo vari-ables thisRole and thisUser are defined.ACTIVITY_TEMPLATE Course (ASSIGNED_ROLES Assistant,Instructor,Student){.................ACTIVITY_TEMPLATE Examination (OWNER Instructor,ASSIGNED_ROLES Examiner){OBJECT_TYPE ExamPaper ........OBJECT_TYPE AnswerBook .........ROLE Examiner {....}ROLE Examinee (ASSIGN parentActivity.Student){....}ROLE Grader (ASSIGN parentActivity.Assistant,parentActivity.Instructor){....}ACTIVITY_TEMPLATEExamSession ............}}Figure 2:Skeleton Specification of Course Activity T emplateMeta Policy SpecificationWhen an activity is instantiated,the user initiating that activ-ity becomes a member of the Creator role for that instance.The creator may not always be trusted for the management of the activity.The Owner role,therefore,specifies which users can manage the activity instance and its nested entities.The membership rules for the Owner role are as follows:The template specification may indicate which user or role can be the owner of an instance of that template.For ex-ample,in Figure 2,the Instructor role is specified as the owner of an Examination activity.The Creator role can be specified as the owner.If not explicitly specified,the owner of the parent activity becomes the owner of the new child activity.An activity template may specify a termination condition.When this condition is satisfied for an instance of the tem-plate,nested entities within it’s scope can be garbage collected.Event SpecificationEvents and event counters are used in our model for specify-ing coordination and dynamic security policies based on the model presented in [14].Events correspond to instantiation of activities,execution of role operations,admission of users in roles etc.Related to each role operation are two types of events:start,and finish .For example,role-name.op.start or role-name.op.finish .For a role,we have event types defined for join ,leave ,admit ,and remove operations.For each activ-ity definition,we have start and finish events.In the specification model,multiple occurrences of a given event type —such as multiple executions of an operation —are represented by a list.The expression (eventName)returns the list including all the instances of this type of event.This list can be indexed using the notation (eventName)[i]to referto the i’th event in the list.We provide a count operator#on lists.One can also specify a derived event type byfiltering an event list based on its attributes.For example,for a role operation execution,we can define afilter based on invoker id,such as opName.start(invoker=John).Object SpecificationShared objects are represented in our specification model only in terms of their types and method signatures.The specifica-tions of ExamPaper and AnswerBook object types are shown below.A specification for an object includes a type name to facilitate parameter bindings of operations in roles,a code-base to load the class of the object,and method signatures. OBJECT_TYPE ExamPaper(CODEBASE=http://codeserver){ METHOD setQuestions{PARAM PaperType}METHOD readPaper{RETURN PaperType}}OBJECT_TYPE AnswerBook(CODEBASE=http://codeserver){ METHOD writeAnswer{PARAM AnswerType}METHOD setGrade{PARAM GradeType}}The object level access control specification is derived from the role’s privileges on objects.After an object is created the owner can specify additional object level access control.Role SpecificationA role is defined in the scope of an activity and can manipu-late the objects in that activity.A role specification includes role name,assigned roles if any,role admission and activa-tion constraints,and role operations with their preconditions. In the specification,a boolean function member(role,user) checks if a participant is present in a role,and members(role) returns the role participant list.The count of the participants in a role is#(members(role)).Role Admission Constraints:Role admission constraints must be true when a user is admitted to a role.The Assistant role in Figure1has several admission constraints.The maximum member count for this role is two;only a staff can be an as-sistant;a student cannot be an assistant;only after a user is assigned to the Instructor role,users can be admitted to the Assistant role;and lastly,users B and C both cannot be as-signed to this role.The specification of admission constraints of the Assistant role is shown below.#members(thisRole)2&member(thisUser,parentActivity.Staff)&!member(thisUser,Student)&#(Instructor.admit)0&!(member(B,thisRole)member(C,thisRole))Role Activation Constraints:Activation constraints of a role are enforced for each role operation invocation.A dynamic “separation of duty”constraint,like a user should not activate two roles at the same time can be specified as part of role acti-vation constraints.In the following example,we present sev-eral activation constraints for an admission committee mem-ber role of a Computer Engineering department.Such a role may specify a minimum and a maximum number of partici-pants to be present.Moreover,a constraint can be that at least one member from both Computer Science and the Electrical Engineering must be present during role activities.#members(thisRole)2&#members(thisRole)5&(#(members(thisRole)members(EE.Professor))0)&(#(members(thisRole)members(CS.Professor))0)Operation Specification:An operation specification may in-clude a precondition and an action which invokes predefined methods of some objects in the shared workspace.The pre-condition must be true when the operation is invoked.A key-word new is reserved for specifying creation of an object or an activity.Follows an example of an operation specification of the Examiner role in the Examination activity.The opera-tion SetPaper can be performed only once as specified by the precondition.This operation results in creation of an object exam of type ExamPaper and an invocation of the setQues-tions method of this object.ROLE ExaminerOPERATION SetPaperPRECONDITION#(SetPaper.start)=0ACTION exam=new OBJECT(ExamPaper)exam.setQuestions(data)Preconditions enable us to specifyfine grain“separation of duty”policies,like the object based separation of duty and the operational separation of duty.For example,in an office system,a manager may prepare an invoice and approve an in-voice,but should not be able to approve his/her own invoice. This specification is shown below.OPERATION ApproveInvoicePRECONDITION#(PrepareInvoice.finish(invoker=thisUser))=0Role Admission on Activity Creation:A participant of a role cannot perform operations of a nested child activity if not admitted to a role in the nested activity and vice versa.Our specification model supports two mechanisms to admit par-ticipants in a parent activity role to a child activity role.One mechanism is static role assignment,in which,using the AS-SIGN construct,all the members of specified roles in the par-ent activity become members of a role in the child activity.In Figure2,using this mechanism,all members of the Student role in the parent activity are admitted to the Examinee role, subject to the Examinee role’s admission constraints.Re-moval of a participant from the assigned role(i.e.the role in the parent activity),also implies removal from the role in the child activity.A participant in the assigned roles can execute role operations in the nested child activity.The second mechanism is dynamic role assignment,in which role admission is specified at the time of activity instantia-tion.The template definition uses the ASSIGNED ROLEStag to specify which roles must by dynamically assigned at instantiation,as specified for the Candidate role in Figure3. Given below is the specification of the StartExam operation of the Examinee role in the Examination activity template. ROLE Examinee(ASSIGN parentActivity.Student)OPERATION StartExamPRECONDITION#(Examiner.SetPaper.finish)=1&#(StartExam.start(invoker=thisUser))=0 ACTION ans=new OBJECT(AnswerBook);act=new ACTIVITY ExamSession((exam,ans),Candidate=thisUser)When an examinee invokes this operation,an instance of the ExamSession template is created and the participant creating the instance is dynamically assigned to the Candidate role. An ExamPaper and an AnswerBook object are passed to this instance of the ExamSession activity.Activity SpecificationFigure3shows an example of an activity template specifi-cation.The examinee creating an instance of the ExamSes-sion template is admitted to the Creator role for that exam-session.The Grader role is specified as the owner of an Ex-amSession activity.ACTIVITY_TEMPLATE 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)&#members(thisActivity.Creator)=1&member(thisActivity.Creator,thisUser)&#members(thisRole)<1ACTIVATION_CONSTRAINTSdate>DATE(Mar,20,2002,12:00)&date<DATE(Mar,20,2002,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)}}}Figure3:Specification of Collaborative ExamSessionActivity T emplateIn the template,a role coupling constraint is specified,requir-ing that a participant admitted to the Candidate role must be in the Creator role of that activity instance.This is achieved using admission constraints for the Candidate role.It ensures that other examinees cannot interfere with a particular candi-date’s exam session.Additionally,activation constraints for the Candidate role ensure that students can take the exam only during a specified period of time.The precondition for the Checker role’s Grade operation ensures that a checker can grade an answer book only after it has been submitted by the candidate.The termination condition specifies that an instance of the ExamSession activity is terminated once the Checker completes the Grade operation.MIDDLEWARE EXECUTION ENVIRONMENT AND SERVICES To construct the runtime environment for a CSCW system from its specifications,the middleware is required to support distributed management of activities.This requires definition of a distributed execution model for activities and runtime structures and protocols for:Incorporation of a trust model in selecting nodes for man-aging roles and objects of an activity.Policy-driven generic managers for roles,objects,and ac-tivities.Derivation of policies and their secure binding at runtime with generic managers.Secure distribution of events for coordination.Secure interactions among users,role managers,and object managers.Basic services for naming,key certificates,and authentica-tion.Our middleware is implemented using a Java-based mobile object programming framework,which provides us basic ser-vices for naming,public key distribution,and authentication. The authentication protocol is based on challenge-response using digital signatures.Moreover,it provides an additional capability of supporting user-object interactions using mo-bile objects in addition to Java RMI.Object ServersIn our system,shared objects are stored by object servers, which provide secure access protocols.For each object,a policy-driven manager object is created.An object is ac-cessed through its manager.For this,a manager implements the same interface as that of the object,but with some addi-tional mechanisms to support authentication.Based on the security and coordination requirements of a collaboration, our system derives appropriate policy modules,which are used by the object managers for access control.The object managers in our system support both role-based as well as discretionary access control.When existing objects of an ac-tivity are passed to a nested child activity,the access control policies of these objects need to be updated at runtime.This binding of new policies is discussed later in the sub-section on policy distribution.Interaction ModelsTo perform a collaboration task,a user invokes a role oper-ation.The action associated with the operation may invoke methods of some shared objects.When a user invokes a role operation,the role manager authenticates the user,verifies user’s membership in the role,checks that the preconditions for the operation are satisfied,and then executes the action.。