Attribute-Based Systems

Attribute-based systems use attributes of principals and resources as they may exist, for instance, in an enterprise database, as a foundation for security and messaging operations. There are at least three areas of significant progress on such techniques. Attribute-Based Access Control (ABAC) promises greater flexibility and integration than access control lists and roles because of its ease of integration with existing enterprise data systems, all of which maintain databases of attributes for principals. Attribute-Based Messaging (ABM) enables the use of addresses and routing based on recipient attributes to make messaging more dynamic and targeted. Attribute-Based Encryption (ABE) allows data to be encrypted based on attributes so that only the principals with specified attributes are able to decrypt it.

Attribute-Based Access Control (ABAC)

ABAC is an access control strategy that centers access control decisions on the attributes of principals and resources. It can be contrasted with the more traditional notions of Identity Based Access Control (IBAC) and Role Based Access Control (RBAC). In IBAC identities of principals are used as a foundation for access control, typically in the form of Access Control Lists (ACLs), which are associated with resources and provide a list of parties having various access rights to the resource. The maintenance of such lists is a problem. For instance, if all managers are meant to have access to a file then the ACL for the file needs to change each time the group of managers changes. One way to address this problem is RBAC, in which a role describes a bundle of privileges. Principals are assigned roles (like manager) and these roles are used to authorize privileges (like access to the file for managers). Thus a new manager only needs to be assigned his role and the access right to the file will be derived from this automatically. A drawback to using such roles is that they require deliberate design and not all organizations have a system of roles for their principals. Moreover, when new resources are created, new access classes need to be defined: RBAC will require defining new roles for each new access class.

ABAC allows privileges to be derived directly from the attributes of principals (using relevant policies). So, a file that should be accessible to managers is marked as such by indicating that it is available to principals that have the manager attribute. More complex access policies can be specified in terms of a boolean formula on the attributes, like manager OR (programmer AND senior) (where the literals manager, senior etc. are boolean variables indicating whether the principal has that attribute). In fact a flexible design would typically use numerous fine-grained attributes (possibly arranged in hierarchical attribute spaces), and then many of the policies would use non-trivial combinations of multiple attributes. ABAC can be effectively combined with IBAC and RBAC in various ways, like using attributes to populate an ACL or assign a role, so there is not a rigid distinction between these techniques and advances in ABAC will contribute to IBAC and RBAC.

A Uniform Framework for Regulating Service Access and Information Release on the Web
P. A. Bonatti and P. Samarati
Journal of Computer Secuity, 10(3): 241–271, 2002.

Supporting Structured Credentials and Sensitive Policies through Interoperable Strategies for Automated Trust Negotiation
T. Yu, M. Winslett, and K. E. Seamons
ACM Transactions on Information Systems Security (TISSEC) 6(1): 1-42, 2003.

A Logic-Based Framework for Attribute-Based Access Control
Lingyu Wang, Duminda Wijesekera, and Sushil Jajodia
ACM Workshop on Formal Methods in Security Engineering (FMSE ’04), Washington DC, November 2004.

Attribute-Based Encryption (ABE)

Last updated on Thursday, June 26, 2014, 12:33 pm