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)

Today, mailing lists are used to provide such messaging, however, recipient lists are overly broad because creating and maintaining more specific lists requires a non-trivial amount of work. ABM is the concept of allowing lists to be formed dynamically by using attributes of intended recipients as addresses. ABM enhances the relevance of messages to the recipient and allows the sender to send confidential messages knowing that the messages would be only delivered to the intended recipients. This concept can be applied to any collection of attributes that are available in enterprise databases. Practical ABM raises some interesting challenges, however. First, there is the challenge of finding a manageable way to deal with access control. If anybody can send a message based on any set of attributes, this may increase rather than decrease the number of unwanted communications. It also entails some privacy issues. For instance: who, if anyone, is allowed to send an email message to faculty that make a salary of more than $100,000? Second, there is the challenge of finding a plausible deployment avenue for ABM that allows the clients to send and receive attribute-based messages via the existing enterprise messaging systems. Third, there is the problem of making ABM sufficiently efficient. And fourth, there is the challenge of extending ABM to inter-domain systems so it can work in messages between organizations.

Attribute-Based Secret Handshake (ABSH)

ABSH protocols allow two users to perform a handshake (or key-exchange) only if each user has attributes specified by the other user. In addition, they have the additional feature that, if a user does not satisfy the specified attributes of the other party involved in the handshake, not only the key-exchange fails but the parties learn nothing about each others' attributes. Recent ABSH techniques use generalized Identity Based Encryption or Fuzzy Identity Based Encryption to achieve the above mentioned goals.

Secret Handshakes with Dynamic and Fuzzy Matching,
G. Ateniese, M. Blanton, and J. Kirsch,
Network and Distributed System Security Symposuim (NDSS '07), SanDiego, CA, Feb. 2007.