Security: Privacy-aware Role Based Access Control (P-RBAC)

Privacy-aware Role Based Access Control
Qun Ni, Purdue University, USA, ni@cs.purdue.edu
Alberto Trombetta, Insubria University, Italy, alberto.trombetta@uninsubria.it
Elisa Bertino, Purdue University, USA, bertino@cs.purdue.edu
Jorge Lobo, IBM T.J. Watson, USA, jlobo@us.ibm.com

SACMAT’07, June 20-22, 2007, Sophia Antipolis, France.
Copyright 2007 ACM 978-1-59593-745-2/07/0006 ...$5.00.

1. INTRODUCTION
Privacy is today a key issue in information technology and has received increasing attention from consumers, companies, researchers and legislators. Legislative acts, such as Health Insurance Portability and Accountability Act (HIPAA) [25] for healthcare and Gramm Leach Bliley Act (GLBA) [26] 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, ... in these approaches there are not systematic mechanisms that describe how consumer personal data is actually handled 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 privacy policies published at their websites.

Conventional access models, such as Mandatory Access Control (MAC), Discretionary Access Control (DAC), and Role Based Access Control (RBAC) [11, 22], are not designed to enforce privacy policies and barely meet privacy protection requirements[12], 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
originates from OECD Guidelines [19] on the Protection of Privacy and Transborder Flows of Personal Data, current privacy laws in the United States, and public privacy policies of some well know organizations. 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, and public privacy policies are based. Purposes are directly applied in the OECD Data Quality Principle, Purpose Specification Principle, and Use Limitation Principle. Purposes are also widely used for specifying privacy rules in legislative acts and actual public policies. HIPPA[25] rules clearly state purposes. The majority of public privacy documents posted at well known sites also specify purposes.
[Page 41]

ACM Digital Library Article (Member Access Only)

Security: Role-based access control (RBAC) fundamentals

An Extended RBAC Profile of XACML
Diala Abi Haidar 1,2, Nora Cuppens-Boulahia 1, Frederic Cuppens 1, Herve Debar 2
1 ENST Bretagne, 2 rue de la Chˆataigneraie, 35512 Cesson-S´evign´e Cedex, France
2 France Telecom R&D Caen, 42 rue des Coutures BP 6243, 14066 Caen, France

SWS’06, Novem ber 3, 2006, Alex andria, Virginia, USA.
Copyright 2006 ACM 1-59593-546-0/06/0011...$5.00.

The basic concept of the RBAC model is that users are assigned to roles, permissions are assigned to roles and users acquire permissions by being members of roles. The user-role
assignment can be a many-to-many relation in the sense that a user can be assigned to many roles and a role can have many users. Similarly, the permission-role assignment is also a many-to-many relation. The RBAC model is organized in four levels [24] each including the requirements of the basic RBAC: the flat (or core) RBAC, the hierarchical RBAC that adds requirements for supporting role hierarchies and the constrained RBAC that adds constraints on the hierarchical RBAC. The constraints may be associated with the user-role assignment (for static separation of duty) or with the activation of roles within user sessions (for dynamic separation of duty). The last level is the symmetric RBAC (also called consolidated) that adds a requirement for permission-role review. This is essential in any authorization management to identify and review the permissions assignment, i.e. the relation between permissions and roles.

The main benefit of this model is the ease of administration of security policies and its scalability. When a user moves inside an organization and has another function, the only thing the administrator needs to do is to revoke the existing user-role assignment and assign her a new role. There is no need to revoke the authorizations she had before and she will be granted new authorizations assigned to her new role. Adding to that, the role hierarchy defined in this model, where a given role can include all the permissions of another role, is a way of having a well structured access control that is the mirror of the organization structure. Finally the RBAC model supports the delegation of access permissions between roles. A role can delegate its role or
part of its role to another role [12].
[pages 14-15]

ACM Digital Library Article (Member Access Only)

Security: Role-based access control (RBAC) defined

Role-based access control
From Wikipedia, the free encyclopedia
(Redirected from RBAC)
Jump to: navigation, search

In computer systems security, role-based access control (RBAC) [1] [2] is an approach to restricting system access to authorized users. It is a newer alternative approach to mandatory access control (MAC) and discretionary access control (DAC).
RBAC is a policy neutral and flexible access control technology sufficiently powerful to simulate Discretionary Access Control (DAC) [3] and Mandatory Access Control (MAC). [4]
Prior to the development of RBAC, MAC and DAC were considered to be the only known models for access control: if a model was not MAC, it was considered to be a DAC model, and vice versa. Research in the late '90s demonstrated that RBAC falls in neither category.[citation needed]

Within an organization, roles are created for various job functions. The permissions to perform certain operations ('permissions') are assigned to specific roles. Members of staff (or other system users) are assigned particular roles, and through those role assignments acquire the permissions to perform particular system functions. Unlike context-based access control (CBAC), RBAC does not look at the message context (such as where the connection was started from).

Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of simply assigning the appropriate roles to the user, which simplifies common operations such as adding a user, or changing a user's department.

RBAC differs from access control lists (ACLs) used in traditional discretionary access control systems in that it assigns permissions to specific operations with meaning in the organization, rather than to low level data objects. For example, an access control list could be used to grant or deny write access to a particular system file, but it would not say in what ways that file could be changed. In an RBAC-based system an operation might be to create a 'credit account' transaction in a financial application or to populate a 'blood sugar level test' record in a medical application. The assignment of permission to perform a particular operation is meaningful, because the operations are fine grained and themselves have meaning within the application.
http://en.wikipedia.org/wiki/RBAC