Privacy aware Role Based Access Control
Privacy is today a key issue in information technology and has received increasing attention from consumers, companies, researchers, legislators, and governments. Legislative acts in the United States, such as the Health Insurance Portability and Accountability Act (HIPAA) for healthcare and the Gramm Leach Bliley Act (GLBA) for financial institutions, require enterprises to protect the privacy of their customers. Although enterprises have adopted various strategies to protect customer privacy and to communicate their privacy policies to customers, such as publishing privacy policies on websites, or incorporating privacy seal programs (e.g. TRUSTe, ESRB, BBBOnline, and CPAWebTrust), these approaches do not provide systematic mechanisms to control how personal identifiable information is actually handled when and after it is collected. Privacy protection can only be achieved by enforcing privacy policies within an enterprise's online and offline data processing systems. Otherwise, enterprises' actual practices might intentionally or unintentionally violate the intended privacy policies.
Conventional access models, such as Mandatory Access Control, Discretionary Access Control, and Role Based Access Control (RBAC), are not designed to enforce privacy policies and barely meet privacy protection requirements, particularly, purpose binding (i.e. data collected for one purpose should not used for
another purpose without user consent), conditions and obligations. The significance of purposes, conditions, and
obligations lies in the OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data, in current privacy laws in many countries, and in public privacy policies of well known organizations, such as Google, IBM, and
Amazon. The OECD guidelines are, to the best of our knowledge, the most well known set of private information protection
principles on which many other guidelines, data-protection laws (e.g. EU Privacy Protection Directive, the Privacy
Act and the Personal Information Protection and Electronic Documents Act in Canada), and many public privacy policies are based. Purposes are directly applied in the OECD Data Quality Principle, Purpose Specification
Principle, and Use Limitation Principle.
There are many situations in which access to private data imposes obligations, that is, actions that must be fulfilled at some point in time in order to perform an action on these data. For example, the OECD Accountability Principle states that ``A data controller should be accountable for complying with measures which give effect to the principles stated above''. A common approach to implement this principle in operating systems or DBMS is to log each data access. Logging actions are obligations required by the majority of privacy policies.
Conditions, that is, prerequisites to be met before an action can be executed, are critical in some cases. One such case is related to children information. Rules in the Children's Online Privacy Protection Act (COPPA) apply to the online collection of personal information from children under 13. Here ``the age of the information source is under 13'' is a condition that must be satisfied before the COPPA rules are applied.
Despite its limitations, existing access control technology can be used as a starting point for managing personal identifiable information. Because both access control policies and privacy policies usually refer to the same set of data, they should not conflict, and using a single model for both kind of policies would greatly simplify management.
One approach to address the development of such an integrated model is to extend conventional access control models to support privacy-aware access control policies. By privacy-aware access control policies we refer to access control policies that incorporate additional information relevant for a controlled access to privacy-sensitive data. An example of such information is the intended use of the data. To facilitate the introduction of such a model in organizations, it is desirable that the model be defined as an extension of some widely deployed access control model. Thus we propose a family of Privacy-aware Role Based Access control (P-RBAC) models, naturally extending classical RBAC models to support privacy policies. Because RBAC is widely deployed in products and applications, we believe that by leveraging RBAC one can facilitate extending the access control policies currently deployed in organizations to support privacy-aware access control.
P-RBAC Family Models
Privacy-aware RBAC (P-RBAC) has been designed to support (possibly complex) privacy policies according to the guidelines discussed in the previous sections, and like classical RBAC consists of a family of conceptual models (see Figure 1) characterized by different modeling capabilities. Core P-RBAC, the base model, provides the basic components that are incorporated in advanced models such as Hierarchical P-RBAC and Conditional P-RBAC. There is a trade-off in the design of Core P-RBAC. On the one hand, Core P-RBAC should be sufficiently expressive to represent public privacy policies, privacy statements and privacy notices posted at Web sites, and policies based on privacy related acts. On the other hand, policy analysis in Core P-RBAC should remain tractable. Core P-RBAC is based on Core RBAC without the session component and is discussed in detail in the following section.
Figure 1 Family Models
Advanced models extend Core P-RBAC with additional modeling constructs. Hierarchical P-RBAC introduces the notions of Role Hierarchy (RH), Object Hierarchy, and Purpose Hierarchy (PH); it thus enhances Core P-RBAC with hierarchical organizations for three important entities of Core P-RBAC. RH has the same notation and semantics as in Hierarchical RBAC. OH describes a partial order relation (<=) between different objects. The semantics of the partial order relation is to propagate permissions among objects, i.e., given two objects O_1 <= O_2, if a permission defines some action on O_2, this permission implicitly defines the action on O_1 as well. An example of OH is represented by an XML document; if a permission specifies ``read an element e'', the permission implicitly allows ``read'' on all sub-elements under element e as well. PH describes a partial order relation (<=) between different purposes. The semantics of the <= is to group purposes when defining permissions.
Conditional P-RBAC introduces Permission Assignment Sets and Complex Boolean Expressions. Conditional P-RBAC is able to express more complex conditions than those supported by the simple condition language of Core P-RBAC. New types of context variables, like string and integer, are supported in Conditional P-RBAC, as well as commonly used logical operators like negation and disjunction. Moreover, Conditional P-RBAC allows policy writers to specify relations between different permission assignments. The need of richer conditions is easily understood, but the importance of relations between permission assignments requires further explanation.
In RBAC, permissions are (action, object) tuples. For any access request, there may be several applicable permission assignments. By applicable we mean that the permission assignments contain the same action and object in the access request. Permissions in these applicable permission assignments, however, must refer to the same tuple (action, object) of the request. Therefore, there is no need to consider the relation between several applicable permissions when answering the access request, e.g., should all applicable permission assignments be considered or only one of these permission assignments is sufficient. When conditions are introduced in permissions, the relation between applicable permissions becomes more complicated when answering an access request. If all applicable permission assignments must be considered and all conditions in these permissions must evaluate to true in order to allow the access request, the relation among these permission assignments is a conjunction (AND). If any of these permission assignments is sufficient and only one condition in these assignments needs to evaluate to true to allow the access request, the relation among the permission assignments is a disjunction. Because it is usually the case that all articles in an privacy act should be enforced, Core P-RBAC only supports the conjunction relation between permission assignments. It is obvious that such a design choice lacks flexibility and cannot handle situations requiring the disjunction relation. To address such requirement, Conditional P-RBAC enables policy writers to specify both conjunctions and disjunctions among permission assignments.
Universal P-RBAC combines the features of both Conditional P-RBAC and Hierarchical P-RBAC and in addition provides three important features, namely, negative permissions, flow control of obligation execution, and permission combination principles. Negative permissions are neither supported by RBAC'96 nor by the RBAC NIST Standard. However, they are useful or even necessary in some situations. For instance, Article 8(1) of the EU Privacy Protection Directive requires that ``Member States shall prohibit the processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and the processing of data concerning health or sex life.'' By enabling the translation of Article 8(1) directly into negative permissions one can avoid the additional steps required for representing and maintaining such a policy using only positive permissions. These steps are not trivial and must be proved to be correct. Having both positive and negative permissions has its own problems since it can result in ``inconsistent'' policy sets. Permission combination principles are introduced to address possible inconsistencies.
Core P-RBAC
Core P-RBAC is illustrated in Figure 2. The model includes several sets of entities: Users(U), Roles(R), Data(D), Actions(A), Purposes(Pu), Obligations(O), and conditions(C) expressed by using a customized language, referred to as LC0.
Figure 2 Core P-RBAC entities
In our model, referred to as Core P-RBAC, privacy policies are expressed as permission assignments (PA); these permissions differ from permissions in classical RBAC because of the presence of additional components, representing privacy related information. For details, please refer to our paper.
Conditional P-RBAC
Conditional P-RBAC supports more expressive condition languages and more flexible relations between permission assignments. Moreover, we extend the permission assignment analysis in Core P-RBAC to redundancy check, indeterministic obligation enforcement check, conflict check and coverage queries. To summarize, Conditional P-RBAC has the following four major differences when compared to existing work:
- Domains, atomic conditions, and relations among permission assignments are carefully crafted to meet the most demanding needs from privacy polices while keeping the complexity of policy analysis tractable;
- Special structures are proposed to process obligations appearing in multiple permission assignments that can simultaneously apply;
- Indeterminism in obligation enforcement among policies is identified and a solution is proposed;
- Efficient algorithms for detecting conflicts, indeterminism and redundancies of a new permission assignment against all existing permission assignments are presented.
For details, please refer to our paper.
Implementation of Core P-RBAC
We developed a management console for Core P-RBAC, and policy writers can use this console to maintain underline system data used in privacy policies, such as user, role, context variable, action, purpose, obligation, etc, to assign users to roles, and to assign permssions to roles. All system data are stored in database.
Figure 3 Schemas of Privacy Policies
During permission assignment, the management console can point out conflicts between new permission assignment and old ones. The management console is developed using .NET Framework 2.0, Visual C# 2005, and SQL Server Express 2005.
Figure 4 Management console of Core P-RBAC
XML-Specification for Core P-RBAC
In order to exchange privacy policies with other projects, e.g. IBM SPARCLE, we developed a draft version XML-Specification for Core P-RBAC, including schema and examples.