Effective Information Sharing And Workflow Of Delegation Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

A global education system, as a key area in future IT, has fostered developers to provide various learning systems with low cost. Many advances in e-learning systems have been implemented, the needs for effective information sharing in a secure manner have to date been largely ignored, especially for virtual university collaborative environments. A rule-based framework to identify and address issues of sharing in virtual university environments through role-based access control (RBAC) management. The framework includes a role-based group delegation granting model, group delegation revocation model, authorization granting, and authorization revocations. In organization workflow the main threat is of access control. The Role based access control is one of the best suitable access control model one can think of. The paper discusses the control factors and role hierarchies in workflow and brings a new model of RBAC. This paper also over comes the conflicts and proves that the system is safe by applying the new model to the workflow.

Keywords: E-learning, RBAC, role-based delegation, Control factors, revocation.


E-learning has the potential to become a lower cost and efficient education tool, and one of the key e-commerce applications with a rapidly growing commercial market in the near future [3]. Human interaction administration, as a shortcoming of e-learning, is a critical component of the e-learning market, especially in virtual university environments. There are situations in which learning resources cannot be updated and delivered due to insufficient collaborative management arrangements between partners of virtual universities. Virtual universities are becoming strongly networked and fundamental changes in the organization of education are occurring. The collaboration within a virtual university is found to be a beneficial and enjoyable component of offering a course, but a source of frustration at the same time. Students' evaluations show that the perceived best and worst aspect of the course is communications between and within each partner in the virtual university [4]. Students are sincerely motivated by the expertise of lecturers but obviously dissatisfied with their collaborations regarding access and updating study materials. The major problem is that students find it difficult to coordinate their schedules at their own university when a study material provided by the university is postponed.

Therefore, effective and efficient communication with distant collaborators is required for the collaboration between and within a virtual university environment. The paper aims to develop a policy-based framework for information sharing in a distributed collaborative virtual university environment with role-based delegation. The inclusion of role-based delegation and revocation allows users themselves to delegate role authorities to others to process some authorized functions and later remove those authorities.

The National Institute of Standards and Technology proposed a role-based access control (RBAC) prototype and published a formal model [7]. RBAC enables managing and enforcing security in large-scale and enterprise-wide systems and its applications depend on specific system requirements. In RBAC models, permissions are associated with roles, users are assigned to appropriate roles, and users acquire permissions through roles. Users can be easily reassigned from one role to another. Roles can be granted additional permissions and permissions can be easily revoked from roles as needed. An IT administrator (security officer) has to assign a role to the delegated lecturer if the role is required to be delegated to the lecturer. Such a model significantly increases the management efforts in a collaborative virtual university environment because of the dynamic of delegations and the continuous involvement from IT administrators. This paper provides control factors and role hierarchies in workflow and a new RBAC model.

The paper is organized as follows: Part 2 and Part 3 explains motivation and describes the proposed system of this paper. Part 4 explains control factors in workflow and new RBAC models. Part 5 details the conclusion and future work.


In the RBAC framework is extended to include role hierarchies. The model allows the occupants of senior roles to inherit all the positive access rights of their juniors, and conversely ensures that the occupants of junior positions inherit any prohibitions that apply to their seniors. The extended models doesn't discuss about the fitness of the models for the workflow as there are other factors influencing in the workflow, as it is implementation of basic or extended RBAC models for workflow is dreadful. Work In [5], Vieira and Rito-Silva propose the Work Analysis Refinement Modeling (WARM) methodology, a first approach to derive workflow process definitions by using business process models. This model was having serious drawback of concentrating only on the functional aspect of workflow and neglected the non-functional requirement mainly access control. In the paper Workflow Access Control from a Business Perspective [6], the basic role based access model is taken for the access control in workflow. This model again doesn't discuss about the other affecting factors in workflow like delegation, decentralization and review. This paper discusses the control factors and role hierarchies in workflow and brings a new model of RBAC. This paper also over comes the conflicts and proves that the system is safe by applying the new model to the workflow.


The existing paper has discussed a role-based delegation model for virtual university learning environments and its implementation with XML [1]. They have analyzed a delegating framework including delegating authorization and revocation with constraints and extended it to include group-based delegation. The revocation dimensions and delegating revocations are discussed. Furthermore, role assignment changes, as the impact result of original role delegating revocation, are described. To provide a practical solution for role-based group delegations, they have analyzed role hierarchies, the relationship of senior and junior roles, group-based delegation, group delegation authorization with prerequisite conditions, and revocation authorization.

The work in this paper has significantly extended previous work in several aspects, for example the workflow analysis of delegation processes in the role-based delegation model at a virtual university. Finally, we propose the implementation of delegation can be adopted in Role Based Access Control model, in any other access control model the implementation becomes very difficult. The proposed new model for the RBAC allows the inclusion of delegation control factor. The efficient design of policies makes it stronger and provides the easy of work with safety. The policy base and server accommodates the task assignment relationship.



The general key components like users, roles, operations and objects are used for access control model and the relations are also quite well defined. The main relations defined in basic RBAC model are user assignment, permission assignments. In case of workflow the other factors also affect the access control. The control factors [2] are discussed below.

4.1.1. Decentralization

In a very large organization it becomes impossible for a single person to carry out all the responsibilities assigned to him but in turn there is no option of skipping from his responsibilities. In such scenario the concept of decentralization comes into picture. The senior role will distribute the work responsibility to the some of junior roles. Then the junior roles will have full authority to carry out those actions. Such works are subjected to the review.

4.1.2. Delegation

The decentralization goes hand in hand with decentralization. The senior role, distributes the responsibility to the junior roles and making the junior role equally responsible for the completion of the assigned responsibility by applying the supervision or through review. In the access control scenario the junior role accepts the rights the rights of senior role temporarily and performs the responsibility assigned by the senior role. While assigning the permissions the senior role will allow the permission for the task to be performed by the junior role but care is taken to block the other activities, which can be performed by the newly assigned rights and they are the responsibilities of the senior role.

4.1.3. Supervision and Review

There is of course a danger that delegates will not carry out their duties properly. For decentralization to work satisfactorily, an additional control principle is needed: supervision and review. This control principle requires one person's actions to be reviewed post hoc by another person, typically their superior in the position hierarchy. The superior usually does not exert direct control over the supervisee at the time that the actions are taken. Supervision is an activity that is carried out on someone by someone else in the immediately superior position. It consists of many activities including monitoring, appraisal, advising, praising and criticize, and outside the scope of any present-day access control system.


4.2.1 Limitations of Existing model

The core RBAC model or any extension models are having the components user, roles, operations, objects and sessions with two relations defined as User Assignment (UA) and Permission Assignment (PA) [8]

The key points to be noted with Core Role Based Access Control model are

1. Set of users exists in organization

2. The roles are specified and these roles are in partial order of hierarchy

3. Each user is mapped to one or more role (many to many relationship) with user→ Role (UA) assignment relation








FIGURE 4.2 : Core RBAC Model

4. Each role is authorized with permissions to objects through operations on objects with Role Permission (PA) assignment relationship from the basic model it is evident that role performing the action/task (if authorized) is having the privileges on the objects, that were assigned to role. When considered the delegation control factor, senior role will delegate the task to one of it junior role. i,e Senior role allots the specific grants to objects and assigns to a temporary role (but this role exists in hierarchy as junior role) to perform the task. If any of the control factors are introduced in the basic RBAC model, it fails, as there is no component for task/action with associated relationship exists in basic model. This leads model to fail miserably.

4.2.2 New Model

The new component TASKS is introduced in this model so that the delegation of task is possible













FIGURE 4.2.2 : Proposed New RBAC Model

from one role (senior role) to another (junior role). When 'task' is accommodated as component in the model, one assignment relationship also get introduced as TA. The definition of basic components and relationships of new RBAC model are as defined below.

USERS, ROLES, OPS, and OBS, TASKS (users, roles, operations, objects and TASKS respectively).

UA subset of USERS X ROLES, a many-to-many mapping user-to-role assignment relation.

assigned_users: (r: ROLES) → 2 USERS, the mapping of role r onto a set of users. Formally: assigned users(r) = { u Є USERS | (u, r) Є UA}.

PRMS = 2(OPS X OBS), the set of permissions.

PA subset of PRMS X ROLES, a many-to-many mapping permission-to-role assignment relation.

assigned_permissions(r: ROLES) → 2PRMS, the mapping of role r onto a set of permissions. Formally: assigned permissions(r) = {p Є PRMS | (p, r) Є PA}

Ob (p: PRMS) → {op subset of OPS}, the permission-to-operation mapping, which gives the set of operations associated with permission p.

Ob (p: PRMS) → {ob subset of OBS}, the permission-to-object mapping, which gives the set of objects associated with permission p.

SESSIONS, the set of sessions.

user_sessions (u: USERS) → 2 SESSIONS, the mapping of user u onto a set of sessions.

session_ roles (s: SESSIONS) → 2ROLES, the mapping of session s onto a set of roles.

Formally: session roles (si) subset of { r Є ROLES | (session users (si ), r) Є UA}.

avail_session perms(s:SESSIONS) → 2PRMS, the permissions available to a user in a session U assigned permissions(r).

r Є session roles(s)

TASKS=2(OPS X OBS X ROLES), the set of tasks

task_assignment subset of TASKS X ROLES, a many to many mapping of task-to-roles relationship

assigned_tasks(r: ROLES) → 2(TASKS) , the mapping of role r onto set of tasks. Formally assigned _tasks → {t Є TASKS | (t,r) Є TA }

4.2.3 Basics of New RBAC Model

The new task-assignment relationship needs the powerful policy database, which verifies the authentication and authorization for the delegation of tasks from one role to another. The policy base maintains the information about Role, Objects, Tasks, Permissions and Attributes of objects. The following constraints have to be taken care by the policy base.


If only Objects are not available for role Ri (to whom the task is delegated) to perform the task ti then,

Rj delegates ti → Ri (Role Rj delegates the Task ti to Ri)

Task ti involves extra objects {Ok, Ok+1, .. Ok+i}

Then PA relation assigns the objects to Role Ri

Ri -> {objects belong to Ri} + {Ok, Ok+1, .. Ok+i}

Ri is inferior and authorized to perform task therefore the system is safe.


When Task is delegated already all objects are accessible by role Ri -Then no extra objects should be made available

Ri objects →{Oi,Oi+1…Oi+k}

Ri Task delegated ti → {Oi, Oi+1…Oi+k}

No extra objects made available. System is safe but no guarantee system will run smooth that all objects are having permissions required by ti

If Ri Task delegated Ti objects available → {Oi,Oi+1…Oi+k}

(Oi Verify pi associated with Task Ti)

if pi to be granted then

store the pi's of oi for Ri

grant new pi's = {original pi of oi } + { New pi for oi which tasks needs}

Now the system is live and safe.


If not all objects for task Ti are available and not all permissions are associated with Objects

(i) For the first part Rule 1 can be applied (i.e. allotting the objects) here system is safe but no guarantee of liveness as permissions are not granted

(ii) For the second part of this scenario apply Rule 2 for all objects the system live and safe.


If Objects are made available according to ti Task requirement but not all the attributes of objects are made available.

Create the new object with these attributes without violating the constraints on object assign to the role Ri once Supervision or review takes place the Ri (who delegated task) is

append / updated the original Object.

4.2.4 Design of New Model

In the new proposed model the essential components needed are policy base and a server. The server will authenticate and authorize the delegation of task and policy base will evaluate the constraints on the tasks with respect to objects, permissions and the roles. The server requests for the data in the policy base, based on the request it got from role to delegation of work to other role. The main validations carried out by server is to verify whether the role requested for delegation of work is superior then to whom the work to be delegated. The server also validates the information about the objects, permissions to be associated to task after delegation. The Policy base provides the information to the server about the objects and permissions needed by the tasks. The Figure illustrates the functionality of server and the policy base.






FIGURE 4.2.4 : Delegation Server and Policy base


The proposed paper aimed to workflow analysis of delegation processes in the role-based delegation model at a virtual university. The implementation of delegation can be adopted in Role Based Access Control model, in any other access control model the implementation becomes very difficult. The proposed new model for the RBAC allows the inclusion of delegation control factor. The efficient design of policies makes it stronger and provides the easy of work with safety. The policy base and server accommodates the task assignment relationship.

The idea of the delegation in RBAC can also be enhanced to the other two control factors,

supervision and the review. The same policy base and servers can be strengthened to incorporate these two control factors. The new rules also can be formed to make the workflow system to operate in safe and live conditions.