Project topics and materials
Get Complete Project Material File(s) Now! »
Role-based access control model
The RBAC model (Role Based Access Control, see [Sandhu et al. 1996]) proposes to structure the expression of authorization policy around the concept of role. A role is an organizational concept: roles are assigned to users according to the function that the user plays in the organization. The basic principle of the RBAC model is to consider that permissions are directly associated with roles. In RBAC, roles receive authorizations to perform actions on objects. As IBAC, R-BAC model considers only positive authorizations (permissions) and therefore it is assumed that the policy is closed. Furthermore, the RBAC model introduces the concept of session. To perform an action on an object, a user must first create a session and in this session, activates a role which has the permission to perform this action on this object. If such a role exists and the user was assigned to this role, then this user will have the permission to perform this action on this object once this role is activated. When a new subject is created in the IS, it is sufficient to assign roles to this subject, thus this subject can access to the IS according to the permissions granted to this set of roles. Therefore, compared to the IBAC model, the management of authorization policy is simplified since there is no need to update this policy every time a new subject is created.
In general, any set of roles can be assigned to a user, and a user can activate in a session any subset of roles which was assigned to him/her. The RBAC model introduces the notion of constraint to specify authorization policies including more restrictive situations. Thus, a static separation constraint specifies that certain roles (e.g., nurse and physician) can not be assigned to a user simultaneously. A dynamic separation constraint specifies that, although some roles can be assigned to a user (for example liberal doctor and surgeon) these roles can not be active simultaneously in the same session.
In RBAC, it is also possible to organize roles hierarchically. Roles inherit permissions from other roles that are hierarchically below them. When a role r1 is hierarchically superior to a role r2, we say that r1 is a senior role of r2. Today the RBAC model is a standard [Ferraiolo et al. 2001]. Many IS implement this standard, for example Unix Solaris from version 8 or the API Authorization Manager RBAC of Windows Server 2003.
Task based access control model
In IBAC and RBAC models, actions correspond generally to basic commands, such as reading the contents of an object or writing in an object. In recent applications, there is a need to control the execution of composite actions, called tasks or activities. The need to control composite activities is particularly present in Workflow applications [Atluri and Huang 1996].
The TBAC model (Task Based Access Control, see [Thomas and Sandhu 1998]) is the first model which introduced the concept of task. Then, other models were developed to monitor the implementation of activities in a workflow (see [Bertino et al. 1999, Atluri et al. 2000]). In particular, the user must obtain permission just in time when there is a need to continue the execution of the activity.
View based access control model
The RBAC and TBAC models introduced, respectively, the concepts of role and task in order to structure subjects and actions. To facilitate the expression and the management of authorization policy, there is also a need for a concept which enables to structure objects.
Among the access control models proposing a structuration of objects, we quote the security model proposed by SQL for relational databases. The expression of a security policy in SQL is based on the concept of view. We denote by VBAC (View Based Access Control) this kind of access control models. Intuitively, in a relational database, a view is the result of an SQL query which was denoted by a given name. This concept of view is then used to structure the expression of authorization policy using GRANT statements (which allows granting a new permission to a user) and REVOKE (which allows deleting a permission that a user had). Thus, a view is an effective way to provide an access to all objects in the view. Note that these objects are sometimes virtual insofar as a SQL view is not materialized. SQL/3 [Lentzner 2004], which is the latest evolution of the SQL standard, proposes to extend the VBAC model by combining the concepts of view and role in order to structure objects and subjects. Thus, the VR-BAC model is defined. The concept of view is not limited to relational models. It could also be used in an oper2.2. ating system. Currently, most operating systems propose just the concept of directory in order to structure the expression of authorization policies.
Team-based access control model
In recent applications, it is often necessary to consider several organizations simultaneously. For example, in web services applications, a user of a certain organization may wish to access data belonging to another organization. An organization is a structured entity. For example, a hospital is an organization that is divided into severalsub-organizations: the different departments of the hospital, the various services of these departments, etc. Each organization generally manages its own authorization policy. Some organizations may also be created dynamically depending on the activities that must support the hospital. For example, a health-care team can be created to support a particular patient. This organization could be deleted once the activities were made. Notice that the permissions of a subject not only depend on the role of the subject but also of the structure within which the subject performs its role. This problem was identified in the TMAC model. The TMAC (Team-Based Access Control, see [Thomas 1997]) model introduces the concept of team. In TMAC, permissions are associated with roles as well as teams. The subject’s permissions result from the combination of permissions associated with the roles played by the subject and permissions associated with the team in which the subject is assigned. Various combinations (for example, the union of permissions) are considered. In fact, the TMAC model is incorrect because it introduces two binary relations: role-permission and team-permission. If the team concept is introduced, a ternary relation team-role authorization must be introduced. This is necessary to specify that authorizations do not depend only on role but also on the team in which this role is exercised. Using such a ternary relation, it is easy to specify the fact that the authorizations of the role doctor can change depending on the doctor is in the team of health-care or in the emergency team. This imperfection of the TMAC model has been corrected in the Or-BAC model, which we present latter in this section.
Dynamic and contextual authorization models
In practice, many permissions are not static but depend on contexts. When these contexts hold, the permissions are activated dynamically. This is called contextual authorizations. Permissions may depend on temporal contexts, geographical contexts, or provisional contexts (permission if other actions were previously performed as in the case of a workflow). Other types of contexts may be defined ([Cuppens and Miege 2003]). To represent these contextual authorizations, several access control models based on rules have been proposed (model of type Rule-BAC, see [Jajodia et al. 2001, Bertino et al. 2001]). In these models, an authorization policy is considered as a set of rules of the form condition → permission which specify that a permission can be derived when a certain condition holds. Models of type Rule-BAC are based on first-order logic which is, in general, undecidable.
To deal with this problem, most of these models propose to use Datalog to get a decision procedure in a polynomial time. However rules must be conform to certain syntactic restrictions ([Ullman 1988]). Compared to the models presented in the previous sections, Rule-BAC models have a greater expressiveness as it is possible to specify contextual authorizations. However,there is a lack in the structuration of the authorization policy which calls for the introduction of the concepts of role, activity, view and organization.
Table of contents :
1 Introduction
1.1 Motivation and background
1.2 Contributions
1.3 Outline of the dissertation
2 Preliminaries and State of the Art
2.1 Introduction
2.2 Access control models
2.2.1 Identity based access control model
2.2.2 Role-based access control model
2.2.3 Task based access control model
2.2.4 View based access control model
2.2.5 Team-based access control model
2.2.6 Dynamic and contextual authorization models
2.2.7 Organization based access control model
2.3 Usage control models
2.3.1 Policy rule management including provisions and obligations
2.3.2 Privacy policies in access control model
2.3.3 The UCONABC model
2.3.4 Obligation specification language
2.3.5 Enforcement and management of obligation policies
2.4 Managing policy conflicts
2.4.1 Access control policy analysis techniques
2.4.2 Obligation policies analysis techniques
2.5 Situation calculus
2.5.1 The language
2.5.2 fundamental axioms
2.6 Conclusions
3 Specification of Obligation with Deadline Policies
3.1 Introduction
3.2 Motivation example
3.2.1 Impact of deadlines to complete medical records on the availability of information
3.2.2 Rules regarding the completion of the patient’s medical record .
3.3 Security policy specification
3.3.1 Specification using the deontic logic of actions
3.3.2 Example of rule specification
3.4 Actual norm derivation and violation detection
3.4.1 The semantic of actual permission
3.4.2 The semantic of active obligation
3.4.3 Fulfillment and violation detection
3.4.4 How the situation calculus helps us by resolving the frame problem
3.5 Conclusion and Contribution
4 Specifying and Enforcing Constraints Policy in a Dynamic World
4.1 Introduction
4.2 Specifying constraints
4.2.1 Example
4.3 Enforcing constraints
4.3.1 Enforcing ahistorical constraints
4.3.2 Rewrite historical constraints in the form of simple state constraint
4.3.3 Enforcing the historical constraints
4.3.4 Defining and characterizing a secure system
4.3.5 Example
4.3.6 Expressive power
4.4 Related work
4.5 Conclusions and contribution
5 Conflict Detection in Obligation with Deadline Policies
5.1 Introduction
5.2 Motivation example
5.3 Conflict detection
5.3.1 Conflict in feasibility of obligations
5.3.2 Conflict between permission and obligation rules
5.3.3 Conflict detection algorithm
5.4 Implementation
5.5 Related work
5.6 Conclusion and Contribution
6 Enriching Obligation with Deadline Policies with Rights
6.1 Introduction
6.2 Motivation example
6.3 Specification of right rules
6.4 Derivation of effective rights and detection of rights violation
6.4.1 Derivation of effective rights
6.4.2 Violation detection
6.5 Conflicting situations
6.5.1 Conflict in exemplarity of feasibility of obligations
6.5.2 A conflict in feasibility of rights
6.5.3 A conflict between obligations and rights
6.6 Related work and discussion
6.7 Conclusion and contributions
7 Conflict resolution based on delegation and renunciation of right
7.1 Introduction
7.2 Detected conflict and responsibility
7.2.1 Situations where the conflict could have been avoided
7.2.2 Shared and multiple responsibilities
7.3 Possible conflict resolution
7.3.1 Obligation delegation
7.3.2 Renunciation of its own rights
7.3.3 Solvable conflict
7.4 Conclusion and contributions
8 Conclusion and perspectives
8.1 Perspectives
8.1.1 Delegation based on workload assigned to users
8.1.2 Delegation based on user reputation
A Actual norm derivation of the case study described in chapter 3
B Prolog file: ConflictDetection.pl
C Gestion Des Conflits dans les Politiques de Contrôle d’ Usage
List of Publications
List of Figures
