Project topics and materials
Get Complete Project Material File(s) Now! »
Policy rule management including provisions and obligations
The model proposed in [Bettini et al. 2002b] extends rule-based access control models to support provisions and obligations. Provisions denote actions which a subject must perform before access, while obligations are actions which a subject will have to per-form after access. This model makes a distinction between obligations and provisions by associating to each one of them a different set of predicates. The set of required provisions and obligations is calculated beforehand for each atom in the security rules. This set is denoted Global Provisions and Obligations Set (GPOS). Concerning the provision and obligation requirements corresponding to a given access request, they are calculated using the set GPOS, when the request is issued. If these requirements are satisfied, access is granted, otherwise, the user is informed about the provisions and obligations that he must meet to satisfy his/her request.
This framework has been extended later in [Bettini et al. 2002a, Bettini et al. 2003] to support obligations specification and enforcement. Obligation rules have been en-riched by the specification of the set of actions to execute when the obligations are fulfilled. When an obligation is violated, this triggers another obligation and another set of actions should be taken.
Concerning the mechanism of obligation enforcement, the authors propose to set up triggers. When obligations are accepted by users, triggers are derived from the defini-tion of obligations. These triggers will be used to check if the obligations are fulfilled. The derivation of the time when the obligations have to be verified is based on temporal reasoning techniques.
The specification of rules in this model is not uniform. In fact, each rule can specify any number of parameters. This complicates the interpretation of the policy because of the hierarchical definition of obligations.
Privacy policies in access control model
In [Ni et al. 2008], authors defined an obligation model to enable the specification of privacy requirements in access control models. This model introduced repeating and conditional obligations in addition to pre and post obligations.
The number of times that an obligation must be fulfilled is specified through variables in a temporal constraint. The temporal constraint specifies also the time interval in which the obligation must be fulfilled. The distinction between pre-obligation and post-obligation depends on the lower endpoint of this interval. In this model, there is a hierarchical dependency between obligations and permis-sions. In fact, obligations are activated only if a request for access is issued. In addition, the semantic of conditional obligation is not completely formalized. Furthermore, the management and the enforcement of obligations in this model is complicated due to the lack of clarity in how the fulfillment and violation of obligations affects the state of policy.
The U CONABC model
The U CONABC model [Park and Sandhu 2004] is based on three components for us-age control: Authorizations, oBligations and Conditions. The authorization component evaluates conditions related to the subject’s and object’s attributes. Obligations specify actions or operations that must be executed. The environmental conditions are spec-ified through the condition component. The conditions that must be satisfied before access are verified by pre functional predicates. While conditions that must be true in current access are verified by ongoing predicates. Thus, if the pre-functional predicates are true, the access is allowed. When the ongoing functional predicates become false, the ongoing access is revoked. U CONABC enables also the update of subject and object attributes as side effect of usage. This is called attribute mutability.
As pointed out in [Janicke et al. 2007], the lack of obligation monitoring and obligation fulfillment notions in U CONABC explain why this model could fail to express properly a desired requirement. This is certainly the reason why this model does not support obligations which are not related to the usage session. Authors in [Janicke et al. 2007] discussed other limitations of U CONABC as the fact that it does not support conflict detection and resolution techniques.
Obligation specification language
The Obligation Specification Language (OSL) [Hilty et al. 2007] enables the specifi-cation of restrictions on usages and mandatory actions. The language specification is based on typed set theory and First-Order Logic with equality. The semantics is defined over event traces with discrete time steps. The semantics formalize the fact that the trace of events (occurrence of actions) is consistent with the policy.
The OSL model does not formalize how states evolve when events occur. Thus, it is not useful for analysing usage control policies. Furthermore, OSL policies are difficult to specify and interpret.
Enforcement and management of obligation policies
In [Elrakaiby et al. 2012b], the authors present an obligation model based on the con-cepts of Event Condition Action. It supports pre and post-obligations as well as on-going, and continuous obligations. The specification and the enforcement of sanctions for users that violate obligations, and re-compensation for users that fulfill their obli-gations are also supported in this model. To manage conflicts and lack of permissions, they propose to cancel obligations and the delay of obligations.
In contrast, the presented model does not manage accountability [Irwin et al. 2006, Irwin et al. 2008, Pontual et al. 2010a, Pontual et al. 2010b]. In this sense, the au-thors in [Pontual et al. 2011] give means for administrator to find the user responsible for violation. Furthermore, the model manages dependencies between obligations. This enables the administrator to find the obligations that can be affected by the obligations which have not been fulfilled.
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
