Privacy aware Role Based Access Control

Privacy is today a key issue in information technology and has received increasing attention from consumers, stakeholders, and legislators. Conventional access models, such as Mandatory Access Control (MAC) and Discretionary Access Control (DAC), are not designed to enforce privacy policies and barely meet the requirements of privacy protection. However, existing access control technology can be used as a starting point for managing personal identifiable information in a trustworthy fashion. A language used for privacy policies must be the same as or integrated with the language used for access control policies, because both types of policy usually control access to the same resources and should not conflict with one another. Therefore we have proposed a family of Privacy aware Role Based Access Control (P-RBAC) models that naturally extend classical RBAC models to support privacy policies.

We believe that a RBAC-based solution to the problem of privacy-aware access control may have a great potential. It could be easily deployed in systems already adopting RBAC and would thus allow one to seamlessly introduce access control policies specialized for privacy enforcement.

P-RBAC Family Models

Due to the complexity and variety of privacy policies and privacy requirements from different organizations, we employ a “Divide and Conquer” methodology. That is, the models in our P-RBAC family are designed to meet different levels of requirements and handle different problems. The P-RBAC family includes four models: Core PRBAC, Hierarchical P-RBAC, Conditional P-RBAC and Universal P-RBAC.

P-RBAC

Figure 1 Family Models

Core P-RBAC, the base model, is at bottom. There is a tradeoff when designing Core P-RBAC. On the one hand, Core P-RBAC should have sufficient expressive power for representing public privacy policies, privacy statements and privacy notices in Web sites, and policies based on privacy related acts, such as HIPPA, COPPA, and GLBA, in the US. On the other hand, conflicts detection in Core P-RBAC should remain tractable. Advanced models in the family extend Core P-RBAC with additional modeling constructs. Hierarchical P-RBAC introduces the notions of Role Hierarchy(RH), Data Hierarchy(DH), and Purpose Hierarchy(PH); it thus enhances Core P-RBAC with a hierarchical organizations for three important entities of Core P-RBAC. Conditional P-RBAC introduces Permission Assignment Sets and advanced conditional languages; its main goal is to provide languages for expressing conditions richer than the simple condition language provided by Core P-RBAC. Universal P-RBAC combines functionalities of both Conditional P-RBAC and Hierarchical P-RBAC.

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.

P-RBAC Entities

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:

  1. 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;
  2. Special structures are proposed to process obligations appearing in multiple permission assignments that can simultaneously apply;
  3. Indeterminism in obligation enforcement among policies is identified and a solution is proposed;
  4. 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.

Schema of privacy policies

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.

Management Console

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.