privacy-aware role-based access control

Access Control

JULY/AUGUST 2009 ■ 1540-7993/09/$26.00 © 2009 IEEE ■ COPUbLIShEd bY ThE IEEE COmPUTEr And rELIAbILITY SOCIETIES 35

Qun ni and Elisa BErtino

Purdue University

JorgE loBo and sEraphin B. Calo

IBM T.J. Watson

P rivacy is of increasing concern to consum-ers, companies, researchers, legislators, and governments. Legislative acts in the US, such as the Health Insurance Portability and

Accountability Act (HIPAA) for healthcare and the Gramm-Leach-Bliley Act (GLBA) for financial insti-tutions, require enterprises to protect their customers’ privacy. (Here, customer and information provider both refer to an individual who releases personally identifi-able information to an enterprise.) Enterprises have ad-opted various strategies to protect customer privacy and communicate their privacy policies to customers—for example, by publishing privacy policies on their Web sites or incorporating privacy seal programs (Truste, BBBOnline, CPA WebTrust, and so on). However, these approaches don’t provide systematic mechanisms to control how personally identifiable information is handled when and after it’s collected. To protect cus-tomer privacy, enterprises must enforce privacy policies within their online and offline data-processing systems. Otherwise, their 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),1,2 don’t enforce privacy policies and barely meet privacy protection require-ments—in particular, purpose binding (that is, compa-nies shouldn’t use data collected for one purpose for another purpose without customer’s consent), condi-tions, and obligations. (See the “Related Work in Access Control Policies” sidebar for other work in this area.) The Organization for Economic Cooperation and De-velopment’s (OECD) Guidelines on the Protection of Pri-

vacy and Transborder Flows of Personal Data—from which many countries’ current privacy laws and the public privacy policies of well-known organizations such as Google, IBM, and Amazon are derived—recognize the significance of purposes, conditions, and obligations. HIPAA, GLBA, the EU Privacy Protection Directive and Canada’s Electronic Documents Act are based on the OECD guidelines.

Despite the limitations of existing access control technology, organizations can use this technology as a starting point for managing personally identifiable information.3 Because both access control policies and privacy policies might refer to the same set of data, they shouldn’t evaluate separately, and using a single model for both types of policies would greatly sim-plify management.4

One approach to developing such an integrated model is to extend conventional access control models to support privacy-aware access control policies. Priva-cy-aware access control policies incorporate additional information relevant for controlled access to privacy-sensitive data. The data’s intended use is an example of such information. To facilitate the introduction of such a model in organizations, the model should be an ex-tension of some widely deployed access control model. Thus, we propose a family of privacy-aware RBAC (P-RBAC) models, naturally extending classical RBAC models to support privacy policies.

Guidelines We designed P-RBAC models based on several im-portant privacy policy guidelines that we derived from

A privacy-aware role-based access control model extends

RBAC to express complex privacy-related policies,

including such features as conditions and obligations.

P-RBAC is easy to deploy in systems already adopting

RBAC, thus allowing seamless integration of access

control and privacy policies.

Privacy-Aware role-based Access Control

Access Control

36 IEEE SECUrITY & PrIVACY

the OECD principles and GLBA, HIPAA, and the Children’s Online Privacy Protection Act (COPPA).

Purpose BindingThe OECD Data Quality, Purpose Specification, and Use Limitation principles require purposes, which are bound to actions on personally identifiable informa-tion. Privacy acts and public policies often use purposes in specifying privacy rules. HIPAA rules, for example,

clearly state purposes. Most public privacy documents posted at well-known sites also specify purposes.

Conditions and ObligationsConditions are predicates that further limit a policy’s scope—that is, they specify under which situation an action on some object is allowed. Conditions let pol-icy writers specify fine-grained privacy policies that precisely meet privacy law requirements. Obligations

M odern access control policy languages proposed by

industry, such as Oasis’s Extensible Access Control Markup

Language (XACML) and the Enterprise Privacy Authorization

Language (EPAL), cite privacy policy support as an objective and

bind purposes to actions. However, these languages handle ob-

ligations as abstract symbols without concrete elements, so they

can’t directly translate privacy laws into access control policies.

Over the years, various access control models have addressed

different security requirements. Among those models, the role-

based access control (RBAC)1 and usage-control (UCON) models2

are the closest to the privacy-aware RBAC (P-RBAC).

Driven by digital rights management requirements, UCON

models focus not only on the initial access control but also on

continuous usage control, and therefore have some similarities

with P-RBAC—for example, conditions and obligations. In some

sense, the goal of UCON’s digital rights management is similar to

that of privacy protection in that content providers aim to control

access and content use after its distribution. However, privacy

protection follows a different protection methodology. Privacy

protection heavily depends on the access purpose and the

fulfillment of obligations within time intervals, whereas UCON’s

digital rights management focuses on the accounting of accesses

according to various criteria, such as membership-based metered

payment and pay per use. Accordingly, UCON models focus on

updating mutable attributes in obligations and don’t provide any

concrete temporal constraints in obligations. Therefore, UCON

only provides an abstract symbol, denoted by T, to represent a

timer or an event. Precisely translating privacy laws into access

control policies requires a more concrete temporal constraint

model. Moreover, no current approach detects conflicts and re-

dundancies in UCON authorizations, obligations, and conditions.

P-RBAC addresses these issues.

A crucial component in a model for expressing privacy poli-

cies is support for obligations. Researchers have proposed several

approaches to modeling and analyzing obligations. Claudio

Bettini and his colleagues formalized policies with obligations

as Horn clauses and investigated how to choose the best policy

rules to minimize the provisions and obligations a user must

fulfill to execute certain actions.3 Keith Irwin and his colleagues

modeled the notion of obligation as a tuple of subject, action,

objects, and a time window, and analyzed accountability of

obligation fulfillments.4 Daniel Dougherty and his colleagues pro-

posed an abstract model that handles obligations as constraints

on the program execution path.5 Compared to P-RBAC, most of

these obligation models are high-level abstract models. More-

over, because they weren’t designed to satisfy privacy law needs,

they lack support for crucial features, such as conditional obliga-

tions and repeating obligations. Finally, none of these approaches

are based on RBAC.

Hippocratic database systems address the problem of enforc-

ing privacy policies, written in standard languages such as the

Platform for Privacy Preferences and EPAL, in databases.6,7 Unlike

P-RBAC’s general, conceptual model, Hippocratic database sys-

tems, which can enforce both access control and privacy policies,

are an ad hoc, implementation-oriented approach. Hippocratic

database systems and P-RBAC can, however, complement each

other. Because the Hippocratic database systems’ design was

heavily influenced by P3P, which is limited in expressing obliga-

tions, Hippocratic database systems can’t deal with obligations

commonly required by privacy laws. Hippocratic database

systems support any conditions in policies that are expressible in

SQL, but they can’t detect possible conflicts among policies. On

the other hand, techniques proposed in the context of Hippo-

cratic database systems, such as query modification, can support

database systems in enforcing P-RBAC policies.

References

D.F. Ferraiolo et al., “Proposed NIST Standard for Role-Based Access 1.

Control,” ACM Trans. Information Systems Security, vol. 4, no. 3, 2001,

pp. 224–274.

J. Park and R.S. Sandhu, “The ucon2. abc Usage Control Model,” ACM

Trans. Information Systems Security, vol. 7, no. 1, 2004, pp. 128–174.

C. Bettini et al., “Provisions and Obligations in Policy Rule Management,” 3.

J. Network and Systems Management, vol. 11, no. 3, 2003, pp. 351–372.

K. Irwin, T. Yu, and W.H. Winsborough, “On the Modeling and Analy-4.

sis of Obligations,” Proc. 13th ACM Conf. Computer and Comm. Security

(CCS 06), ACM Press, 2006, pp. 134–143.

D.J. Dougherty, K. Fisler, and S. Krishnamurthi, “Obligations and Their 5.

Interaction with Programs,” Proc. 12th European Symp. Research In Com-

puter Security (ESORICS 07), LNCS 4734, Springer, 2007, pp. 375–389.

R. Agrawal et al., “Hippocratic Databases,” 6. Proc. Very Large Databases

(VLDB), Morgan Kaufmann, 2002, pp. 143–154.

K. LeFevre et al., “Limiting Disclosure in Hippocratic Databases,” 7. Proc.

Very Large Databases (VLDB), Morgan Kaufmann, 2004, pp. 108–119.

Related Work in Access Control Policies

Access Control

www.computer.org/security 37

regulate which actions subjects must fulfill at a certain time to allow a certain action to be performed. The following examples demonstrate why conditions and obligations are necessary components in privacy laws.

COPPA states:

Before collecting, using, or disclosing personal in-formation from a child, an operator must obtain ver-ifiable parental consent from the child’s parent. This means that an operator must make reasonable efforts (taking into consideration available technology) to ensure that before personal information is collected from a child, a parent of the child receives a notice of the operator’s information practices and consents to those practices.

A permission to collect, use, or disclose a child’s in-formation is conditional because the operator must confirm verifiable parental consent. Furthermore, an obligation to inform a parent and obtain verifiable pa-rental consent must be fulfilled before any operator (subject) in an organization may access a child’s in-formation if it hasn’t obtained parental consent in the past. Such an obligation might therefore be condition-al as well. After the organization fulfills the obligation and obtains a reply (either consent or rejection) from a parent, it shouldn’t ask that parent the same question again. Therefore, before activating the obligation, the organization must check whether it has already re-quested consent.

Another COPPA rule states:

At any time, a parent may revoke his/her consent, refuse to allow an operator to further use or collect their child’s personal information, and direct the op-erator to delete the information.

From an access control viewpoint, this rule suggests that upon obtaining parental consent and collecting a child’s information, operators should immediately assign permissions such as “revoke consent,” “refuse further use or collection,” or “request deletion” to the parent who gave consent. One way to specify such permissions in formal access control policies is by us-ing obligations that the operator must fulfill without delay after collecting a child’s information. Obliga-tions might include actions such as “grant permis-sions” or “revoke permissions.”

One GLBA rule asserts,

Consumers are entitled to receive a privacy notice from a financial institution only if the company shares the consumers’ information with companies not affiliated with it, with some exceptions. Custom-ers must receive a notice every year for as long as the customer relationship lasts.

Two different obligations concern consumers and cus-tomers. An organization should fulfill an obligation such as “sending consumers a privacy notice,” once af-ter disclosing the consumers’ information. However, it must fulfill another obligation, “sending customers privacy notices,” periodically. At first glance, the latter obligation seems not to be bound to any action—for example, collecting, using, or disclosing customers’ information. Such an obligation is related to an at-tribute of the information providers, however. The attribute specifies that these providers aren’t only con-sumers but also customers. (In the GLBA, a consumer is an individual who obtains or has obtained a finan-cial product or service from a financial institution for personal, family, or household reasons. A customer is a consumer with a continuing relationship with a finan-cial institution.) The obligation is therefore related to an action that changes a consumer to a customer.

In short, both conditions and obligations are nec-essary components when modeling privacy laws. Moreover, our examples show that obligations are the most complex component. We can thus summarize the relevant modeling features required to adequately express obligations.

Action binding. Obligations are usually coupled with some action request—that is, subjects commit them-selves to complete some obligations to execute a spe-cific action on some objects. In some cases, obligations are only connected to some special objects in policies. Nevertheless, a corresponding action can still be recog-nized because there’s usually an action that makes these objects special and thus triggers these obligations.

Temporal constraints. Obligations typically include temporal constraints. Pre-obligations, for example, should be fulfilled before an action request is allowed, and the result from fulfilling the obligation might affect the decision on the action request. Postobligations, however, should be fulfilled after the action in the action request is executed. Intuitively, each obligation should be as-signed a temporal constraint to specify the right time to fulfill the obligation. Otherwise, a policy-enforcement engine can’t determine when to start evaluating policy conditions if pre-obligations exist, and subjects can le-gally circumvent postobligations by saying “I will do it in the future.” In some situations, temporal constraints might require that obligations be performed repeatedly until some condition becomes true.

Different subjects. A subject’s obligation might come from another subject’s action request—that is, the obligation’s subject might not be the subject who causes the obligation. For instance, when an operator discloses a child’s information to third parties, these parties might be required to fulfill obligations similar

Access Control


to the operator’s. In some situations (for example, log-ging accesses) the subject of an obligation might be the system itself.

Conditional obligations. Some obligations can be conditional—that is, a subject must perform them only if some condition becomes true. For instance, COPPA specifies that “an operator is required to send a new notice and request for consent to parents if there are material changes in the collection, use, or dis-closure practices to which the parent had previously agreed.” The “material changes” here are the prereq-uisites to execute the obligations “send a new notice” and “request for consent.”

Privacy-Aware RBAC Family ModelsAs Figure 1 shows, P-RBAC consists of a family of conceptual models characterized by different model-ing capabilities. Core P-RBAC, the base model, pro-vides 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 core P-RBAC’s design. On one hand, core P-RBAC should be sufficiently expressive to represent public privacy policies, privacy statements, and privacy no-tices on Web sites, and access control policies derived from privacy-related acts. On the other hand, policy analysis in core P-RBAC should remain tractable. Core P-RBAC is based on core RBAC1 without the session component.

Advanced models extend core P-RBAC with ad-ditional modeling constructs. Hierarchical P-RBAC introduces the notions of role hierarchy, object hier-archy, and purpose hierarchy. It thus enhances core P-RBAC with hierarchical organizations for three

important core P-RBAC entities. Role hierarchy uses the same notation and semantics as in hierarchi-cal RBAC.1 Object hierarchy describes a partial order relation (≤) between objects. The ≤ relation indicates that permissions propagate among objects—that is, given two objects O1 ≤ O2, if a permission defines some action on O2, it implicitly defines the action on O1 as well. Consider, for example, an XML docu-ment. If a permission specifies “read an element e,” the permission implicitly allows “read” on all subelements under element e as well. Purpose hierarchy describes a partial order relation (≤) between purposes. Likewise, the purpose relation indicates that those permissions propagate among purposes.

Conditional P-RBAC introduces permission as-signment sets and complex Boolean expressions.5 It can express more complex conditions than those supported by core P-RBAC’s condition language. Conditional P-RBAC supports new types of context variables, such as string and integer, as well as commonly used logical operators such as negation and disjunction. Moreover, conditional P-RBAC lets policy writers specify rela-tions between permission assignments.

The need for richer conditions is easily understood, but the importance of relations between permission assignments requires further explanation.

In RBAC, permissions are (action, object) tuples. An access request can have several applicable permis-sion assignments. By “applicable,” we mean that the permission assignments contain the same action and object in the access request. (Roles in applicable per-mission assignments must have been assigned to the user in the access request.) Permissions in these appli-cable permission assignments, however, must refer to the same (action, object) tuple as the request. There-fore, we don’t need to consider the relation between several applicable permissions when answering the ac-cess request.

If conditions are introduced in permissions, the re-lation 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 to allow the access request, the relation among these permission assignments is a conjunction. If any of these permission assignments is sufficient and only one condition in the assignments must evaluate to true to allow the access request, the relation among the per-mission assignments is a disjunction. Because typically all articles in a privacy act should be enforced, core P-RBAC supports only the conjunction relation be-tween permission assignments. Obviously, such a de-sign choice lacks flexibility and can’t handle situations requiring the disjunction relation. (Some disjunctive cases can be handled by splitting context variables.6) To address such requirements, conditional P-RBAC

Core P-RBAC

Conditional P-RBAC

Universal P-RBAC

Hierarchical P-RBAC

Figure 1. The family of conceptual privacy-aware role-based access control

(P-RBAC) models. Hierarchical P-RBAC extends the core P-RBAC with role,

object, and purpose hierarchies. Conditional P-RBAC adds permission

assignment sets and complex Boolean expressions. Universal P-RBAC

combines hierarchical and conditional P-RBAC and introduces three new

constructs: negative permissions, flow control of obligation execution, and

permission combination.

Access Control


lets policy writers specify both conjunctions and dis-junctions among permission assignments.

Universal P-RBAC combines the features of con-ditional P-RBAC and hierarchical P-RBAC and pro-vides three important features: negative permissions, flow control of obligation execution, and permission combination principles.

Neither RBAC 962 nor the RBAC National Insti-tute of Standards and Technology Standard1 support negative permissions. However, these permissions are useful or even necessary in some situations. For in-stance, Article 8(1) of the EU Privacy Protection Di-rective requires that

Member States shall prohibit the processing of per-sonal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and the processing of data con-cerning health or sex life.

Translating Article 8(1) directly into negative per-missions can avoid the additional steps required for representing and maintaining such a policy using only positive permissions. These steps aren’t trivial and must be proved to be correct. Having both positive and negative permissions can result in inconsistent policy sets. Permission combination principles address possible inconsistencies.

Because of space limitations, we focus on core P-RBAC. Some fundamental concepts of the RBAC standard,1 such as sessions and constraints, can be seamlessly added in P-RBAC. We don’t discuss them here because our focus is on expressing privacy poli-cies in P-RBAC.

Core P-RBACAs Figure 2 illustrates, core P-RBAC includes several sets of entities: users, roles, objects, actions, purposes, obligations, and conditions expressed using a custom-ized language, referred to as LC0.

A user is a human being or any subject which can initiate an action, and a role represents a job function or job title within the organization with some associ-ated semantics regarding the authority and responsi-bility conferred on a member of the role.1 In some sense, the collection of individuals external to the or-ganization collecting the data, such as the parents of children whose information has been collected, can be considered a role as well, because from the orga-nization’s perspective, these individuals have some authority over the information collected. Parents, for example, clearly have some authority regarding their children’s information.

An object is any resource that should be protected. An action is an executable image of a program, which executes some function for the user upon invocation.

The types of actions and objects that P-RBAC con-trols depend on the type of system in which P-RBAC is deployed.

Roles in P-RBAC not only represent groups of individuals within an organization but also groups of information providers. A reviewer of this article argued, “Privacy is understood as relating to indi-viduals, whereas roles are concerned not with indi-viduals but with categories of individuals. Thus, the perspectives of privacy and RBAC are different and from this potential tensions arise.” We believe that just as roles help simplify the administration of access control policies, they can be helpful in administrating privacy policies. In P-RBAC, we thus deal with two classes of individuals: the individuals represented by information providers about whom data is collected, and individuals who access the data collected about the information providers, referred to as data users. Accesses by data users must be controlled to ensure that privacy regulations aren’t violated. Accesses to data by information providers should be allowed in a limited form as well to comply with privacy laws—for example, to let information providers add, delete, or change their own information. From the viewpoint of access control policy administration, no major dif-ference exists between assigning roles to information providers and assigning roles to data users. Personal preferences concerning privacy protection aren’t en-coded in roles but in attributes about information providers collected as privacy metadata accessible by context variables in permissions.

In core P-RBAC, as in classical RBAC, an admin-

P-RBAC permissions

RBAC permissions

Permissionassignments

Purpose binding

Purposes

Objects Conditions

Obligations

Users Roles

Actions

User assignments

Figure 2. Core P-RBAC model. P-RBAC extends the RBAC model to include

the action’s intended purpose, the conditions under which the requestor

may perform the action, and the obligations that some subject must

perform before or after granted action.

Access Control


istrator assigns permissions to roles and users obtain such permissions by being assigned to roles. Core P-RBAC’s distinctive feature lies in the complex struc-ture of privacy permissions, which reflect the highly structured ways of expressing privacy rules to repre-sent the essence of OECD principles and privacy acts. Therefore, aside from the object and the action to be performed on it, a privacy permission explicitly states the intended purpose, the conditions under which the permission can be granted, and the obligations to be performed before the permission is granted or after the permission is obtained.

ConditionsCore P-RBAC conditions shouldn’t be confused with constraints in the classic RBAC model. Constraints are a mechanism for laying out higher-level organiza-tional policies that might cross several roles, whereas conditions are a mechanism to precisely define a single role’s permission. A common example of constraints is separation of duties. Handling privacy-related condi-tions and constraints separately lets us focus on how to effectively and precisely model the necessary prereq-uisites for enforcing privacy policies.

LC0 expresses conditions using context variables. Such variables record privacy-relevant information that must be considered when enforcing privacy per-missions. Even though the condition language has limited expressive power, it can model many condi-tions usually found in privacy acts and policies. Defi-nition 1 states the conditions that can be expressed by LC0.

Definition 1.6 Let CV be a set of context variables. Each variable x ∈ CV has a finite domain of possible values, denoted Dx. Every domain is equipped with a pair of corresponding relational operators (= and ≠). The conditions ⊥ (false) and T (true) are constant. An atomic condition defined over CV has the form (x opr

v), where x ∈ CV, v ∈ Dx, opr ∈ {=, ≠}. We define the conditions of LC0 (over CV ) as follows:

a • constant condition is a condition of LC0,an • atomic condition is a condition of LC0, andlet • ci and cj be conditions of LC0, the conjunction of ci and cj (ci ∧ cj) is a condition of LC0.

For instance, the variable oc represents the infor-mation provider’s consent for collecting, using, or dis-closing his or her personally identifiable information. The variable’s domain is {yes, no, n/a}, where “n/a” means not available and indicates that the information provider hasn’t been asked for consent.

The variable vpc represents a parent’s consent for collecting, using, or disclosing his or her child’s infor-mation. Its domain is {yes, no, n/a}.

Because the set of context variables is finite, each context variable has a finite domain, and only equal-ity and inequality are supported. Thus, the set of all possible conditions (module logical equivalence) ex-pressed in LC0 is finite. C denotes this set.

ObligationsAn obligation’s subject might differ from the user per-forming the action that triggered the obligation, so we also add a component for indicating the obligation subject to the permission. This doesn’t mean giving a blank permission to the obligation subject to execute the action imposed by the obligation. The obligation subject must independently have permission to execute the action during the time frame that the obligation must be fulfilled or the obligation will be violated.

When defining a permission assignment, the ob-ligation’s subject often isn’t fully identified. In some cases, such a subject is the user that submitted the ac-tion request. In other cases, a policy author might have to choose the subject from the set of users assigned to a particular role. The latter case is common in privacy laws because subjects in law statements usually refer to groups of individuals that share some properties. In these cases, the P-RBAC permissions will explicitly identify the obligation subjects using some special con-text variables, such as those in Table 1. These special context variables form a subset of CV and are mainly used in conditions to refer to the obligation subjects.

We based our temporal constraint model on a simple notion of time domain—that is, the pair (Z; ≤). In our context, each element of Z is referred to as a time instant, and ≤ is a total order on Z. In what follows, given t, t´ ∈ Z, [t, t´] denotes the time interval starting at time instant t and ending at time instant t .́ Definition 2 introduces a terse yet flexible definition for temporal constraints, which is the key notion in our temporal constraint model.

Definition 2. A temporal constraint tc is a tuple (ts, te, cnt), where ts, te ∈ Z, and cnt ∈ N*. The variables ts and te represent a time interval starting at ts and ending at te, and cnt represents the time interval’s repeating number. Temporal constraint tc denotes a sequence of time intervals defined as follows:

[• ts, te], [te + 1, 2te – ts + 1], …, [ts + (cnt – 1)(te – ts + 1), te + (cnt – 1) (te – ts +1)] if te ≥ ts ≥ 0.[• ts – (cnt – 1)(te – ts + 1), te – (cnt – 1)(te – ts + 1)], …, [2ts – te + 1, ts – 1], [ts, te] if 0 ≥ te ≥ ts.

For instance, a temporal constraint (3, 7, 3) rep-resents the sequence of time intervals [3, 7], [8, 12], [9, 13]. For simplicity, we further assume in the P-RBAC model that time is relative. We model time as an integer representing the number of basic time

Access Control


instants from a predetermined time instant, denoted by 0, which is related to an action request. We identify two special time instants that are related to the prede-termined time instant 0:

decision time• , which is the time instant at which a policy decision point (PDP) decides to grant an ac-cess requester to execute the action; and completion time• , which is the time instant at which the action’s execution is completed.

For a time instant t, if t > 0, t represents |t| time instants after a completion time. If t < 0, t repre-sents |t| time instants before a decision time. For a temporal constraint (ts, te, cnt), if te ≤ 0, the tempo-ral constraint indicates that the executed obligation is a pre- obligation and should be fulfilled during the time interval between the request time and the deci-sion time. If ts ≥ 0, the temporal constraint indicates that the associated obligation is a postobligation that should be fulfilled some time after completion time. As a special case, te = ts = 0 indicates a postobligation that should be fulfilled immediately after the action has been executed.

The distinction between the time before grant-ing the access requester to execute the action and the time after the action’s execution gives t = 0 a different meaning depending on whether t repre-sents a starting time ts or an ending time te. Classical access control policies without obligations consider the time at which an action request occurs, the time at which to evaluate the condition of applicable per-mission assignments, the time at which to authorize the action, and the time at which the action is per-formed to be the same. In practice, however, these times differ, especially when they contain obliga-tions and temporal constraints.

In a temporal constraint, when te = 0 and ts < 0, the constraint requires that a PDP evaluate the pre-obligation before evaluating the permission con-dition. This requirement ensures that some relevant subject executes the actions within the pre-obliga-tion that affect the value of context variables in the permission conditions before evaluating the permis-sion condition. Consider the policy, “Before collect-ing, using, or disclosing personal information from a child, an operator must obtain verifiable parental consent from the child’s parent.” In this policy, the obligation to “obtain verifiable parental consent” might affect a context variable vpc’s value by assign-ing it a value from the set {yes, no, and n/a}. The vpc’s value in turn affects the evaluation of the condi-tions in the policy that help the PDP decide whether he or she can collect, use, or disclose a child’s infor-mation. The term ts = 0 represents a different situa-tion. If the PDP grants an action request, the subject

who submitted the request might decide not to ex-ecute the action because of the burden imposed by the postobligations. Therefore, the timer recording the time interval allocated to postobligations might start counting only after the subject has performed the action.

Definition 3 formalizes the obligation model we adopted for P-RBAC.

Definition 3. Let C be a set of possible conditions ex-pressed in LC0, U a set of users, ICV a set of special context variables, A a set of actions, O a set of objects, and TC a set of temporal constraints. An obligation is a tuple (c, s, a, o , tc), where c ∈ C, s ∈ U ∪ ICV, a ∈ A, o ∈ B(O) (a powerset of O), and tc ∈ TC.

The set U represents both humans and any other subject who can initiate an action. The set O includes any other component introduced in the definition—for example, U, ICV, and TC. Data is a subset of O as well. In theory, TC could be infinite. None-theless, we assume that for each deployment of core P-RBAC, only a finite set of temporal constraints is applicable. Based on this assumption, we further conclude that the number of possible obligations is also finite. Examples of obligations using context variables include

In the context variable (• c, self, a, {o}, tc), if condition c is true, the subject submitting the action request activating the obligation performs the action a on object o under the temporal constraint tc. In the context variable (• ra = r, auser, a, {o}, tc), a user with role r is obligated to perform action a on object o under the temporal constraint tc. In the context variable (• rs = r, users, a, {o}, tc), all users of role r are obligated to perform action a on object o under the temporal constraint tc.

As these examples show, context variables let users ex-press many conditions of interest for obligations speci-fied in privacy laws and regulations.

Table 1. The special context variable (ICV) set.

Name DomaIN RepReseNTINgself The set of users The user who submits the action

request

auser The set of users A possible user

ra The set of roles The role of the user whom the

variable “auser” represents

users The power set of the set

of users

All possible users

rs The set of roles The role of users whom the vari-

able “users” represents

Access Control


Core P-RBAC modelDefinition 4 combines the previous notions and for-mally introduces core P-RBAC.

Definition 4. The core P-RBAC model consists of the following components:

A set • D of data, a set U of users, a set R of roles, a set Pu of purposes, a set A of actions, a condition language LC0, and a set O of objects such that D ∪ U ∪ R ∪ Pu ∪ A ∪ CV ⊂ O.A finite set • TC of temporal constraints defined ac-cording to Definition 2, and TC ⊂ O.A set • Ob of obligations on O defined according to Definition 3.A set • P ⊆ C × A × B(O) × B(Pu) × B(Ob) of per-missions.A set • PA ⊆ R × P of permission assignments—a many-to-many permission-to-role assignment relation.A set of • UA ⊆ U × R user assignments—a many-to-many user-to-role assignment relation.

We omit sessions, a component of the RBAC stan-dard definition,1 for simplicity. We could integrate this concept into our model, but its details and the analysis of the interaction between sessions and obligations are out of this article’s scope. As is apparent, for any per-mission p = (c, a, o p ou b, , ), p is a regular access control permission if c = T, pu = ∅, and ob = ∅. Therefore, our core P-RBAC permission set is a superset of the permission set in the core RBAC model.

An ExampleWe demonstrate how P-RBAC can represent privacy law rules with obligations using a rule from COPPA. Although the rule looks simple, it includes several features supported by P-RBAC, such as repeating obligations, conditional obligations, and pre-obliga-tions. Additional examples that illustrate other useful P-RBAC features, such as a method that deals with obligations with subject binding instead of action binding, are available elsewhere.7

COPPA states:

Before collecting, using or disclosing personal infor-mation from a child, an operator must obtain verifi-able parental consent from the child’s parent.

To represent such a policy, we must specify three permission assignments, each of which corresponds to one of three actions: collect, use, and disclose. Because they’re similar, we show only the permission related to the collection. Such permission is as follows:

PA1: (operator, vpc = yes, collect, {ci}, ∅, {(vpc = n/a, self, obtain, {vpc, pi}, (–wd, 0, 2))}),

where vpc denotes the context variable “verifiable pa-rental consent,” ci denotes the object “child’s informa-tion,” and pi denotes the context variable “the parent whose child’s information is collected, used, or dis-closed in permissions.”

Because the original policy doesn’t specify a pur-pose, the purpose component is an empty set. The value wd is a predefined constant number indicating the number of days to wait for the response. The tem-poral constraint (–wd, 0, 2) indicates that obtain is a pre-obligation, and if there’s no reply in wd days, an operator can ask again. The value n/a (not available) indicates that the corresponding parent has never been asked for consent. If the value of vpc isn’t n/a (that is, it’s yes or no), the parent shouldn’t be asked again.

Some Words about Policy AnalysisLarge organizations usually must deal with complex access control and privacy policies. The more com-plex these policies are, the higher the probability that they’ll contain errors because of new requirements or regulations, interaction among policies, or just hu-man mistakes. These organizations therefore need techniques to detect incorrect policies before they’re deployed. To address this issue, we identified some primitive operations for analyzing P-RBAC poli-cies. These operations include validity of permission assignments, dominance of obligations, and indeter-minism of obligation enforcement.

If obligations in a new permission contradict exist-ing permissions or the permission itself, the new per-mission is invalid. The interaction between permissions and obligations can cause problems, such as when there is no permission letting an obligation’s subject perform the action in the obligation, or if the subject can’t sat-isfy the conjunction of the condition in the obligation and the condition in the permission containing the ob-ligation. Obligation execution might result in obliga-tion cascading—that is, an obligation’s execution can trigger another obligation’s execution, which in turn might trigger other obligations. Ill-written permis-sions can result in nonterminating obligation execu-tion. The cascading bag notion addresses this issue.7

The dominance of obligation characterizes the dif-ferent strictness between two obligations. Some re-quests might have several applicable policies that could lead to numerous obligations. Therefore, reducing the number of obligations to be executed might have significant practical impact. Obviously, the remain-ing obligations shouldn’t reduce the duties required by the original policies. On the other hand, many of these obligations will likely be similar to each other because they’re associated with similar permissions. An efficient algorithm for minimizing obligation fulfillments that accounts for temporal constraints is available elsewhere.7

Access Control


Indeterminism in obligation enforcement arises because multiple policies can apply to the same access request. Given a request to which two or more policies apply, the choice of obligations to be executed can be nondeterministic if policies aren’t well written—for example, the relationship between applicable policies is a disjunction, and these policies have diff erent obli-gation sets. Policy normalization is one way to detect indeterminism in obligation enforcement.5 We’ve also investigated techniques for detecting confl icting and redundant policies in P-RBAC.5,6

M any interesting problems remain open. The in-troduction of more expressive condition lan-

guages, delegation models, or hierarchies would further complicate the interaction between obliga-tions and permissions. An obligation model with more fl exible fl ow control of obligation execution might be desired. For instance, causal relations might exist between obligations, and policies might have several alternative obligations. New refi nement techniques for P-RBAC policies could directly support and automate the translation of high-level privacy-protection goals onto low-level policies.

ReferencesD.F. Ferraiolo et al., “Proposed NIST Standard for 1. Role-Based Access Control,” ACM Trans. Information Systems Security, vol. 4, no. 3, 2001, pp. 224–274.R.S. Sandhu et al., “Role-Based Access Control 2. Models,” Computer, vol. 29, no. 2, 1996, pp. 38–47.C.S. Powers, “Privacy Promises, Access Control, and 3. Privacy Management,” Proc. 3rd Int’l Symp. Electronic Commerce (ISEC), IEEE CS Press, 2002, p. 13.A.H. Anderson, “A Comparison of Two Privacy Pol-4. icy Languages: EPAL and XACML,” Proc. 3rd ACM Workshop Secure Web Services (SWS), ACM Press, 2006, pp. 53–60.Q. Ni et al., “Conditional Privacy-Aware Role-Based 5. Access Control,” Proc. 12th European Symp. Research In Computer Security (ESORICS 07), Springer, LNCS 4734, 2007, pp. 72–89.Q. Ni et al., “Privacy-Aware Role-Based Access Con-6. trol,” Proc. ACM Symp. Access Control Models and Tech-nologies (SACMAT), ACM Press, 2007, pp. 41–50.Q. Ni, E. Bertino, and J. Lobo, “An Obligation Model 7. Bridging Access Control Policies and Privacy Policies,” Proc. ACM Symp. Access Control Models and Technologies (SACMAT), ACM Press, 2008, pp. 133 –142.

Qun Ni is a PhD student and research assistant in the De-

partment of Computer Science at Purdue University. His re-

search interests include privacy-aware access control and

access control decision aggregation. Ni has an MS in com-

puter system architecture from the Institute of Computing

Technology, Chinese Academy of Sciences. Contact him at

[email protected].

Elisa Bertino is a professor in the Department of Computer

Science at Purdue University and the research director at the

Center for Education and Research in Information Assurance

and Security. Her research interests include information se-

curity and database systems. Bertino has a PhD in computer

science from the University of Pisa. She is a fellow of the IEEE

and the ACM. Contact her at [email protected].

Jorge Lobo is a research staff member at the IBM T.J. Wat-

son Research Center. His research interests include policy

management, semantics of logic programs, and nonmono-

tonic reasoning. Lobo has a PhD in computer science from the

University of Maryland, College Park. Contact him at jlobo@

us.ibm.com.

Seraphin B. Calo is a research staff member and the man-

ager of the policy life-cycle technologies team at the IBM T.J.

Watson Research Center. His research interests include policy

management. Contact him at [email protected].

Learn about computing history and the people who shaped it.

COMPUTING THEN

http://computingnow.computer.org/ct