NIST Special Publication 800-162

Guide to Attribute Based AccessControl (ABAC) Definition andConsiderations
Vincent C. Hu
David Ferraiolo
Rick Kuhn
Adam Schnitzer
Kenneth Sandlin
Robert Miller
Karen Scarfone
This publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-162

C O M P U T E R

S E C U R I T Y

NIST Special Publication 800-162

Guide to Attribute Based AccessControl (ABAC) Definition andConsiderations
Vincent C. Hu
David Ferraiolo
Rick Kuhn
Computer Security Division
Information Technology Laboratory
Adam Schnitzer
Booz Allen Hamilton
Kenneth Sandlin
Robert Miller
The MITRE Corporation
Karen Scarfone
Scarfone Cybersecurity
Clifton, VAThis publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-162

January 2014

INCLUDES UPDATES AS OF 08-02-2019; SEE PAGE IX

U.S. Department of Commerce

Penny Pritzker, Secretary

National Institute of Standards and Technology
Patrick D. Gallagher, Under Secretary of Commerce for Standards and Technology and Director

Authority
This publication has been developed by NIST to further its statutory responsibilities under the Federal
Information Security Management Act (FISMA), Public Law (P.L.) 107-347. NIST is responsible fordeveloping information security standards and guidelines, including minimum requirements for Federal
information systems, but such standards and guidelines shall not apply to national security systems
without the express approval of appropriate Federal officials exercising policy authority over such
systems. This guideline is consistent with the requirements of the Office of Management and Budget(OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in Circular A130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in Circular A-130,
Appendix III, Security of Federal Automated Information Resources.
Nothing in this publication should be taken to contradict the standards and guidelines made mandatory
and binding on Federal agencies by the Secretary of Commerce under statutory authority. Nor should
these guidelines be interpreted as altering or superseding the existing authorities of the Secretary ofCommerce, Director of the OMB, or any other Federal official. This publication may be used bynongovernmental organizations on a voluntary basis and is not subject to copyright in the United States.
Attribution would, however, be appreciated by NIST.
National Institute of Standards and Technology Special Publication 800-162
Natl. Inst. Stand. Technol. Spec. Publ. 800-162, 47 pages (January 2014)
CODEN: NSPUE2This publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-162
Certain commercial entities, equipment, or materials may be identified in this document in order todescribe an experimental procedure or concept adequately. Such identification is not intended to imply
recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or
equipment are necessarily the best available for the purpose.
There may be references in this publication to other publications currently under development by NIST in
accordance with its assigned statutory responsibilities. The information in this publication, including
concepts and methodologies, may be used by Federal agencies even before the completion of suchcompanion publications. Thus, until each publication is completed, current requirements, guidelines, andprocedures, where they exist, remain operative. For planning and transition purposes, Federal agencies may
wish to closely follow the development of these new publications by NIST.
Organizations are encouraged to review all draft publications during public comment periods and provide
feedback to NIST. All NIST Computer Security Division publications, other than the ones noted above, areavailable at https://csrc.nist.gov/publications.

Comments on this publication may be submitted to:
National Institute of Standards and Technology
Attn: Computer Security Division, Information Technology Laboratory
100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930
Email: sp800-162-comments@nist.gov

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

Reports on Computer Systems Technology
The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s
measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof ofconcept implementations, and technical analyses to advance the development and productive use of
information technology. ITL’s responsibilities include the development of management, administrative,
technical, and physical standards and guidelines for the cost-effective security and privacy of other thannational security-related information in Federal information systems. The Special Publication 800-series
reports on ITL’s research, guidelines, and outreach efforts in information system security, and its
collaborative activities with industry, government, and academic organizations.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Abstract
This document provides Federal agencies with a definition of attribute based access control (ABAC).
ABAC is a logical access control methodology where authorization to perform a set of operations isdetermined by evaluating attributes associated with the subject, object, requested operations, and, in somecases, environment conditions against policy, rules, or relationships that describe the allowable operations
for a given set of attributes. This document also provides considerations for using ABAC to improveinformation sharing within organizations and between organizations while maintaining control of that
information.

Keywords
access control; access control mechanism; access control model; access control policy; attribute based
access control (ABAC); authorization; privilege.

iii

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

Acknowledgements

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

The authors, Vincent C. Hu, David Ferraiolo, and Rick Kuhn of the National Institute of Standards andTechnology (NIST); Adam Schnitzer of Booz Allen Hamilton; Kenneth Sandlin and Robert Miller of The
MITRE Corporation; and Karen Scarfone of Scarfone Cybersecurity, wish to thank their colleagues who
reviewed drafts of this document, including the following: Arthur R. Friedman, Alan J. Lang, Margaret
M. Cogdell, and Kevin Miller from the National Security Agency (NSA), Jeffery L. Coleman (SOTERA
Defense Solutions), Anne P. Townsend (The MITRE Corporation), Jennifer Newcomb (Booz Allen
Hamilton), Tim Weil (Coalfire), Ed Coyne (DRC), John W. Tolbert (Boeing), Jeremy Wyant (General
Dynamics), Ian Glazer (Gartner), Scott C. Fitch (Lockheed Martin), Tim Schmoyer (Jericho Systems),
Luigi Logrippo (Université du Québec en Outaouais), Dave Coxe (Criterion Systems), Don Graham(Radiant Logic), and Ronald Ross, and Ramaswamy Chandramouli (NIST). Additionally, the NIST
Computer Security Division would like to thank Mr. Friedman for initiating this effort and having theforesight to anticipate the growing importance of Attribute Based Access Control in government andindustry.
The authors also gratefully acknowledge and appreciate the comments and contributions made bygovernment agencies, private organizations, and individuals in providing direction and assistance in thedevelopment of this document.

Trademark Information
All registered trademarks or trademarks belong to their respective organizations.

iv

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

Table of Contents
Executive Summary ................................................................................................................... vii
1.

2.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

3.

Introduction............................................................................................................................ 1
1.1

Purpose and Scope ....................................................................................................... 1

1.2

Audience ......................................................................................................................... 1

1.3

Document Structure ...................................................................................................... 1

1.4

Notes on Terminology ................................................................................................... 2

Understanding ABAC .......................................................................................................... 4
2.1

The Benefit of ABAC ..................................................................................................... 5

2.2

A Working Definition of ABAC ..................................................................................... 6

2.3

Basic ABAC Concepts .................................................................................................. 8

2.4

Enterprise ABAC Concepts........................................................................................ 11

2.4.1

Enterprise ABAC Policy ...................................................................................... 12

2.4.2

Attribute Management in Enterprise ABAC...................................................... 13

2.4.3

Access Control Mechanism Distribution in Enterprise ABAC ....................... 14

ABAC Enterprise Considerations .................................................................................... 17
3.1

Initiation Phase Considerations ................................................................................. 18

3.1.1

Building the Business Case for Deploying ABAC Capabilities ..................... 18

3.1.2

Scalability, Feasibility, and Performance Requirements................................ 19

3.1.3

Developing Operational Requirements and Architecture .............................. 22

3.2

Considerations during the Acquisition/Development Phase ................................. 25

3.2.1

Business Process Generation and Deployment Preparation ........................ 25

3.2.2

System Development and Solution Acquisition Considerations ................... 27

3.2.3

Considerations for Other Enterprise ABAC Capabilities ................................ 30

3.3

Considerations during the Implementation/Assessment Phase .......................... 31

3.3.1

Attribute Caching .................................................................................................. 31

3.3.2

Attribute Source Minimization ............................................................................ 31

3.3.3

Interface Specifications ....................................................................................... 32

3.4

Considerations during the Operations/Maintenance Phase ................................. 32

3.4.1
4.

Availability of Quality Data .................................................................................. 32

Conclusion ........................................................................................................................... 33

Appendix A — Acronyms and Abbreviations ......................................................................... 34
Appendix B — References ....................................................................................................... 36v

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

List of Figures
Figure 1: Traditional (Non-ABAC) Multi-Organizational Access Method ................................... 6
Figure 2: Basic ABAC Scenario ..................................................................................................... 8
Figure 3: Core ABAC Mechanisms ................................................................................................ 9
Figure 4: Enterprise ABAC Scenario Example ............................................................................ 12
Figure 5: An Example of ACM Functional Points ....................................................................... 15
Figure 6: ACM NIST System Development Life Cycle (SDLC) ................................................. 17
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Figure 7: ACL Trust Chain ........................................................................................................... 21
Figure 8: ABAC Trust Chain ........................................................................................................ 22vi

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

Executive Summary

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

The concept of Attribute Based Access Control (ABAC) has existed for many years. It represents a pointin the space of logical access control that includes access control lists, role-based access control, and the
ABAC method for providing access based on the evaluation of attributes. Traditionally, access control 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 orgroups assigned to that user. Practitioners have noted that this approach to access control is often
cumbersome to manage given the need to associate capabilities directly to users or their roles or groups. It
has also been noted that the requester qualifiers of identity, groups, and roles are often insufficient in theexpression of real-world access control policies. An alternative is to grant or deny user requests based on
arbitrary attributes of the user and arbitrary 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.
In November 2009, the Federal Chief Information Officers Council (Federal CIO Council) published theFederal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Plan v1.0
[FEDCIO1], which provided guidance to federal organizations to evolve their logical access control
architectures to include the evaluation of attributes as a way to enable access within and between
organizations across the Federal enterprise. In December 2011, the FICAM Roadmap and Implementation
Plan v2.0 [FEDCIO2] took the next step of calling out ABAC as a recommended access control model for
promoting information sharing between diverse and disparate organizations. In December 2012, theNational Strategy for Information Sharing and Safeguarding included a Priority Objective that the Federal
Government should extend and implement the FICAM Roadmap across Federal networks in all security
domains. The U.S. General Services Administration (GSA) and the Federal CIO Council are designatedleads for this Objective, and are preparing an implementation plan.
Despite the clear guidance to implement the FICAM Roadmap and contextual (risk adaptive) role orattribute based access control, to date there has not been a comprehensive effort to formally define or
guide the implementation of ABAC within the Federal Government. This document serves a two-foldpurpose. First, it aims to provide Federal agencies with a definition of ABAC and a description of thefunctional components of ABAC. Second, it provides planning, design, implementation, and operational
considerations for employing ABAC within an enterprise with the goal of improving information sharing
while maintaining control of that information. This document should not be interpreted as an analysis ofalternatives between ABAC and other access-control capabilities, as it focuses on the challenges of
implementing ABAC rather than on balancing the cost and effectiveness of other capabilities versus
ABAC.
ABAC is a logical access control 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 systems are capable of enforcing both Discretionary Access Control (DAC)and Mandatory Access Control (MAC) concepts. ABAC enables precise access control, which allows fora higher number of discrete inputs into an access control decision, providing a bigger set of possiblecombinations of those variables to reflect a larger and more definitive set of possible rules to express
policies.
The access control policies that can be implemented in ABAC are limited only by the computational
language and the richness of the available attributes. This flexibility enables the greatest breadth ofsubjects to access the greatest breadth of objects without specifying individual relationships between eachsubject and each object. For example, a subject is assigned a set of subject attributes upon employment

vii

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS(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 orowner of an object creates an access control rule using attributes of subjects and objects to govern the setof 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 access control management capability and limits long-term
maintenance requirements of object protections.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Further, ABAC enables object owners or administrators to apply access control policy without priorknowledge 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. 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.
When deployed across an enterprise for the purposes of increasing 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 accessdecisions and policy enforcement.
In addition to the basic policy, attribute, and access control mechanism requirements, the enterprise must
support management functions for enterprise policy development and distribution, enterprise identity andsubject attributes, subject attribute sharing, enterprise object attributes, authentication, and access control
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, andinteroperability of an enterprise ABAC solution. These factors can be summarized around a set of
activities:
•
•
•
•
•

Establish the Business Case for ABAC Implementation
Understand the Operational Requirements and Overall Enterprise Architecture
Establish or Refine Business Processes to Support ABAC
Develop and Acquire an Interoperable Set of Capabilities
Operate with Efficiency

The remainder of this document provides a more detailed explanation of ABAC concepts andconsiderations for employment of enterprise ABAC capabilities. This document serves as a first step tohelp planners, architects, managers, and implementers fulfill the information sharing and protection
requirements of the U.S. Federal Government, through the employment of ABAC.

viii

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

ErrataThis table contains changes that have been incorporated into Special Publication (SP) 800-162.
Errata updates can include corrections, clarifications, or other minor changes in the publicationthat are either editorial or substantive in nature.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Date

Type

Change02-25-2019

Editorial

Updated DOI and availability statement on all
pages.

All

02-25-2019

Editorial

Replaced references to NIST SP 800-63-1 and
800-63-2 with references to SP 800-63-3 and SP
800-63B.

1, 27, 37

02-25-2019

Editorial

Updated several references in Appendix B toreflect the current versions of those documents.

36-37

08-02-2019

Substantive

Updated Figure 8, ABAC Trust Chain, to include
Environment Conditions as an input to the AccessControl Decision.

22

ix

Pages

NIST SP 800-162

1.

Introduction

1.1

Purpose and Scope

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONSThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

The purpose of this document is to provide Federal agencies with a definition of Attribute Based AccessControl (ABAC) and provide considerations for using ABAC to improve information sharing while
maintaining control of that information. This document describes the functional components of ABAC, aswell as a set of issues for employing ABAC within a large enterprise without directly addressing
authentication mechanisms or all aspects of Identity Management 1, thus assuming subjects are bound totrusted identities or identity providers. The focus is on core ABAC concepts without addressing in detail
topics such as Attribute Engineering/Management, Integration with Identity Management, Federation,
Situational Awareness (Real Time or Contextual) Mechanism, Policy Management, and Natural Language
Policy translation to Digital Policy. The discussed considerations should not be deemed comprehensive.
Before selecting and deploying an ABAC product or technology, the hosting organization should augment
these considerations with testing and independent product reviews.
This document brings together many previously separate bodies of ABAC knowledge in order to bridge
gaps between available technology and best practice ABAC implementations, and strives to provide
guidelines that can be consistently applied throughout organizations. It can be used as an informationalguide for organizations that are considering deploying, planning to deploy, or are currently deploying
ABAC systems.
This guidance extends the information in NISTIR 7316, Assessment of Access Control Systems[NIST7316]; NISTIR 7665, Proceedings of the Privilege Management Workshop [NIST7665]; NISTIR
7657, A Report on the Privilege (Access) Management Workshop [NIST7657]; and NISTIR 7874,
Guidelines for Access Control System Evaluation Metrics [NIST7874], which demonstrates thefundamental concepts of policy, models, and properties of Access Control (AC) systems.
1.2

Audience

This document is intended to benefit and address the needs of two specific audiences:••
1.3

Persons who have a basic understanding of access control concepts and desire a general
understanding of ABAC concepts
Access control subject matter experts or managers experienced in access control concepts who areseeking detailed deployment or operational information on ABAC
Document Structure

The rest of this document is divided into the following sections and appendixes:• Section 2 provides a basic understanding of ABAC. It gives readers an overview of the current
state of logical access control, a working definition of ABAC, and an explanation of core andenterprise level ABAC concepts. Readers can gain a general understanding of ABAC concepts
from just completing Section 2.
• Section 3 discusses ABAC enterprise employment considerations during the initiation,acquisition/development, implementation/assessment, and operations/maintenance phases.
Readers with an interest in access control and/or project management will benefit most from thissection.
1

See [NIST800-63-3] and [NIST800-63B].

1

NIST SP 800-162•••

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

Section 4 concludes the document.
Appendix A defines various acronyms and abbreviations related to ABAC.
Appendix B lists the references for the document.

Because of the constantly changing nature of the IT industry, readers are strongly encouraged to takeadvantage of other resources, including those referenced in this document.
1.4

Notes on Terminology

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

The terminology is not meant to be mandatory, but is intended to be consistent within the confines of the
document itself. Where possible, terminology that is used elsewhere within NIST publications and acrossthe Federal Government was adopted to maintain consistency. Where terms were found to be usedinconsistently or where multiple terms were being used throughout the Federal Government and theIdentity and Access Control community to address a common concept, the most concise terms anddefinitions were applied.
A logical object—sometimes referred to as a resource—is an entity to be protected from unauthorizeduse. The subject represents the entity requesting to perform an operation upon the object. The subject issometimes referred to as a requestor.
The subject is most often assumed to be a human. A non-person entity (NPE), such as an autonomous
service or application could also fill the role of the subject. In general, every operation performed by acomputer must be done on behalf of some person or organization (in the case of an NPE) with the authority
to perform the operation. The term subject is used to denote a human or NPE requesting access to an
object.
There are characteristics or attributes of a subject such as name, date of birth, home address, training
record, and job function that may, either individually or when combined, comprise a unique identity that
distinguishes that person from all others. These characteristics are often called subject attributes. The
term subject attributes is used consistently throughout this document.
In the course of a person’s life, he or she may work for different organizations, may act in different roles,
and may inherit different privileges tied to those roles. The person may establish different personas foreach organization or role and amass different attributes related to each persona. For example, an individual
may work for Company A as a gate guard during the week and may work for Company B as a shift
manager on the weekend. The subject attributes are different for each persona. Although trained andqualified as a Gate Guard for Company A, while operating in her Company B persona as a shift manager
on the weekend she does not have the authority to perform as a Gate Guard for Company B.
Authentication is not the same as access control or authorization. Authentication is the act of verifyingthat the subject has been authorized to use the presented identifier by a trusted identity provider
organization. Access control or authorization, on the other hand, is the decision to permit or deny a
subject access to system objects (network, data, application, service, etc.) Note that ABAC can be usedwithout identification information, and authentication method is not addressed in this document. The terms
access control and authorization are used synonymously throughout this document.
Privileges represent the authorized behavior of a subject; they are defined by an authority and embodiedin policy or rules. For the purposes of this document, the terms privileges and authorizations are usedinterchangeably in that they are meant to convey one’s authority and implicit approval to access one ormore objects.

2

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

Environment conditions are dynamic factors, independent of subject and object, that may be used as
attributes at decision time to influence an access decision. Examples of environment conditions include
time, location, threat level, and temperature.
Policy, rules, and relationships govern allowable behavior within an organization, based on theprivileges of subjects and how resources or objects are to be protected under which environment
conditions. Throughout this document, the term policy is used to convey these rules and relationships.
Policy is typically written from the perspective of the object that needs protecting and the privileges
available to subjects.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Like subjects, each object has a set of attributes that help describe and identify it. These traits are calledobject attributes and are sometimes referred to as resource attributes. This document uses the term
object attributes consistently throughout. Object attributes are typically bound to their objects throughreference, by embedding them within the object, or through some other means of assured association suchas cryptographic binding. 2
Information about policy, such as author, policy effective date, deconflict methods, etc. are sometimes
called metapolicy. Information about attributes such as attribute authority, attribute creation date, etc. aresometimes called metaattributes. Metapolicy and metaattributes may be used in the development of setsof policies and the identification of the appropriate attribute sets needed for authorization. A good exampleof the use of a metaattribute is assigning an assurance level or measure of confidence to the attribute—acomposite score for an attribute that could combine subjective ratings like a confidence score for theauthority behind the attribute, a freshness score of the information in the attribute, and a level of accuracy
score for how often the information is validated. At times, these measures of confidence may even be used
as input to the access decision.
These policies must be enforced through some type of access control mechanism. The access control
mechanism must assemble authorization information, which may include information about the object
being protected, the subject requesting access, the policies governing access to the resource, and any
contextual information needed to make a decision. By evaluating each policy element against the available
information, the access control mechanism often employs a policy decision point (PDP) to render adecision, a policy enforcement point (PEP) to enforce the decision, and some sort of context handler orworkflow coordinator to manage the collection of attributes required for the decision. For the purposes ofthis document, it is assumed that the term access control mechanism incorporates all of this functionality,
and the term is used throughout.

2

Cryptographic binding is a methodology for providing integrity and authenticity to data and data relationships using wellknown cryptographic techniques. Cryptographic binding works by determining the hash value of each object attributeassociated with a specific object and digitally signing the collection of hashed values. When the object is accessed, if theobject signature fails, the attribute hash values are then compared to determine which element was modified since the lastbinding operation.

3

NIST SP 800-162

2.

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

Understanding ABAC

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Fully understanding ABAC requires understanding of the basic principles of logical access control. The
purpose of logical access control is to protect objects—be they data, services, executable applications,network devices, or some other type of information technology—from unauthorized operations. These
operations may include discovering, reading, creating, editing, deleting, and executing objects. These
objects are owned by an individual or organization and have some inherent value that motivates thoseowners to protect them. As owners of the objects, they have the authority to establish a policy that
describes what operations may be performed upon those objects, by whom, and in what context thosesubjects may perform those operations. If the subject satisfies the access control policy established by theobject owner, then the subject is authorized to perform the desired operation on that object—better known
as being granted access to the object. If the subject does not satisfy the policy, then it is denied access tothe object.
Computer security architects and administrators deploy access control mechanisms (ACM) in logicaligned to protect their objects by mediating requests from subjects. These ACMs can use a variety ofmethods to enforce the access control policy that applies to those objects. The ACM can be defined as:
Access Control Mechanism (ACM): The logical component that serves to receive the accessrequest from the subject, to decide, and to enforce the access decision.
How these ACMs function can be described in terms of various logical access control models. These
access control models provide a framework and set of boundary conditions upon which the objects,
subjects, operations, and rules may be combined to generate and enforce an access control decision. Eachmodel has its own advantages and limitations but it is important to note the evolution of these models to
fully appreciate the flexibility and applicability of the ABAC model.
MAC/DACAn early application of logical access control was applied in Department of Defense (DoD) applicationsin the 1960s and 1970s with the emergence of the concepts of Discretionary Access Control (DAC) andMandatory Access Control (MAC). These terms are further defined in the DoD Trusted Computer System
Evaluation Criteria (TCSEC) or “Orange Book” [TCSEC]. The definition of DAC and MAC can be also
found in [NIST800-53].
IBAC/ACLs
As networks grew, the need to limit access to specific protected objects spurred the growth of identity
based access control (IBAC) capabilities. IBAC employs mechanisms such as access control lists (ACLs)
to capture the identities of those allowed to access the object. If a subject presents a credential thatmatches the one held in the ACL, the subject is given access to the object. Individual privileges of thesubject to perform operations (read, write, edit, delete, etc.) are managed on an individual basis by theobject owner. Each object needs its own ACL and set of privileges assigned to each subject. In the IBAC
model, the authorization decisions are made prior to any specific access request and result in the subject
being added to the ACL. For each subject to be placed on an ACL, the object owner must evaluate
identity, object, and context attributes against policy governing the object and decide whether to add thesubject to the ACL. This decision is static and a notification process is required for the owner to reevaluate
and perhaps remove a subject from the ACL to represent subject, object, or contextual changes. Failure to
remove or revoke access over time leads to users accumulating privileges.

4

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

RBAC
Role-Based Access Control model (RBAC) [FK92, ANSI359, SCFY96] employs pre-defined roles thatcarry a specific set of privileges associated with them and to which subjects are assigned. For example, asubject assigned the role of Manager will have access to a different set of objects than someone assigned
the role of Analyst. In this model, access is implicitly predetermined by the person assigning the roles toeach individual and explicitly by the object owner when determining the privilege associated with eachrole. At the point of an access request, the access control mechanism evaluates the role assigned to thesubject requesting access and the set of operations this role is authorized to perform on the object before
rendering and enforcing an access decision. Note that a role may be viewed as a subject attribute that isevaluated by the access control mechanism and around which object access policy is generated. As the
RBAC specification gained popularity, it made central management of enterprise access control
capabilities possible and reduced the need for ACLs.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

ABAC
ACLs and RBAC are in some ways special cases of ABAC in terms of the attributes used. ACLs work on
the attribute of “identity”. RBAC works on the attribute of “role”. The key difference with ABAC is theconcept of policies that express a complex Boolean rule set that can evaluate many different attributes.
While it is possible to achieve ABAC objectives using ACLs or RBAC, demonstrating AC requirementscompliance is difficult and costly due to the level of abstraction required between the AC requirements
and the ACL or RBAC model. Another problem with ACL or RBAC models is that if the AC requirement
is changed, it may be difficult to identify all the places where the ACL or RBAC implementation needs tobe updated.
One example of an access control framework that is consistent with ABAC is the Extensible Access Control
Markup Language (XACML) [XACML]. The XACML model employs elements such as rules, policies,
rule- and policy-combining algorithms, attributes (subject, (resource) object, action and environment
conditions), obligations, and advice. Its reference architecture includes functions such as Policy Decision
Points (PDPs), Policy Enforcement Points (PEPs), Policy Administration Points (PAPs), and Policy
Information Points (PIPs) to control access. Another example is the Next Generation Access Control
standard [ANSI499].
In general, ABAC avoids the need for capabilities (operation/object pairs) to be directly assigned tosubject requesters or to their roles or groups before the request is made. Instead, when a subject requests
access, the ABAC engine can make an access control decision based on the assigned attributes of therequester, the assigned attributes of the object, environment conditions, and a set of policies that are
specified in terms of those attributes and conditions. Under this arrangement policies can be created andmanaged without direct reference to potentially numerous users and objects, and users and objects can beprovisioned without reference to policy.
2.1

The Benefit of ABAC

In many AC systems, logical access control solutions have been based primarily on the identity of a
subject requesting execution of an operation (e.g., read) upon an object (e.g., a file). Examples include
IBAC or RBAC where access to an object has been individually granted to a locally identified subject, or
when access to an object has been granted to locally defined roles that the subject is a member of. Thisapproach to AC is often cumbersome to manage. In this non-ABAC multi-organizational access method
example (illustrated below in Figure 1), authenticated access to objects outside of the subject’s originatingorganization would require the subject’s identity to be pre-provisioned in the target organization and prepopulated on an access list.

5

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONSThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Figure 1: Traditional (Non-ABAC) Multi-Organizational Access Method

Additionally, the subject qualifiers, such as identity and roles, are often insufficient in the expression ofreal-world AC needs. RBAC makes a decision based on the subject’s association with a role. RBAC does
not easily support multi-factor decisions (for example, decisions dependent on physical location, andspecialized training such as for Health Insurance Portability and Accountability Act (HIPAA) records
access; recent training on HIPAA data protection may be a prerequisite to view medical records.) RBAC
role assignments tend to be based upon more static organizational positions, presenting challenges incertain RBAC architectures where dynamic access control decisions are required. Trying to implement
these kinds of access control decisions would require the creation of numerous roles that are ad hoc andlimited in membership, leading to what is often termed “role explosion”.
A method is needed to make AC decisions without previous knowledge of the object by the subject or
knowledge of the subject by the object-owner. By relying upon the concepts of subject and object
attributes consistently defined between organizations, ABAC avoids the need for explicit authorizations to
be directly assigned to individual subjects prior to a request to perform an operation on the object.
Moreover, this model enables flexibility in a large enterprise where management of access control lists orroles and groups would be time consuming and complex. Leveraging consistently defined attributes thatspan both subjects and objects, authentication and authorization activities can be executed andadministered in the same or separate infrastructures, while maintaining appropriate levels of security.
2.2

A Working Definition of ABACABAC has been described in various ways. For example, one early paper on web services states that
ABAC “grants accesses to services based on the attributes possessed by the requester” [WWJ04], while a
discussion of security in geographic information systems describes ABAC as an approach in which“attribute values associated with users determine the association of users with privileges” [CGLO09].
Still another paper summarizes ABAC as a model that is “based on subject, object, and environment
attributes and supports both mandatory and discretionary access control needs” [YT05]. In these and otherdefinitions, there is a reasonable consensus that ABAC determines access (i.e., operations upon system

6

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

objects) by matching the current value of subject attributes, object attributes, and environment conditions
with the requirements specified in access control rules. The following is a high-level definition of ABAC:
Attribute Based Access Control (ABAC): An access control method where subject requests to perform
operations on objects are granted or denied based on assigned attributes of the subject, assigned
attributes of the object, environment conditions, and a set of policies that are specified in terms of those
attributes and conditions.
Attributes are characteristics of the subject, object, or environment conditions. Attributes contain
information given by a name-value pair.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

A subject is a human user or NPE, such as a device that issues access requests to perform operations
on objects. Subjects are assigned one or more attributes. For the purpose of this document, assume
that subject and user are synonymous.
An object is a system resource for which access is managed by the ABAC system, such as devices,
files, records, tables, processes, programs, networks, or domains containing or receiving information.
It can be the resource or requested entity, as well as anything upon which an operation may be
performed by a subject including data, applications, services, devices, and networks.
An operation is the execution of a function at the request of a subject upon an object. Operations
include read, write, edit, delete, copy, execute, and modify.
Policy is the representation of rules or relationships that makes it possible to determine if a requested
access should be allowed, given the values of the attributes of the subject, object, and possibly
environment conditions.
Environment conditions: operational or situational context in which access requests occur. Environment
conditions are detectable environmental characteristics. Environment characteristics are independent ofsubject or object, and may include the current time, day of the week, location of a user, or the current
threat level.
The high-level ABAC definition is depicted in Figure 2 where the ABAC ACM receives the subject’s
access request, then examines the subject’s and object’s attributes against a specific policy. The ACM thendetermines what operations the subject may perform upon the object.

7

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

Access Control
PolicyEnvironment
Conditions
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

2d

2a
rules

Decision

1

Enforce

3
Subject

ABAC
Access Control
Mechanism

2b

Name

Affiliation

Etc.

Clearance

2c

Type
Etc.

Subject Attributes

Object

Owner

Classification

Object Attributes

1. Subject requests access to object
2. Access Control Mechanism evaluates a) Rules, b) Subject Attributes, c) Object Attributes, andd) Environment Conditions to compute a decision
3. Subject is given access to object if authorized
Figure 2: Basic ABAC Scenario

2.3

Basic ABAC Concepts

In its most basic form, ABAC relies upon the evaluation of attributes of the subject, attributes of theobject, environment conditions, and the formal relationship or access control rule or policy defining theallowable operations for subject-object attribute combinations. All ABAC solutions contain these basic

8

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

core capabilities to evaluate attributes and enforce rules or relationships between those attributes (seeFigure 3 below).

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Figure 3: Core ABAC Mechanisms

Even within a small isolated system, ABAC relies upon the assignment of attributes to subjects andobjects, and the development of policy that contains the access rules. Each object within the system must
be assigned specific object attributes that characterize the object. Some attributes pertain to the entire
instance of an object, such as the owner. Other attributes may only apply to parts of the object. For
example, a document object could be owned by organization A, have a section with intellectual property
from organization B, and be part of a program run by organization C. As another example, consider adocument residing in a directory within a file management system. This document has a title, an author, adate of creation, and a date of last edit—all object attributes that are determined by the creator, author, or
editor of the document. Additional object attributes may be assigned such as owning organization,
intellectual property characteristics, export control classification, or security classification. Each time a

9

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

new document is created or modified, these object attributes must be captured. These object attributes areoften embedded within the document itself, but they may be captured in a separate table, incorporated byreference, or managed by a separate application.
Each subject that uses the system must be assigned specific attributes. Consider the example of a user
accessing a file management system. The user is established as a subject within the system by anadministrator and characteristics about that user are captured as subject attributes. This subject may have a
name, a role, and an organization affiliation. Other subject attributes may include US Person status,
nationality, and security clearance. These subject attributes are assigned and managed by an authority
within the organization that maintains the subject identity information for the file management system. As
new users arrive, old users leave, and characteristics of subjects change, these subject attributes may need
to be updated.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Every object within the system must have at least one policy that defines the access rules for the allowablesubjects, operations, and environment conditions to the object. This policy is normally derived fromdocumented or procedural rules that describe the business processes and allowable actions within theorganization. For example, in a hospital setting, a rule may state that only authorized medical personnel
shall be able to access a patient’s medical record. In some system, if the object is a document with a Record
Type Attribute of Patient Medical Record, then the Medical Record Rule will be selected and processed so thatthe subject with a Personnel Type Attribute value of Non-Medical Support Staff trying to perform the Read
operation will be denied access and the operation will be disallowed. Note that this is only one approach to
implementing the connection between attributes and rules.
The rules that bind subject and object attributes indirectly specify privileges (i.e., which subjects canperform which operations on which objects). Allowable operation rules can be expressed through many
forms of computational language such as:• A Boolean combination of attributes and conditions that satisfy the authorization for a specificoperation• A set of relations associating subject and object attributes and allowable operations
Once object attributes, subject attributes, and policies are established, objects can be protected using
ABAC. Access control mechanisms mediate access to the objects by limiting access to allowable
operations by allowable subjects. The ACM assembles the policy, subject attributes, and object attributes,
then renders and enforces a decision based on the logic provided in the policy. ACMs must be able tomanage the process required to make and enforce the decision, including determining what policy toretrieve, which attributes to retrieve in what order, and where to retrieve attributes. The ACM must thenperform the computation necessary to render a decision.
The policies that can be implemented in an ABAC model are limited only to the degree imposed by thecomputational language and the richness of the available attributes. This flexibility enables the greatest
breadth of subjects to access the greatest breadth of objects without having to specify 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). A designated authority creates rules to govern the set of allowable operations (e.g., all Nurse
Practitioners in the Cardiology Department can View the Medical Records of Heart Patients). Adding to
the flexibility, attributes and their values may then be modified throughout the lifecycle of subjects,
objects, and attributes.

10

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONSProvisioning attributes to subjects and objects governed by a ruleset that specifies what operations cantake place enables an unlimited number of subjects to perform operations on the object—all without priorknowledge of the specific subject by the object-owner or rule-maker. As new subjects join theorganization, rules and objects do not need to be modified. 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 areassigned those attributes), no modifications to existing rules or object attributes are required. This benefit
is often referred to as accommodating the external (unexpected) user and is one of the primary benefits of
employing ABAC.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Contrary to some other schemes, under the definition of ABAC presented here, operations do not have“attributes”. As defined “Attributes contain information given by a name-value pair”. For example,“read = all” (or “all = read”) is not appropriate. Operations can have many types or classes, which are not“attributes” but a fixed set of values. It would be possible to make operation itself an “attribute name”,
such as “operation = read”, but this would then be the only attribute for operation, which would be
redundant.
To meet accountability requirements, there will be a need to track accesses of objects to specific subjects
linked to specific users. Accountability could be lost if access decisions are based on attributes, but subject
or user IDs are not tracked to specific access requests and decisions.
2.4

Enterprise ABAC Concepts

While ABAC is an enabler of information sharing, when deployed across an enterprise, the set ofcomponents required to implement ABAC gets more complex. At the enterprise level the increased scalerequires complex and sometimes independently established management capabilities necessary to ensure
consistent sharing and use of policies and attributes and the controlled distribution and employment ofaccess control mechanisms throughout the enterprise. The following represents a definition of enterprisefor this document.
Enterprise: A collaboration or federation among entities for which information sharing is required andmanaged.
Figure 4 below presents an example of the major components required to enable enterprise ABAC. Some
enterprises have existing capabilities that can be leveraged to implement ABAC. For example, mostenterprises have some form of identity and credential management to manage population of subject
attributes, such as name, unique identifier, role, clearance, etc. Similarly, many enterprises may have someorganizational policy or guidelines to establish rules authorizing subjects’ access to enterprise objects.
However, these rules are usually not written in a machine-enforceable format that can be integrated
consistently across all applications. ABAC policies must be made available in machine-enforceable
format, and stored in repositories and published for ACM consumption. These digital policies include
subject and object attributes required to render access control decisions. The enterprise subject attributes
must be created, stored, and shared across organizations within the enterprise through a subject attribute
management capability. Likewise, enterprise object attributes must be established and bound to objects
through an object attribute management capability. At this point, the ABAC-enabled access control
mechanisms must be deployed. The remainder of this section provides more detail on each of these major
components of enterprise ABAC.

11

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONSThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Figure 4: Enterprise ABAC Scenario Example

2.4.1

Enterprise ABAC Policy

Natural Language Policies (NLPs) are high-level requirements that specify how information access ismanaged and who, under what circumstances, may access what information. NLPs are expressed in humanunderstandable terms and may not be directly implementable in an ACM. NLPs may be ambiguous andthus hard to derive in formally actionable elements, so the enterprise policy may be difficult to encode inmachine-enforceable form. While NLPs can be application-specific and thus taken into consideration by theapplication system, NLPs are just as likely to pertain to subject actions that span multiple applications. For
instance, NLPs may pertain to object usage within or across organizational units or may be based on needto-know, competence, authority, obligation, or conflict-of-interest factors. Such policies may span
multiple computing platforms and applications. NLPs are defined in this document as follows:
Natural Language Policy (NLP): Statements governing management and access of enterprise objects.
NLPs are human expressions that can be translated to machine-enforceable access control policies.
Given that relevant NLPs exist for each organization in an enterprise, the next step is to translate those into
a common set of rules that can be enforced equally and consistently within the ACMs across theenterprise. In order to accomplish this, it is necessary to identify all required subject/object attributecombinations and allowable operations. Often these values will vary from organization to organization andmay require some form of consensus or mapping to each organization’s existing attributes toaccommodate enterprise interoperability. The agreed-upon list of subject and object attributes, the12

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

allowable operations, and all mappings from existing organization-specific attributes are then translated
into machine-enforceable format.
NLPs must be codified into Digital Policy (DP) algorithms or mechanisms. For efficiency of performanceand simplicity in specification, an NLP may require decomposition and translation into different DPs thatsuit the infrastructure of operation units in the enterprise. DPs are defined in this document as:
Digital Policy (DP): Access control rules that compile directly into machine executable codes or signals.
Subject/object attributes, operations, and environment conditions are the fundamental elements of DP, thebuilding blocks of DP rules, which are enforced by an access control mechanism.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Multiple DPs may require Metapolicies (MPs), or policies dictating the use and management of DPs tohandle DP hierarchical authorities, DP deconfliction, and DP storage and updates. MPs are used for
managing DPs. Depending on the level of complexities, hierarchical MPs may be required based on the
structures for the priority and combination strategies specified by NLP. MP is defined in this document as:
Metapolicy (MP): A policy about policies, or policy for managing policies, such as assignment ofpriorities and resolution of conflicts between DPs or other MPs.
Once DPs and MPs are developed they need to be managed, stored, validated, updated, prioritized,
deconflicted, shared, retired, and enforced. Each of these operations requires a set of capabilities that willoften be distributed across the enterprise and is collectively termed Digital Policy Management (DPM).
There may be multiple policy authorities and hierarchies within organizations that have variations onenterprise policy. The rules for how DPs and MPs are managed may be determined by a central authority.
Proper DP definition and development are critical to the identification of subject and object attributes thatare needed to render an access control decision. Remember that a DP statement is comprised of the subject
and object attribute pairings as well as environment conditions needed to satisfy a set of allowable
operations. Once the full set of subject and object attributes needed to satisfy the entire set of allowable
operations for a given set of enterprise objects is identified, this set of attributes comprises the entire set of
attributes needed to be defined, assigned, shared, and evaluated for enterprise ABAC access decisions. For
this reason, identifying the NLP and DP must be accomplished by the support of attributes when
implementing an enterprise ABAC capability. Additional considerations for management of DP can befound in Section 3 of this document.
2.4.2

Attribute Management in Enterprise ABAC

Next, consider the lists of attributes developed while examining the NLPs and DPs. Without a sufficientset of object and subject attributes, ABAC does not work. Attributes need to be named, defined, given a
set of allowable values, assigned a schema, and associated to subjects and objects. Subject attributes need
to be established, issued, stored, and managed under an authority. Object attributes must be assigned to theobjects. Attributes shared across organizations should be located, retrieved, published, validated, updated,
modified, and revoked.
Subject attributes are provisioned by attribute authorities—typically authoritative for the type of attributethat is provided and managed through an attribute administration point. Often, there are multiple
authorities, each with authority over different attributes. For example, Security might be the authority for
Clearance attributes, while Human Resources might be the authority for Name attributes. Subject
attributes that need to be shared to allow subjects from one organization to access objects in anotherorganization must be consistent, comparable, or mapped to allow equivalent policies to be enforced. For

13

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

example, a member of Organization A with the role Job Lead wants to access information in Organization
B, except Organization B uses the term Task Lead to denote the equivalent role. This problem also applies
to mapping between an enterprise attribute schema and an application-specific schema, particularly ones
built before the enterprise schema is defined and/or Commercial Off-The-Shelf (COTS) products thatcome with their own built-in schema. Organizations must normalize subject attribute names and values, ormaintain a mapping of equivalent terms for all organizations. This should be managed by a central
authority.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Object attributes need to be established, maintained, and assigned to objects as objects are created or
modified. While it may not be necessary to have a common set of object attributes in use across theenterprise, object attributes should be consistently employed to fulfill enterprise policy requirements, andavailable sets of object attributes should be published for those wishing to mark, tag, or otherwise apply
object attributes to their objects. At times, it might be necessary to ensure that object attributes are nottampered with or altered to satisfy an access request. Objects can be cryptographically bound to theirobject attributes to identify whether objects or their corresponding attributes have been inappropriately
modified. Mechanisms must be deployed to ensure that all objects created are assigned the appropriate setof object attributes to satisfy the policy being employed by the ACM. It may be necessary to have anEnterprise Object Attribute Manager to coordinate these requirements.
In the course of managing attributes, the concept of “metaattributes”—or characteristics of attributes—
arises. Metaattributes apply to subjects, objects, and environment conditions as extended attributeinformation useful for enforcing more detailed policy that incorporates information about the attributes
and for managing the volumes of data needed for enterprise attribute management. Metaattributes aredefined in this document as:
Metaattributes: Information about attributes necessary to implement MP and DP processing within an
ACM.
Additional considerations for attribute management can be found in Section 3 of this document.
2.4.3

Access Control Mechanism Distribution in Enterprise ABAC

Finally, consider the distribution and management of ACMs throughout the enterprise. Depending on theneeds of the users, size of the enterprise, distribution of the resources, and sensitivity of the objects thatneed to be accessed or shared, the distribution of ACMs can be critical to the success of an ABAC
implementation. The functional components of an ACM may be physically and logically separated anddistributed within an enterprise rather than centralized as described in the system-level view of ABAC.
Within the ACM are several functional “points” that are the service node for retrieval and management of
the policy, along with some logical components for handling the context or workflow of policy andattribute retrieval and assessment. Figure 5 shows the main functional points: the Policy Enforcement
Point (PEP), the Policy Decision Point (PDP), the Policy Information Point (PIP), and the Policy
Administration Point (PAP). When these components are in an environment, they must function together
to provide access control decisions and policy enforcement.

14

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONSThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Figure 5: An Example of ACM Functional Points

A PDP performs an evaluation on DPs and MPs in order to produce an access control decision. PDP and
PEP are defined in this document as follows:
Policy Decision Point (PDP): Computes access decisions by evaluating the applicable DPs and MPs. Oneof the main functions of the PDP is to mediate or deconflict DPs according to MPs.
The PEP enforces decisions made by the PDP:
Policy Enforcement Point (PEP): Enforces policy decisions in response to a request from a subject
requesting access to a protected object; the access control decisions are made by the PDP.
PDP and PEP functionality can be distributed or centralized, and may be physically and logically separated
from each other. For example, an enterprise could establish a centrally controlled enterprise decision
service that evaluates attributes and policy, and renders decisions that are then passed to the PEP. This
allows for central management and control of subject attributes and policy. Alternatively, localorganizations within the enterprise may implement separate PDPs which draw on a centralized DP store.
The design and distribution of ACM components requires a management function to ensure coordinationof ABAC capabilities.
To compute access decisions, the PDP must have information about the attributes. This information isprovided by the PIP. The PIP is defined in this document as:

15

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONSPolicy Information Point (PIP): Serves as the retrieval source of attributes, or the data required forpolicy evaluation to provide the information needed by the PDP to make the decisions.
Before these policies can be enforced, they must be thoroughly tested and evaluated to ensure they meetthe intended need. This action is carried out by the PAP. The PAP can be defined as:
Policy Administration Point (PAP): Provides a user interface for creating, managing, testing, anddebugging DPs and MPs, and storing these policies in the appropriate repository.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Finally, as an optional additional component within the ACM, the Context Handler manages the order ofpolicy and attribute retrieval. This can be important when time critical or disconnected access control
decisions must be made. For example, attributes may be retrieved in advance of an access request, or
cached to avoid the delay inherent in retrieval at the time of the access request. The Context Handler also
coordinates with PIPs to add attribute values to the request context, and converts authorization decisions in
the canonical form (e.g., XACML) to the native response format. The Context Handler can be defined as:Context Handler: Executes the workflow logic that defines the order in which policy and attributes are
retrieved and enforced.

16

NIST SP 800-162

3.

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONSABAC Enterprise Considerations

Many factors must be considered before deploying an ABAC system across an enterprise. This section
addresses consolidation of available guidelines based on the state of the technology to date and lessons
learned through multiple attempts within the Federal Government to deploy ABAC capabilities throughout
a large enterprise. The guidelines are presented according to the phases of the NIST System Development
Life Cycle (SDLC) illustrated in Figure 6. For more general information regarding the definitions of thephases and expected outputs, refer to [NIST800-100]. Most considerations for employment of enterprise
ABAC fall within the first four phases: Initiation, Acquisition/Development, Implementation/Assessment,
and Operations/Maintenance. This section focuses on those phases exclusively.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Figure 6: ACM NIST System Development Life Cycle (SDLC)

The development and deployment of an enterprise ABAC capability requires the careful consideration of anumber of factors that will influence its design, security, and interoperability. These factors lead to a set ofquestions that should be considered:•••

Establish the Business Case for ABAC Implementation. What are the costs ofdeveloping/acquiring new capabilities and transitioning away from old capabilities? What are theimportant benefits provided by ABAC? What new risks, if any, are introduced by ABAC, what
new governance structures are required to manage shared capabilities and documentation ofpolicies that were previously human-in-the-loop decisions? Which datasets, systems, applications,and networks need ABAC capabilities? How is liability for data loss or misuse of data managed?
Understand the Operational Requirements and Overall Enterprise Architecture. How are
privileges managed, monitored, and validated for compliance? What interfaces and objects will
be exposed by the enterprise for information sharing? What ACM will be used? How will subject
and object attributes be shared and managed? What are the access control rules and how are theycaptured, evaluated, and enforced? How is trust managed within the enterprise?
Establish or Refine Business Processes to Support ABAC. Are access rules and policies fully
understood and documented? How are required attributes identified and assigned? How are

17

NIST SP 800-162••

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONSThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

multiple policies applied in a hierarchy and deconflicted? How are access failures handled? Whocreates new policies? How are common policies shared and managed?
Develop and Acquire an Interoperable Set of Capabilities. How will interoperability beachieved? How are subject attributes from identity management integrated into ABAC? How arediverse or special needs for identities handled? How are subject attributes shared and maintained
across enterprise entities? What are the tradeoffs with centralization versus distribution ofauthentication, authorization, attribute management, decision, or enforcement capability? How areenvironment conditions used in access decisions? How is confidence in security, quality, andaccuracy measured, conveyed, and used in access decisions? How are subject attributes mapped
between organizations? How are policies developed to incorporate the latest set of available
subject, object, and environment condition attributes?
Evaluate Performance. How are subject attributes managed for disconnected and bandwidthlimited or resource-limited users? How available are interface specifications for new participants
to the enterprise? How are quality and timeliness of changes to attributes and policies measured
and enforced? Will overall system and end-to-end performance be adequate?

The following sections address these principles and questions in more detail.
3.1

Initiation Phase Considerations

During the initiation phase, the organization evaluates
the need for an ABAC system and its potential use. It
should be determined whether the ABAC system will
be an independent information system or a componentof an already-defined system. Once these tasks havebeen completed and a need has been recognized for
ABAC capabilities, several processes must take place
before the ABAC system is approved, to include
clearly defining goals and defining high-level
requirements. During this phase, the organization
defines high-level business and operational
requirements as well as the enterprise architecture for
the ABAC system.
3.1.1

Building the Business Case for Deploying ABAC Capabilities

As with any major system deployment, the deployment of enterprise ABAC capabilities should be
preceded by significant requirements evaluation, trade studies, and planning activities to include thedetermination of whether ABAC is the right type of access control capability needed and feasible given
the application portfolio. ABAC has the virtue of providing access without prior knowledge of or
information about the subject, and large-scale enterprise information sharing of a limited set of mission orbusiness critical objects.
Before any technical requirements are generated or deployment decisions are made, it is important toevaluate and establish a business case for the deployment of ABAC capabilities as well as to define thescope of the enterprise targeted for these capabilities. Enterprise ABAC carries with it significant
development, implementation, and operations costs as well as a change in the way enterprise objects areshared and protected. Case studies or experience reports from other organizations may be helpful inplanning the ABAC deployment. It may be more practical to take an incremental approach and implement
ABAC protections for a limited set of objects. This implementation would establish and utilize, to the
maximum extent possible, policies and attributes appropriate for the enterprise as a whole. Feedback from18

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

incrementally building out this ABAC capability will refine policy and attribute definitions and exercise
the governance and configuration management capabilities necessary to support broader ABAC use
throughout the enterprise. It should be noted that without addressing the issues presented in the following
subsections, an enterprise may incur significant delay and additional cost in its ABAC deployment.
3.1.2

Scalability, Feasibility, and Performance Requirements

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Scalability, feasibility, and performance are important issues when considering the deployment of an
ABAC product or technology. Enterprise ABAC—allowing an organization to have access to authorized
objects managed by another organization in the same enterprise—requires complex interaction between
ABAC components. Often these components are distributed throughout the enterprise across organization
boundaries and sometimes on different networks. The larger and more diverse the enterprise, the more
complex these interactions become. What may have been a simple request to access a document in a
repository may now require a policy request from an enterprise service, multiple attributes from numerous
logically and physically dispersed attribute sources, a third-party validation of the integrity of the object
attributes bound to the document, and a decision made at one point in the enterprise while the enforcementof that decision occurs at a different point in the enterprise. Feasibility evaluation should check whether
applications can support ABAC, either natively or through third-party applications. All of these potential
interactions have a performance cost that must be evaluated when determining the scope of objects that
may be shared through an enterprise ABAC implementation. To mitigate potential performance andscalability concerns, a variety of architectures should be considered. The distribution of ABAC components
should take into account the underlying enterprise architecture, and location of necessary data and objects
to be shared. For instance, PDPs and PEPs may be deployed under the same administration.
3.1.2.1 Development and Maintenance Cost
While ABAC provides many important new features when deployed across an enterprise, the cost ofdevelopment, deployment, and maintenance of ABAC may exceed its benefits in the long term. In
addition, the cost of retrofitting applications to use ABAC is wholly separate from procuring, setting up,
and maintaining an authorization infrastructure. While cost savings can be incurred through no longer
having to maintain existing solutions, it is possible that a large portion of that maintenance savings will be
offset by the cost of managing and maintaining subject attributes and the policies needed for ABAC, aswell as additional system support required. The benefits of having more precise 3, consistent, and flexible
security must be quantified and used to determine the right balance between cost of risk and cost of
security. Given these considerations, ABAC is not the right solution for every access control problem but
can prove viable for environments where subjects and objects carry a rich set of attributes and accessdecisions involve complex relationships among these attributes.
3.1.2.2 Cost of Transition to ABAC
The governance and business process changes that must accompany the shift to ABAC represent asignificant transition to an approach where objects are controlled by enterprise-governed policies andenterprise-controlled attributes, and sometimes local control as well. These objects may now need to be
3

Attributes and rules allow more precision through a larger number of discrete inputs into an access control decision,
providing a larger set of possible combinations of those variables to reflect a larger and more definitive set of possible
rules, policies, or restrictions on access. ABAC allows a large number of attributes to be combined to satisfy any access
control rule imaginable. As long as the attributes are available to evaluate at the time the access decision is rendered, therule can be as complex and definitive as it needs to be to satisfy the protection requirements of the object. Thus, finegrained AC allows access to be more detailed or flexibly partitioned when compared with coarse-grained AC, for example:
coarse: employees can read file X, fine: employees working on project A can read file X, and finer: employees working
on project A during office hours can read file X.

19

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

associated with an additional set of characteristics that may not have been used in access control until now.
Users accustomed to logging onto their network and having broad access to resources may no longer havethat luxury. While policy makers will do their best to reflect current mission and business needs inpolicies, there will be unexpected but inevitable denials of access to those with critical mission or business
functions.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

As ABAC products are implemented and an organization’s access control changes, new processes andcapabilities will need to be integrated into the users’ day-to-day business processes and enterprise policies.
During the transition it will be important to ensure that users understand why these access control changes
are being implemented and what impact they will have on the way business is done. These users will need
to be educated in the new ABAC systems and processes. These changes need to be properly
communicated to show the benefits of an enhanced user experience, the enhanced security andsafeguarding of critical information, the requirements of the new ABAC system, and the legacy access
control systems, if replaced, that will be phased out. Users may be comfortable with existing processes andmay not see an immediate value in switching to an ABAC capability. It may be important to emphasize
areas in which ABAC enhances the security posture of the enterprise in contrast to areas where it
complements existing access control mechanisms.
3.1.2.3 Need to Review Privilege and Monitor Authorizations
Some enterprises may desire the ability to review the capabilities associated with subjects and their
attributes and the access control entries associated with objects and their object attributes. Moresuccinctly, there are some requirements to know what access each individual has before the requests are
made. This is sometimes referred to as “before the fact audit”. Before the fact audit is often necessary todemonstrate compliance to specific regulations or directives. Another commonly desired review feature isdetermining who has access to a particular object or to the set of resources that are assigned to a particular
object attribute. An ABAC system may not lend itself well to conducting these audits efficiently. Rather, a
key feature of ABAC is the ability of the object owner to protect and share the object without any priorknowledge of individual subjects. Evaluating the set of subjects that have access to a given object requires
a significant data retrieval and computation effort—possibly requiring every object owner to run asimulation of the access control request for every known subject in the enterprise. Limiting the scope of
ABAC implementation can help in predetermining access authorizations, but other methods of ensuring
the validity of access authorizations should be explored if the enterprise requires such validation.
3.1.2.4 Understanding Object Protection Requirements
Within the various parts of an enterprise there are a number of different operation and object types overwhich policy needs to be enforced. These may include operating systems, applications, data services, anddatabase management systems. While some NLPs may exist to help determine authorized access, accessto most objects is controlled through local group policy governed by local business rules, undocumented
evaluation factors, and inherited non-standard doctrine. Implementing ABAC requires, first and foremost,a thorough understanding of the objects and their protection requirements. Without that understanding, thecost to develop and implement the technology required for enterprise ABAC increases dramatically. It is
recommended that enterprise ABAC implementations be initially applied to objects that are well defined,
controlled, and documented.
3.1.2.5 Enterprise Governance and Control
Successful enterprise ABAC requires the coordination and determination of several business process andtechnical factors as well as establishment of enterprise responsibilities and authorities. Without the proper
governance model in place, organizations will develop stovepiped solutions and enterprise interoperability

20

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

will be delayed significantly. It is recommended that an enterprise governance body be formed to manage
all identity, credential, and access management capability deployment and operation and that each
subordinate organization maintain a similar body to ensure consistency in managing the deployment andtransition associated with enterprise ABAC implementation. Additionally, it is recommended that the
governance body develop a “trust model” that can be used to illustrate the trust chain and help determine
ownership and liability of information and services, needs for additional policy and governance, andrequirements for technical solutions to validate or enforce trust relationships. The trust model can be used
to help influence organizations to share their information with clear expectations of how that information
will be used and protected, and be able to trust the information coming from other organizations.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Additionally, enterprise authorization services should be tightly integrated with security audit, data loss
prevention, security configuration management, continuous monitoring, and cyber defense capabilities.
Authorization services alone are not enough to ensure the security needed to protect the mission-criticalobjects resident on the networks. Efforts should be undertaken to fully understand enterprise security
requirements and the impacts an ABAC implementation will generate. For example, when using a
distributed ACM architecture there may be consequences to the ability to audit access control decisions
and events.
ABAC systems can benefit from deployment in environments governed by a trust framework. A
comparison of representative trust chains for legacy ACL use and ABAC use (Figures 7 and 8) shows that
there are many more complex trust relationships required for ABAC to work properly. ACLs are
established by the object owner or administrator, who ultimately enforces the object access rules by
provisioning access to the object through addition of a user to an ACL. In ABAC, the root of trust is
derived from many sources, such as Subject Attribute Authorities or Policy Developers.

Figure 7: ACL Trust Chain

21

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONSThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Figure 8: ABAC Trust Chain

When managing the risk inherent in information sharing, two perspectives of risk must be addressed when
deploying an enterprise ABAC solution. First, an ABAC solution may be considered one of many security
control options that help protect an enterprise from risk. The risk of unauthorized access to protectedresources can be reduced with an ABAC implementation because precise policies can be implemented
consistently and updated more easily to address changing threats. Second, use of ABAC may increase or
decrease operational risk of an enterprise by exposing protected objects to access by unknown entities. By
assuming that attributes are issued appropriately, the ABAC system is partially dependent upon theattribute-issuing authorities. This multiplicity of risk sources presents a number of challenges that must be
managed through governance and a formal trust model.
When establishing a governance model for managing the risks inherent in ABAC, it is important to ensure
there are mechanisms and agreements in place with each responsible organization to monitor and manage
these roots of trust and any liabilities that occur as a result of unwarranted access.
3.1.3

Developing Operational Requirements and Architecture

Several high-level operational and architecture planning requirements must be satisfied before
implementing an ABAC solution:
•
•
•
•
•

First, identify the objects that will be shared and protected by ABAC.
Second, define the rules or policies that govern their protection.
Third, identify and define the subject and object attributes, along with their associated authorities,
in coordination with the access control rule developers.
Fourth, develop processes regarding how the access control policies are written, validated, andmanaged.
Finally, determine how the ACMs will be segmented or distributed throughout the enterprise andhow attribute, policy, and decision requests and responses will be rendered.

22

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

3.1.3.1 Object Identification and Policy Assignment
The objects selected to be shared and protected by the ABAC solution will vary based upon organizational
requirements. Each object or class of object must be identified and the policy or rules protecting each must
be documented. A set of business processes need to be established to identify, class, and assign policy toeach new object created within the scope of the ABAC implementation.
3.1.3.2 Attribute ArchitectureThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Access control policies are expressed in terms of attributes. Consequently, all required attributes must be
established, defined, and constrained by allowable values required by the appropriate policies. The
schema for these attributes and allowable attribute values must be published to all participants to help
enable object owners with rule and relationship development. Once attributes and allowable values are
established, methods for provisioning attributes and appropriate attribute values to subjects and objects
need to be established as well as an architecture for any attribute repositories, retrieval services, or
integrity checking services. Interfaces and mechanisms must be developed or adopted to enable sharing ofthese attributes.
3.1.3.3 Subject Attributes
Many human subject attributes are typically provisioned upon employment with the organization and may
be provisioned by several different authorities (human resources, security, organization leadership, etc.)
For these, approaches to obtaining authoritative data are well known. As an example, only security
authorities should be able to provision and assert clearance attributes and attribute values based on
authoritative personnel clearance information; an individual should not be able to alter his or her own
clearance attribute value. Other subject attributes may involve the subject’s current tasking, physicallocation, and the device from which a request is sent; processes need to be developed to assess and assure
the quality of such subject attribute data.
Authoritative subject attribute provisioning capabilities should be appropriately dependable in regards toquality, assurance, privacy, and service expectations. These expectations may be defined in an Attribute
Practice Statement (APS). An APS provides a listing of the attributes that will be used throughout theenterprise, and may identify authoritative attribute sources for the enterprise. Still further network
infrastructure capabilities (including the ability to maintain attribute confidentiality, integrity, andavailability) are required to share and replicate authoritative subject attribute data within and acrossorganizations.
3.1.3.4 Object Attributes
Object attributes are typically provisioned upon object creation and may be bound to the object orexternally stored and referenced. It is to be expected that access control authorities cannot closely monitor
all events. Frequently, this information is driven by non-security processes and requirements. Good
attribute data that support good access decisions are essential, and measures must be taken to ensure that
object attributes are assigned and validated by processes that the object owner or administrator considers
appropriate for the application and authoritative. For example, object attributes must not be modifiable by
the subject to manipulate the outcome of the access control decision. The object attributes must be madeavailable for retrieval by access control mechanisms for access control decisions. Additional
considerations for creating object attributes include:

23

NIST SP 800-162•••

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

In general, users will not know the values of an object attribute (e.g., to which sensitive
compartment a given user is authorized). This should be accounted for in ACMs, so that users
only see the values that are applicable to them.
As with subject attributes, a schema is required for object attributes defining attribute names andallowed values.
Attributes need to be kept consistent in DP, MP, and NLP.

There have been numerous efforts within the Federal Government and commercial industry to create
object attribute tagging tools that provide not only data tagging, but also cryptographic binding of theattributes to the object and validation of the object attribute fields to satisfy access control decision
requirements.
3.1.3.5 Environment Condition
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Environment condition refers to context information that generally is not associated with any specificsubject or object but is required in the decision process. They are different from subject and object
attributes in that they are not administratively created and managed, but instead are intrinsic and must be
detectable by the ABAC system. Environment conditions such as the current date, time, location, threat,and system status, usually are evaluated against current matching environment variables when authorizing
an access request. Environment conditions allow ABAC policies to specify exceptional or dynamic AC
rules that cannot be described by subject/object attributes only. When composing ABAC rules withenvironment conditions, it is important to make sure that the environment condition variables and theirvalues are globally accessible, tamper proof, and relevant for the environments where they are used.
3.1.3.6 Access Control Rules
In ABAC, all AC rules must include some combination of attributes and allowable operations. They may
also include conditions, hierarchical inheritance, and complex logic. Together these provide a rich array of
options when implementing ABAC. Rule sets and the application of rule sets to objects must be governedand managed appropriately. Rules must accurately and completely reflect the NLP, and be authoritatively
developed (some by organizations, some by resource owners), applied, maintained, shared, and asserted.
ABAC allows multiple rules from multiple stakeholders. New techniques are needed to coordinate andobtain the proper balance of sharing and protection. In some settings, one might limit the visibility ofwhich rules apply to which objects to limit the likelihood of unauthorized subjects manipulating attributes
to obtain authorization. In other circumstances, subjects that are denied access should have a method toverify or rectify the circumstances that caused the denial. Some organizations may wish to track thedenials to see if the rules were appropriate. Similarly, rule definition and employment mechanisms andprocesses should include a robust rule deconfliction (resolution for the different decisions of rules)
capability to determine rule conflicts and resolution processes.
3.1.3.7 Access Control Mechanism and Context Handling
The distribution and orchestration of ACM must be predetermined to avoid conflicts and weaknesses inobject protection. For example, if an identical object is held by two different organizations, anunauthorized subject should not be able to access the version held by the organization with lesser
restrictions. ACMs should be managed, maintained, and employed in a consistent manner to ensureinteroperability and comprehensive security.
The order in which the ACM retrieves information, evaluates for a decision, and enforces the decision candiffer greatly based on the specific requirements of the implementation, and may even take into account24

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

environment conditions during access control decision rendering. This is referred to as Context Handlingand simply refers to the workflow the ACM undertakes when gathering the data needed for a decision.
Additionally, where and how policy, attribute, and decision information are stored and exchanged
throughout the enterprise is an important consideration, for performance and scalability purposes.
3.2

Considerations during the Acquisition/Development Phase

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

During the acquisition/development phase, thesystem is designed, purchased, programmed,
developed, or otherwise constructed. Typically,
during this phase, the organization prepares thebusiness processes needed for enterprise-wide
execution and defines the systems to be deployed
and integrated. During the first part of this phase,the organization should simultaneously define thesystem’s security and functional requirements.
During the last part of this phase, the organization
should perform developmental testing of thetechnical and security features/functions to ensurethat they perform as intended prior to launching
the implementation/assessment phase.
3.2.1

Business Process Generation and Deployment Preparation

3.2.1.1 Documentation of Rules
For each of the types of objects controlled by an organization, there should be an accompanying set ofaccess control rules documented in an NLP. (Use cases might provide the easiest means for enterpriseparticipants to define NLP for a set of objects.) These rules should dictate who can and cannot create,view, modify, delete, forward, and interact with data and services controlled by the organization and underwhat context or environment conditions they have those privileges. Documenting these rules incorporates
the organization’s interpretation of applicable policies and guidance, the specific sensitivities of applicableobjects, and knowledge of appropriate user communities that will need the objects.
Documenting NLP facilitates the development of DP and provides traceability back to the written policy.
For example, many organizations have difficulties transitioning their authorization capabilities from ACLs
into a more robust ABAC infrastructure because no corresponding NLP exists. As an example, consider
that when a request for access is received, the data owner evaluates a set of criteria—usually
undocumented—such as, “Is this person a member of the working group?” or “Am I familiar with thisperson or his or her organization?” and then renders a decision before adding the requestor’s name to theappropriate ACL. Well documented NLPs enable transition from human generated decision making to aconsistent automated policy driven access control decision.
3.2.1.2 Customizing Policy
Unless required by higher authorities or obligations, subordinate organizations should not make local
policies less stringent. If subordinate organizations in an enterprise are able to independently relax therestrictions established for enterprise policy, the security inherent in the system is undermined, possibly
allowing local access to enterprise objects where it would otherwise be forbidden.

25

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

Local access policies implemented in a federated enterprise should reflect the enterprise policy associatedwith the requested object, based on mapped attributes from the requestor’s organization. Depending on
the sharing agreements between organizations, objects with shared ownership or control should beprotected according to the most restrictive policy.
3.2.1.3 Agreement and Understanding of Attributes
A consistent set of valid values must be defined and applied for enterprise subject and object attributes.
This allows authorization decisions to be based on known values that are consistent throughout theenterprise. The lifecycle management of attributes is the responsibility of the provisioning organization,
whether the attributes are used exclusively within an organization or across organizations.
3.2.1.4 Understanding Meaning of Attributes
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

Attribute service providers need to describe attributes and their relationship with other attributes so that
consumers may properly and effectively use attributes. Attribute service providers must document thedefinitions and meanings of enterprise authorization attribute values and provide guidance on the use of
the attributes. In some cases, attributes must be used in combination with other attributes to establish avalid context, such as the combination of role and organization—a role has no meaning unless it is definedwithin the context of an organization. For example, the Director of Operations for an entire organization,
whose responsibilities may encompass the Finance, Human Resources, Legal, and other departments, hasan entirely different contextual meaning from the Director of Operations within the Web Services branchof the IT Department. Without the understanding of the guidance related to the attribute, its context, andthe knowledge that these attribute values are required together to render a decision, the DP—and hence thedecision—may be generated on insufficient information or using faulty logic.
3.2.1.5 Processes and Procedures for Access Failures
A set of procedures and requirements for communicating exception handling, access denials, and errors
should be established to provide users a means to remediate access decisions given mission, role, andneed-to-know imperatives. As authorization services mature from the traditional method of provisioning
an account and populating an ACL to an automated decision process, it will be more difficult for systemusers to understand and remedy access denials. A well-established process for properly discovering andobtaining the attributes needed for access approval will help ease the transition. This can be expanded toaddress dropped connections or other difficulties in accessing the authorization service component.
In a mission-critical role, the subject should be able to understand the limitations and request an exception,
be pointed to an authoritative source of help, or attempt an alternate path to access equivalent informationor services.
3.2.1.6 Attribute Privacy Considerations
ABAC capabilities should be developed to comply with all applicable privacy laws, directives, and policy.
Due to the personal and descriptive nature of subject attributes, implementing attribute sharing capabilities
may increase the risk of privacy violation of personally identifiable information (PII) due to inadvertent
exposure of attribute data to untrusted third parties or aggregation of sensitive information inenvironments less protected than the originator’s. Organizations engaged in attribute sharing should
employ trust agreements to ensure the proper handling of PII and enforcement of PII regulations. Thesetrust agreements should detail authorized PII use and handling for all components in the trust chain as wellas methods for validating, remediating, and adjudicating liability for regulatory infractions. A second
consideration is that subject attributes can be revealed by the patterns of grant/deny decisions. If a subject

26

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

accesse a particular resource, the subject must possess attributes as specified in the access rule for that
resource. The organization should protect access logs or other means of discovering grant/deny decisions.
3.2.1.7 Digital Policy Creation and Maintenance
Each DP should be specified to satisfy the requirements of an NLP. DPs are sensitive and need to beprotected in the same way as objects, according to an appropriate policy. These policies may pertain tocreation and modification of specific portions of the DP. DPs should be written or modified only by
individuals who can interpret NLPs and have authority to write the DP. Implementing a particular NLP
may require specification of multiple DPs. Special consideration should be taken to ensure that
subordinate policies do not conflict with higher level policies. Individual organizations should develop
and maintain local policy and unique policy that applies only to their constituent or subordinate
organizations.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

3.2.2

System Development and Solution Acquisition Considerations

3.2.2.1 Standardization and Interoperability within the Enterprise
Implementers of ABAC should strongly consider using a comprehensive standards-based approach thatenables current day interoperability and future deployment flexibility by making use of products orcapabilities that meet these objectives. An established practice to achieve interoperability and costefficient ABAC deployments is to use a series of standards, specifications, and standardized
configurations (specifying a subset of standard options, i.e., a profile). Standards that have optional
elements may be implemented inconsistently by developers, making it possible for services or applications
that are fully compliant with a standard to be non-interoperable. For this reason, well-defined andstandardized profiles should be encouraged, especially in cross-organizational environments. Whenacquiring ABAC solutions, implementers should use commonly agreed-upon tailored profiles as well as
leverage the standards and profiles contained within existing standards registries.
Individual authorization service components (e.g., policy decision point, policy enforcement point, policy
retrieval point, attribute retrieval point, metaattribute retrieval point) should be developed with standard,
open interfaces so that systems from multiple products can be employed while ensuring interoperability.
Enterprises should consider a set of requirements addressing functionality, interfaces, infrastructure, andproduct support to employ as a filter within the procurement process for all acquisitions regardless of
categorization or affiliation.
3.2.2.2 Identity Management Integration
A request for access to an object must be authenticated as originating from a unique subject.
Authentication is achieved through use of identity credentials, and must occur before an access decision
can be made. The ABAC system needs to support the prevalent and strategic authentication mechanisms
and credentials used by the organization. This may mean the organization needs to make enhancements to
its authentication infrastructure, if its current state impedes ABAC adoption. The subject attributes
conveyed in these credentials should uniquely determine the subject, and the identity vetting process used
to issue credentials should be sufficient to hold the identified entity accountable. The issuance and vetting
processes should be recognized throughout the enterprise as trustworthy and sufficient to enforce
accountability requirements. Strong authentication methods should be used that are of sufficient assurance
for the request ([NIST800-63-3, NIST800-63B]). Once the subject is authenticated, attributes associatedwith the subject can be used to determine an access decision, and access decisions can be captured inrequired audit records/systems to provide attribution of the request. For example, a request transferred via
a Transport Layer Security (TLS) 1.2 session with client authentication [RFC5246] depending on X.509

27

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

certificates issued by a trusted certificate authority is associated to the entity bound by the certificate
authority to the distinguished name.
3.2.2.3 Support for NPEs
Support for NPEs in access control services has special requirements. Authorization services use attributes
associated with entities in any form. The attributes bound to the NPE not only help define the unique NPE
but also reflect the context of that entity within an organization.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

In some cases, an NPE subject may be acting on behalf of one or more human subjects. These NPEs may
carry their own identity credentials independent of any human subject. Note that the access control systembasing an access decision on an NPE credential will not be able to attribute the request to the individual orindividuals who may be acting in that role, or logged into the group account, at the time of the request.
NPEs may act either independently or on behalf of an authenticated individual. NPEs may include
network devices (e.g., switches, routers), processes running on servers (e.g., portals), workstations, andother endpoint devices. As mission and security functions are increasingly automated, NPEs will play alarger role as actors in authorization service interactions.
3.2.2.4 Authentication and Data Integrity between ABAC Components
The authorization service requires strong mutual authentication between ABAC components (e.g., PEP,
PDP) when authorization service components exchange sensitive information. For each exchange, proof oforigin, data integrity, and timeliness should be considered. For example, when the authorization service
needs to obtain attributes from an authoritative attribute service, mutual authentication should be used,followed by mechanisms for validating message integrity and message origin. Authentication protocols
based on strong methods (e.g., X.509 authentication) should be used to provide the level of assurance
needed by both parties involved in the attribute exchange.
3.2.2.5 Integrating Other Controls with ABAC
Authorization services alone are not enough to ensure the security needed to protect the mission-criticalobjects distributed throughout the enterprise. Comprehensive and cohesive security capabilities are needed
to establish the desired level of assurance, and they must be tightly integrated and able to seamlessly feed
the security information needed for making and enforcing access decisions. These other controls may
include subject authentication, security audit, security configuration management, intrusion detection, andmonitoring capabilities.
3.2.2.6 Selection and Accessibility of Attribute Sources
Authorities should be clearly identified so that the attribute source is able to provide attributes to the policy
decision point from an authoritative source. When multiple attribute services are available, possibly withdifferent metaattributes (such as assurance level), the attribute store/policy information point should
balance the retrieval of attributes that satisfy the most restrictive policies, with performance andavailability requirements.
3.2.2.7 A Shared Repository for Subject Attributes
Direct use of shared repositories for subject attributes should be considered where there is sufficient
network connectivity to take advantage of economies of scale, increased quality control, and standard
interfaces. Another advantage of using shared attribute repositories is that they provide a single accesspoint for data from multiple sources. Building and managing a connection to a single access point may be

28

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

less complex than managing multiple connections. In some cases, limited connectivity, insufficient
bandwidth, or intermittent connections may prevent authorization service providers from being able to use
shared repositories reliably. It may be necessary to maintain local copies of data that cannot be
continuously in sync with a shared attribute repository, and thus not have access to current data.
3.2.2.8 Minimum Attribute Assignments
In some enterprises, a minimum set of attributes may be defined. With a standard set of enterprise subject
attributes and object attributes, DPs can more easily be developed and modified to reflect changes inpolicy. One example of where this approach applies is with classification and compartmentalization
markings within classified networks. In most cases, an object cannot be placed on the network without
proper marking, and access control policies are written to address the finite and well-known set ofclassification and compartmentalization markings.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

3.2.2.9 Environment Conditions
When required by policy, environment (or contextual) information can be fed into the access control
process. Examples include threat level, subject/object location, method of authentication, or time of day.
The environment conditions may change more rapidly over time than subject and object attributes.
3.2.2.10 Attribute Management
Authorities for assigning attributes should be clearly defined and consistent with an appropriate attributepolicy. Some form of validation, integrity, and provenance mechanisms (to verify the completeness,allowable values, integrity, and change history of attributes) should be integrated into the mechanism orframework used to manage attributes.
3.2.2.11 NLP/DP Traceability
A comprehensive and coherent traceability between high-level enterprise written policy/NLP and lowlevel enterprise or local DP should be maintained by an appropriate authority. This will enable changes towritten policy to be evaluated and subsequent DPs to be altered accordingly. With this policy traceability,
the plethora of DPs resident in local organizations will be auditable, verifiable, and alterable given any
change to requirements.
3.2.2.12 Rules or Policies Based on the Agreed Attributes
If an organization has an agreement with one or more organizations to use a defined list of attributes (someindustry and use case-specific groupings of attributes are available today), the organization that owns theobjects must ensure that it writes access control policies based only on those attributes. Every effort should
be made to use any accepted common set of shared enterprise attributes, no matter how limited, to ensure
basic interoperability if only to effect a limited secure information sharing capability. As new
requirements arise, the enterprise may choose to introduce new enterprise attributes and rules for sharingthem.
For example, the OASIS XACML Export Control–US (EC-US) and Intellectual Property Control (IPC)
Profiles serve as examples of domain-specific standardized attributes with generally constrained attributevalues. The EC-US Profile documents the attributes common to access control decisions for the U.S.
Department of Commerce Export Administration Regulations (EAR) and the U.S. Department of State
International Traffic in Arms Regulations (ITAR).

29NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

3.2.2.13 Externalization of Policy Decision Services
It is common to implement PDPs as services, separate from individual enterprise services andapplications. Doing so removes the burden and expense of providing similar decision services for every
enterprise service or application, since a single PDP can support multiple enterprise authorization services.
Allowing authorization service providers to use PDP services that are provided by the larger enterprise orby the organization greatly simplifies service/application development; saves money that would otherwise
be spent on licensing, training, configuring, and deploying disparate instances of these services; andmoves operations and maintenance away from individual programs.
3.2.3

Considerations for Other Enterprise ABAC Capabilities

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

When developing and implementing ABAC enterprise authorization capabilities, architects and program
managers must keep in mind that there will inevitably be a long transition from the current access control
methods in use now to the desired end state. As standards and technology mature, organizations will needto embrace concepts that enhance interoperability and promote higher assurance solutions while
discarding proprietary, stovepiped solutions.
3.2.3.1 Confidence in Access Control Decisions
An access control decision is made by using the accurate, timely, and relevant data gathered from
authoritative source(s) that are appropriate to the level of risk. Confidence in the access control decision
depends upon timeliness, relevance, authority, and quality, reliability, and completeness of information
used to compute the decision. Other factors in establishing confidence include identification andauthentication processes (e.g., strength of authentication mechanism, identity vetting, credential issuanceand proofing, attestation, source Internet Protocol [IP] address). When adopting a risk-based approach to
ABAC, the factors discussed above should be taken into account.
3.2.3.2 Mapping Attributes between Organizations
Organizations may name attributes and attribute values differently. It may be important to implement
solutions that provide attribute mapping between enterprise organizations to minimize the need for a
special class of attributes called “enterprise attributes.” Attribute mapping serves as a translation between
attributes or attribute values that are named differently. For example, one organization may use the name
Citizenship and another may use the name Nationality to refer to the same set of attribute values.
In practice, cross-organizational ABAC may follow a collaborative approach outlined in Sections 3.1.3.1
and 3.1.3.2. This would allow each organization to make local decisions within a framework that provides
assurance of appropriate control between organizations. When new policies are created, if policy authors
create or designate their own attributes, policies may not be interoperable. Using pre-agreed attributes will
make the policies more uniform and easily understood.

30

NIST SP 800-162

3.3

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONSConsiderations during the Implementation/Assessment Phase

In the implementation/assessment phase, theorganization installs or implements the system,
configures and enables system security features,
tests the functionality of these features, and finally,
obtains a formal authorization to operate the system.
Most of the considerations during this phase arefocused on optimizing performance and ensuring
security features work as expected.
3.3.1

Attribute CachingThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

When an ABAC solution moves from theprototype/pilot to deployment, attribute caching may
be considered to enhance performance. Performance of the ABAC solution can be negatively affected if
each access decision requires an across-the-network attribute request. This is especially apparent in lowbandwidth, high-latency environments.
In addition to performance issues regarding attribute caching, the organization may evaluate a tradeoff
regarding the freshness of attributes and the impact upon security. Attributes that are not refreshed as often
will ultimately be less secure than attributes that are refreshed in real time. For example, a subject’s accessprivileges may have changed since the last refresh, but those updates will not be reflected in their available
access privileges until the next refresh.
Environments with sporadic connectivity will need to cache attributes at the local level. The security
ramifications of using cached attributes locally need to be determined within the implementing
organization at a policy level, and addressed with appropriate technical controls. In these disconnectedenvironments, administrators may employ risk-based analysis as a basis for access decisions, as some
attributes at the local (disconnected) level may change or be removed before the system refreshes its
attributes. The local (and disconnected system’s) possible use of stale cached attributes could introduce alevel of risk to the system, because the local system is not making use of the most recently available
attributes. Therefore, a risk-based analysis may be warranted as to whether or not to deploy this type ofsolution.
An example is a deployed ship with only intermittent, non-ideal connections to enterprise network fabrics.
Because the deployed user population will have only minor changes throughout their transit, supportingthe “unanticipated” system user is less of a concern. In this case, a bulk download and local storage ofsubject attributes may be sufficient for most local access control decisions. Therefore, subject attributedata could be stored locally on the ship throughout a deployment, and local applications and services
could use the data from the local store without the need to reach to an authoritative enterprise attributesource. While this is one example of a solution to an austere environment problem, it should not be
inferred that this is the only solution.
3.3.2

Attribute Source Minimization

Minimizing the number of attribute sources used in authorization decisions may improve performance andsimplify the overall security management of the ABAC solution. Organizations planning to deploy an
ABAC solution may benefit from establishing a close working relationship among all of the organization’s
stakeholders who will be involved in the solution’s deployment.

31

NIST SP 800-162

3.3.3

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONSInterface Specifications

To help ensure consistently reliable access to ABAC services, all organizations that participate in
information sharing through enterprise ABAC capabilities should fully understand the interface,interaction, and precondition requirements for all types of requests, including attribute and DP requests. It
is also important to ensure that as changes occur in the infrastructure and interface requirements, allrelying parties are provided notification of updates so they can plan to modify their components
accordingly.
3.4

Considerations during the Operations/Maintenance Phase

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

In the operations/maintenance phase, systems andproducts are in place and operating, enhancements
and/or modifications to the system are developed andtested, and hardware and/or software is added or
replaced. During this phase, the organization should
monitor performance of the system to ensure that it isconsistent with preestablished user and security
requirements, and needed system modifications areincorporated.
3.4.1

Availability of Quality Data

As the information needed to render access control decisions, and in some cases the decisions themselves,
is externalized from the objects and consumers, access to information and services will become more
dependent on an outside service’s ability to provide timely and accurate data. It is important that the
infrastructure be robust, well-tested, resilient, and scalable to mission needs. This is important to support
attribute services, attribute stores, policy stores, policy and attribute generation and validation
components, decision engines, and metaattribute repositories and conduits through which this informationmust pass. If outsourced, service agreements should detail availability, response time, and data quality andintegrity requirements. For example, failover, redundancy, and continuity of operations must be
considered for data and services that are considered mission critical. Maintaining high availability ofquality data requires that addition, updating, and deleting of attribute values is performed by trained,authorized individuals, and regularly audited.
Formal agreements between providers and consumers of attributes and services should meet an appropriate
standard of service, quality, availability, protection, and usage. Various laws and regulations establish
responsibilities, liabilities, and penalties related to the appropriate protection of information. The
agreements should capture these requirements as well as those related to responsibility for data.
Agreements establishing an appropriate level of trust between organizations are important. These
agreements would serve to formalize that trust relationship with a series of requirements and, possibly,
penalties for nonconformance. APSs and MOUs/MOAs for attribute services and authoritative andaccountable attribute sources can also serve to translate organizational policy into operational procedures.
The purpose, usage, participants, responsibilities, and administration of these services are described inthese formal agreements.

32

NIST SP 800-162

4.

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONS

Conclusion

This document brings together many previously separate bodies of ABAC knowledge in order to bridge
existing gaps between available technology and best practice ABAC implementations and to address the
emerging interest in ABAC within the Federal Government.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

ABAC controls access to objects by evaluating rules against the attributes of entities (subject and object),
operations, and the environment relevant to a request. ABAC relies upon the evaluation of attributes ofthe subject, attributes of the object, and a formal relationship or access control rule defining the allowable
operations for subject-object attribute combinations. ABAC enables precise access control allowing for alarge number of discrete inputs into an access control decision, providing a large set of possiblecombinations of those variables to reflect a diverse set of possible rules, policies, or restrictions on access.
Thus, ABAC allows an unrestricted number of attributes to be combined to satisfy a rich set of policies.
This document defines general concepts necessary to understand ABAC. Specifically it addresses subject
and object attributes, and generic features of an ABAC model and its components. It brings to lightnumerous considerations aligned to the system development lifecycle that must be factored in theplanning, design, development, implementation, and operation of ABAC capabilities within an enterprise.
The advantages and common pitfalls of ABAC mechanisms are discussed, especially for large enterprises.
ABAC capabilities will allow an unprecedented amount of flexibility and security while promoting
information sharing between diverse organizations. It is vital that these capabilities be developed anddeployed using a common foundation of concepts and functional requirements to ensure the greatest levelof interoperability possible. ABAC is well suited for large enterprises. An ABAC system can implement
existing role-based access control policies and can support a migration from role-based to a more granular
access control policy based on many different characteristics of the individual requester. It supports theexternal (unexpected) user and provides more efficient administration. However, an ABAC system is more
complicated, and therefore more costly to implement and maintain, than simpler access control systems.

33

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONSAppendix A — Acronyms and Abbreviations
Selected acronyms and abbreviations used in the guide are defined below.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

AASC
ABAC
AC
ACL
ACM
APS
CIO
CONOPS
COTS
DAC
DLP
DoD
DP
DPM
FICAM
FISMA
GUI
HIPAA
IBAC
IETF
IP
IR
IT
ITL
MAC
MP
NIST
NLP
NPE
OASIS
OMB
OPSEC
PAP
PDP
PEP
PII
PIP
PKI
RAdAC
RBAC
RFC
RLS
SAN
SDLC
SOA
SP
SQL
TCSEC

Attribute and Authorization Services Committee
Attribute Based Access Control
Access Control
Access Control List
Access Control Mechanism
Attribute Practice Statement
Chief Information Officer
Concept of Operations
Commercial Off-the-Shelf
Discretionary Access Control
Data Loss Prevention
Department of Defense
Digital Policy
Digital Policy Management
Federal Identity, Credential, and Access Management
Federal Information Security Management Act
Graphical User Interface
Health Insurance Portability and Accountability Act
Identity Based Access Control
Internet Engineering Task Force
Internet Protocol
Interagency Report
Information Technology
Information Technology Laboratory
Mandatory Access Control
Metapolicy
National Institute of Standards and Technology
Natural Language Policy
Non-Person Entity
Organization for the Advancement of Structured Information Standards
Office of Management and Budget
Operations Security
Policy Administration Point
Policy Decision Point
Policy Enforcement Point
Personally Identifiable Information
Policy Information Point
Public Key Infrastructure
Risk-Adaptable Access Control
Role-Based Access Control
Request for Comment
Row Level Security
Storage Area Network
System Development Life Cycle
Service Oriented Architecture
Special Publication
Structured Query Language
Trusted Computer System Evaluation Criteria

34

NIST SP 800-162

TD
TLS
XACML
XML

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONSTechnology Development
Transport Layer Security
Extensible Access Control Markup Language
Extensible Markup Language

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162

35

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONSAppendix B — References[ANSI359] InterNational Committee for Information Technology Standards, American National Standard
for Information Technology - Role Based Access Control, ANSI/INCITS 359-2012, American National
Standards Institute, New York, May 29, 2012, 56pp.
https://webstore.ansi.org/Standards/INCITS/INCITS3592012.
[ANSI499] InterNational Committee for Information Technology Standards, Information technology Next Generation Access Control – Functional Architecture (NGAC–FA), ANSI/INCITS 499-2018,
American National Standards Institute, New York, January 30, 2018, 57pp.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162[CGLO09] I. F. Cruz, R. Gjomemo, B. Lin, and M. Orsini, “A Constraint and Attribute Based Security
Framework for Dynamic Role Assignment in Collaborative Environments”, in Collaborative Computing:
Networking, Applications and Worksharing, Lecture Notes of the Institute for Computer Sciences, Social
Informatics and Telecommunications Engineering, vol. 10, 322-339 (2009). https://doi.org/10.1007/9783-642-03354-4_24.
[FEDCIO1] Federal Chief Information Officers Council, Federal Identity, Credential, and Access
Management (FICAM) Roadmap and Implementation Guidance (Version 1.0). Office of Management andBudget, Washington, D.C., November 10, 2009, 220pp.
[FEDCIO2] Federal Chief Information Officers Council, Federal Identity, Credential, and Access
Management (FICAM) Roadmap and Implementation Guidance (Version 2.0). Office of Management andBudget, Washington, D.C., December 2, 2011, 478pp. https://www.idmanagement.gov/wpcontent/uploads/sites/1171/uploads/FICAM_Roadmap_and_Implem_Guid.pdf.
[FK92] D. F. Ferraiolo and D. R. Kuhn, “Role-Based Access Controls,” in Proceedings of 15th NISTNCSC National Computer Security Conference, National Institute of Standards and Technology,
Gaithersburg, Maryland, 554-563 (1992). https://csrc.nist.gov/publications/detail/conferencepaper/1992/10/13/role-based-access-controls.
[NIST7316] V. C. Hu, D. F. Ferraiolo, and D. R. Kuhn, Assessment of Access Control Systems, NISTIR
7316, National Institute of Standards and Technology, Gaithersburg, Maryland, September 2006, 60 pp.
https://doi.org/10.6028/NIST.IR.7316.
[NIST7657] NIST/NSA Privilege (Access) Management Workshop Collaboration Team, A Report on thePrivilege (Access) Management Workshop, NISTIR 7657, National Institute of Standards andTechnology, Gaithersburg, Maryland, March 2010, 48 pp. https://doi.org/10.6028/NIST.IR.7657.
[NIST7665] Proceedings of the Privilege Management Workshop, September 1-3, 2009, NISTIR 7665, S.
A. Durrant, T. Brewer, and A. Sokol, eds., National Institute of Standards and Technology,
Gaithersburg, Maryland, January 2010, 10 pp. https://doi.org/10.6028/NIST.IR.7665.
[NIST7874] V. C. Hu, and K. Scarfone, Guidelines for Access Control System Evaluation Metrics,
NISTIR 7874, National Institute of Standards and Technology, Gaithersburg, Maryland, September 2012,
48pp. https://doi.org/10.6028/NIST.IR.7874.
[NIST800-100] P. Bowen, J. Hash, and M. Wilson, Information Security Handbook: A Guide forManagers, NIST Special Publication 800-100, National Institute of Standards and Technology,

36

NIST SP 800-162

GUIDE TO ABAC
DEFINITION AND CONSIDERATIONSGaithersburg, Maryland, October 2006 (including updates as of March 7, 2007), 178pp.
https://doi.org/10.6028/NIST.SP.800-100.
[NIST800-53] Joint Task Force Transformation Initiative, Security and Privacy Controls for Federal
Information Systems and Organizations, NIST Special Publication 800-53 Revision 4, National Instituteof Standards and Technology, Gaithersburg, Maryland, April 2013 (including updates as of January 22,2015), 462pp. https://doi.org/10.6028/NIST.SP.800-53r4.
[NIST800-63-3] P. Grassi, M. Garcia, and J. Fenton, Digital Identity Guidelines, NIST Special
Publication 800-63-3, National Institute of Standards and Technology, Gaithersburg, Maryland, June2017 (including updates as of December 1, 2017), 74pp. https://doi.org/10.6028/NIST.SP.800-63-3.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-162[NIST800-63B] P. Grassi, E. Newton, R. Perlner, A. Regenscheid, J. Fenton, W. Burr, J. Richer, N.
Lefkovitz, J. Danker, Y.-Y. Choong, K. Greene, and M. Theofanos, Digital Identity Guidelines:
Authentication and Lifecycle Management, NIST Special Publication 800-63B, National Institute ofStandards and Technology, Gaithersburg, Maryland, June 2017 (including updates as of December 1,2017), 79pp. https://doi.org/10.6028/NIST.SP.800-63b.
[RFC5246] T. Dierks and E. Rescorla, The Transport Layer Security (TLS) Protocol, Version 1.2, RFC
5246, Internet Engineering Task Force, Network Working Group, August 2008, 104pp.
https://doi.org/10.17487/RFC5246.
[SCFY96] R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman, “Role-Based Access Control
Models,” IEEE Computer 29(2), 38-47 (February 1996). https://doi.org/10.1109/2.485845.
[TCSEC] U.S. Department of Defense, Information Assurance (IA), DoD Directive 8500.1, U.S.
Department of Defense, Washington, D.C., October 24, 2002, 25 pp.
https://dodcio.defense.gov/Portals/0/Documents/DIEA/850001p.pdf.
[WWJ04] L. Wang, D. Wijesekera, and S. Jajodia, “A Logic-based Framework for Attribute Based AccessControl,” in Proceedings of the 2004 ACM workshop on Formal Methods in Security Engineering, FMSE
‘04, ACM, New York (October 2004) 45-55. https://doi.org/10.1145/1029133.1029140.
[XACML] “OASIS eXtensible Access Control Markup Language (XACML) TC,” Organization for the
Advancement of Structured Information Standards [Web page], https://www.oasisopen.org/committees/tc_home.php?wg_abbrev=xacml.
[YT05] E. Yuan and J. Tong, “Attributed Based Access Control (ABAC) for Web Services,” inProceedings of the 2005 IEEE International Conference on Web Services, ICWS 2005, IEEE Computer
Society, Los Alamitos, California (2005) 561-569. https://doi.org/10.1109/ICWS.2005.25.

37