Content uploaded by D. Richard Kuhn
Author content
All content in this area was uploaded by D. Richard Kuhn on Aug 07, 2015
Content may be subject to copyright.
Attribute-Based Access Control
Vincent C. Hu, D. Richard Kuhn, David F. Ferraiolo
National Institute of Standards and Technology
Gaithersburg, MD, USA
vhu, kuhn, dferraiolo@nist.gov
ABAC is a flexible access control approach that can implement
policies which are limited only by the computational language
and the richness of the available attributes. This flexibility
enables the greatest breadth of subjects to access the greatest
breadth of objects without specifying individual relationships
between each subject and each object, making ABAC ideal for
many distributed or rapidly changing environments.
Traditionally, Access Control (AC) has been based on the
identity of a user requesting execution of a capability to
perform an operation (e.g., read) on an object (e.g., a file),
either directly, or through predefined attribute types such as
roles or groups assigned to that user. Practitioners have noted
that this approach to AC is often cumbersome to manage
given the need to associate capabilities directly to users or
their roles or groups. In addition, the requester qualifiers of
identity, groups, and roles are often insufficient in the
expression of real-world AC policies. An alternative is to
grant or deny user requests based on arbitrary attributes of the
user and selected attributes of the object, and environment
conditions that may be globally recognized and more relevant
to the policies at hand. This approach is often referred to as
ABAC.
ABAC is a logical AC model that is distinguishable because
it controls access to objects by evaluating rules against the
attributes of entities (subject and object), operations, and the
environment relevant to a request. ABAC enables precise AC,
which allows for a higher number of discrete inputs into an
AC decision, providing a larger set of possible combinations
of those variables to reflect a larger and more definitive set of
possible rules to express policies, which are limited only by
the computational language and the richness of the available
attributes. This flexibility enables creation of access rules
without specifying individual relationships between each
subject and each object. For example, a subject is assigned a
set of subject attributes upon employment (e.g., Nancy Smith
is a Nurse Practitioner in the Cardiology Department). An
object is assigned its object attributes upon creation (e.g., a
folder with Medical Records of Heart Patients). Objects may
receive their attributes either directly from the creator or as a
result of automated scanning tools. The administrator or
owner of an object creates an AC rule using attributes of
subjects and objects to govern the set of allowable capabilities
(e.g., all Nurse Practitioners in the Cardiology Department can
View the Medical Records of Heart Patients). Under ABAC,
access decisions can change between requests by simply
changing attribute values, without the need to change the
subject/object relationships defining underlying rule sets. This
provides a more dynamic AC management capability and
limits long-term maintenance requirements of object
protections.
Further, ABAC enables object owners or administrators to
apply AC policy without prior knowledge of the specific
subject and for an unlimited number of subjects that might
require access. As new subjects join the organization, rules
and objects do not need to be modified, and as long as the
subject is assigned the attributes necessary for access to the
required objects (e.g., all Nurse Practitioners in the Cardiology
Department are assigned those attributes), no modifications to
existing rules or object attributes are required. This benefit is
often referred to as accommodating the external
(unanticipated) user and is one of the primary benefits of
employing ABAC.
1,2
As a result of this flexibility, ABAC has attracted interest
across industry and government, and is the fastest growing
access control model today
3
[ref, Gartner?]. It has been
integrated with other approaches, such as the INCITS standard
for role based access control
4
, and has become the basis for an
increasing range of products. But beyond the basic scheme of
associating attributes with subjects, objects, and environments,
there has been little consistency among ABAC
implementations.
ABAC Definition and Considerations for Enterprise
environment
Due to a lack of consensus on ABAC features, users cannot
accurately assess the benefits and challenges associated with
ABAC. A comprehensive definition and guide to
implementing ABAC within the federal government is
provided by NIST Special Publication (SP) 800-162, Guide to
Attribute Based Access Control (ABAC) Definition and
Considerations
1
. This document serves a two-fold purpose.
First, it provides federal agencies with a definition of ABAC
and a description of the functional components of ABAC.
Second, it provides planning, design, implementation, and
operational considerations for employing ABAC within an
enterprise to improve information sharing while maintaining
control of that information. The Guide to Attribute Based
Access Control focuses on the challenges of implementing
ABAC rather than on balancing the cost and effectiveness of
other capabilities versus ABAC.
When deployed across an enterprise to increase information
sharing among diverse organizations, ABAC implementations
can become complex—supported by the existence of an
attribute management infrastructure, machine-enforceable
policies, and an array of functions that support access
decisions and policy enforcement (figure 1). In addition to the
basic policy, attribute, and AC mechanism requirements, the
enterprise must support management functions for enterprise
policy development and distribution, enterprise identity and
subject attributes, subject attribute sharing, enterprise object
attributes, authentication, and AC mechanism deployment and
distribution. The development and deployment of these
capabilities requires the careful consideration of a number of
factors that will influence the design, security, and
interoperability of an enterprise ABAC solution. These factors
can be summarized around a set of activities:
Figure 1. ABAC example.
• Establish the Business Case for ABAC Implementation.
• Understand the Operational Requirements and Overall
ABAC Enterprise Architecture;
• Establish or Refine Business Processes to Support ABAC;
• Develop and Acquire an Interoperable Set of ABAC
Capabilities;
• Operate with Efficient ABAC processing.
From the above activities, NIST SP 800-162
1
helps
ABAC system planners, architects, managers, and
implementers fulfill the information sharing and protection
requirements by discussion on ABAC enterprise
implementation considerations in four phases:
Initiation Phase including considerations for Building the
Business Case for Deploying ABAC Capabilities, Scalability,
Feasibility, and Performance Requirements, and Developing
Operational Requirements and Architecture.
Acquisition/Development Phase including considerations for
Business Process Generation and Deployment Preparation,
System Development and Solution Acquisition Considerations,
and Other Enterprise ABAC Capabilities.
Implementation/Assessment Phase including considerations
for Attribute Caching, Attribute Source Minimization, and
ABAC Interface Specifications.
Operations/Maintenance Phase including considerations for
Availability of Quality ABAC Data.
Attribute Assurance
The
metadata of ABAC attributes communicate aspects of
attributes are an important area of focus for attribute
standardization. By coupling a common set of mandatory and
optional metadata with attribute assertions, ABAC systems
can interrogate attribute information to make their own risk
based decisions, especially when delivered via a broker that
has many attribute systems connected to it. In general,
attribute metadata can be broken down by:
Accuracy establishes the policy and technical underpinings
for semantically and syntactically correct use of these
attributes and Environmental conditions, and ensures that the
reported attributes are trustworthy, based on the trust
established in the measurement and reporting processes.
Integrity considers different standards and protocols used for
secure sharing of attributes between systems in order to avoid
compromising the integrity and confidentiality of the
attributes or exposing vulnerabilities in provider or relying
systems or entities.
Availability ensures that the update and retrieval of attributes
support the RP to which the attributes are used. In addition,
the fail-over and backup capability of attribute repositories
needs to be considered. Note that some attributes may change
regularly or over time.
An Attribute Provider (AP) is any person or system that
provides subject, object (or resource), or environmental
condition attributes regardless of transmission method. The
AP may be the original authoritative source, or receiving
information from an authoritative source for repacking and
store-and-forward to ABAC system. And attribute values may
be human generated (e.g., an employee database) or derived
from formulas (e.g., a credit score). Regardless of the source
of the AP’s attributes, an ABAC system should ensure that the
attribute value received from an AP is accurately associated
with the subject, object, or environmental condition to which
it applies.
2
Table 1 illustrates an example Level of Attribute
Assurance (LOAA) metric categorized by the levels of
attribute assurance (row) based on the Accuracy, Integrity, and
Availability properties.
Table 1 Assurance Level Mappings Example
LO
AA Accuracy Integrity Availability
1 *Attributes are properly
verified for veracity
through provision and
management.
*Secure attribute
repository.
*Secure
communication
between APs and
RPs.
*Attribute refresh
frequency meets
the system
performance
requirement.
2 *Includes Level 1.
*Documented rule or
standards for attribute
value assignment and
definition (syntax and
semantic rule).
*Includes Level 1.
*Dedicated attribute
repositories.
*Includes Level 1.
*Attribute
caching during
run time meets the
system
performance
requirement.
3 *Includes Level 2.
*Attributes cover all
protection policy
requirements of the
organization. (Semantically
complete).
*Includes Level 2.
*Encrypted attribute
values and
communications
between APs and
RPs.
*Includes Level 2.
*Fail-over or back
up attributes
support.
4 *Includes Level 3.
*Attributes are under
federated or unified
governance.
*Includes Level 3.
*Formal rules or
policy (or standards)
for create, update,
modify, and delete
attributes.
*Includes Level 3.
*Log for attribute
changes and
access.
ABAC has the potential to dramatically improve control
and flexibility for access control in modern applications such
as e-commerce and the “internet of things”. But a consensus
definition has been needed, and work remains to be done in
assuring the accuracy and reliability of attributes. For more
information, see http://csrc.nist.gov/projects/abac/index.html.
References
1. V. C. Hu et al., Guide to Attribute Based Access Control (ABAC)
Definition and Considerations NIST Special Publication 800-162.
2. V. C. Hu et al., Attribute Consideration, Internet Society (ISOC) position
paper, 2014.
3.http://www.avatier.com/products/identity-management/resources/gartner-
iam-2020-predictions/
4. D.R. Kuhn, E.J. Coyne, T.R. Weil, "Adding Attributes to Role Based
Access Control", IEEE Computer, June, 2010, pp. 79-81.
