UNCLASSIFIED

Attribute Based Access Control (ABAC)

Engineering Blueprint v. 2.0
18 May 2011

DISA
Identity Management Division (PEO-MA, IA4)

UNCLASSIFIED

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Table of Contents
Executive Summary .................................................................................................................... 1
1
1.1
1.2
1.3
1.4
1.5
1.6
1.7

Introduction .......................................................................................................................... 2
Mission Description ............................................................................................................................. 2
Purpose ............................................................................................................................................... 3
Intended Audience .............................................................................................................................. 3
Scope .................................................................................................................................................. 3
Dynamic Access Control Development Approach .............................................................................. 4
Assumptions ........................................................................................................................................ 5
Symbol Conventions ........................................................................................................................... 5
ABAC from a Strategic and Operational Context ............................................................. 6

2.1 Information Sharing Paradigm ............................................................................................................ 6

2.2 Access Control in Support of Information Sharing .............................................................................. 9

Attribute Based Access Control ....................................................................................... 13

3.1 What is ABAC?.................................................................................................................................. 13

3.2 ABAC Components ........................................................................................................................... 14

Architectural Interfaces and Specifications .................................................................... 19

4.1 ABAC Component Message Overview ............................................................................................. 19

4.2 Message Types ................................................................................................................................. 20
4.3 PEP Specifications ............................................................................................................................ 22
4.3.1 Component Behavior: Enforce Access Control Decision ............................................................ 23
4.4 PDS Specifications ............................................................................................................................ 24
4.4.1 Component Behavior: Generate Access Control Decision ......................................................... 26
4.4.2 Component Behavior: Request Access Control Policy ............................................................... 29
4.4.3 Component Behavior: Request Attributes ................................................................................... 31
4.5 AS Specifications .............................................................................................................................. 32
4.5.1 Component Behavior: Retrieve Attributes ................................................................................... 33
4.6 PS Specifications .............................................................................................................................. 34
4.6.1 Component Behavior: Retrieve Policy ........................................................................................ 35

5
5.1
5.2
5.3
5.4
5.5
5.6
5.7

ABAC Demonstrations and Pilots .................................................................................... 37

Joint Rapid Architecture Experiment (2006/2007) Demonstration.................................................... 37
Empire Challenge (08/09) Demonstration......................................................................................... 37
Joint Expeditionary Forces Exercises 2008 Demonstration ............................................................. 38
The Joint Forces Command Defense Knowledge Online/Joint Knowledge Online Pilot .................. 38
PvM Pilot Phase I .............................................................................................................................. 39
PvM Pilot Phase II ............................................................................................................................. 39
OpenAM Reference Implementation ................................................................................................. 39
Implementation Approach and Lessons Learned .......................................................... 41

6.1 Integration with Native Access Controls ........................................................................................... 41

6.2 Policy Creation .................................................................................................................................. 41
6.3 Standards .......................................................................................................................................... 41
6.4 Performance and Scalability ............................................................................................................. 41
6.5 Design Considerations ...................................................................................................................... 42
6.5.1 PEP Policy Enforcement Point ................................................................................................. 42
6.5.2 Policy Decision Service ............................................................................................................... 43
6.5.3 Attribute Service .......................................................................................................................... 44
6.5.4 Policy Service .............................................................................................................................. 44
ii

UNCLASSIFIED

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

7
7.1
7.2
7.3
7.4

Enabling Performance and Resiliency ............................................................................ 45

Policy Enforcement Point .................................................................................................................. 46
Policy Decision Service ..................................................................................................................... 46
Access Control Component Horizontal Scaling ................................................................................ 47
High Availability Design..................................................................................................................... 49
Issues and Challenges ...................................................................................................... 51

Appendix A: Acronyms and Abbreviations ............................................................................ 54

Appendix B: Data Dictionary ................................................................................................... 58
Appendix C: References .......................................................................................................... 62
Appendix D: Security Frameworks Overview ........................................................................ 64
DISA IdAM Framework ............................................................................................................................. 64
Federal Identity, Credentialing, and Access Management ....................................................................... 66
NSA Enterprise Security Management ..................................................................................................... 67
Comparison of Security Frameworks ........................................................................................................ 68
Appendix E: Supporting Documentation ................................................................................ 70
Policy Analysis Requirements ................................................................................................................... 70
Government and Market Surveys ............................................................................................................. 70
Operational Use Cases ............................................................................................................................. 70
Gap Analysis Document............................................................................................................................ 70
Operational Requirements Document....................................................................................................... 70
Research Documentation and Results ..................................................................................................... 71
System Requirements Document ............................................................................................................. 71
Risk Analysis Report ................................................................................................................................. 71
Engineering Blueprint- v1 .......................................................................................................................... 72
Proof of Concept Design Document ......................................................................................................... 72
Test Plan ................................................................................................................................................... 72
Reference Implementation ........................................................................................................................ 72
Appendix F: Architectural Patterns and Performance Modeling.......................................... 73
Authorization Pattern 1.............................................................................................................................. 73
Authorization Pattern 2.............................................................................................................................. 76
Authorization Patterns 3 6 ...................................................................................................................... 78
Performance Modeling .............................................................................................................................. 79
Authorization Pattern 1 Timing .................................................................................................................. 80
Authorization Pattern 1 with Multiple Services .......................................................................................... 82
Authorization Pattern 2 Timing .................................................................................................................. 84

List of Figures
Figure 1: Dynamic Access Control Development Approach ......................................................................... 4
Figure 2: Symbol Convention ........................................................................................................................ 5
Figure 3: Engineering Blueprint in Support of GIG 2.0 ................................................................................. 8
Figure 4: Access Control Today .................................................................................................................. 10
Figure 5: Dynamic Access Control .............................................................................................................. 11

iii

UNCLASSIFIED

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Figure 6: Basic ABAC Authorization Pattern............................................................................................... 16
Figure 7: Logical ABAC Interfaces .............................................................................................................. 19
Figure 8: Enforce Access Control Decision ................................................................................................ 24
Figure 9: Generate Access Control Decision Process Flow ....................................................................... 28
Figure 10: Request Access Control Policy Process Flow ........................................................................... 30
Figure 11: Request Attributes Process Flow............................................................................................... 32
Figure 12: Retrieve Attributes Process Flow............................................................................................... 34
Figure 13: Retrieve Policy Process Flow .................................................................................................... 36
Figure 14: PEP Integration Patterns ........................................................................................................... 43
Figure 15: Authorization Pattern 1 Flow...................................................................................................... 45
Figure 16: Multiple PEPs............................................................................................................................. 47
Figure 17: Multiple PDSs ............................................................................................................................ 48
Figure 18: High Availability Configuration ................................................................................................... 49
Figure 19: DISA IdAM Framework .............................................................................................................. 65
Figure 20: FICAM Services Framework ...................................................................................................... 67
Figure 21: ESM Services ............................................................................................................................ 68
Figure 22: Security Framework Mapping .................................................................................................... 69
Figure 23: Authorization Pattern 1 .............................................................................................................. 74
Figure 24: Authorization Pattern 2 .............................................................................................................. 77
Figure 25: Authorization Pattern 1 Timing .................................................................................................. 81
Figure 26: Authorization Pattern 1 Timing with Multiple Services............................................................... 83
Figure 27: Authorization Pattern 2 Timing .................................................................................................. 85

List of Tables
Table 1: Mission Support Capabilities........................................................................................................... 6
Table 2: JCA Alignment to Blueprint ............................................................................................................. 8
Table 3: Access Control Types ................................................................................................................... 11
Table 4: ABAC Enablement of Mission Support Capabilities ..................................................................... 13
Table 5: ABAC Components ....................................................................................................................... 14
Table 6: ABAC Programs and Initiatives..................................................................................................... 17
iv

UNCLASSIFIED

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Table 7: ABAC Message Types .................................................................................................................. 20
Table 8: Policy Enforcement Point Functions ............................................................................................. 22
Table 9: Enforce Access Control Decision Behavior .................................................................................. 23
Table 10: Policy Decision Point Functions .................................................................................................. 25
Table 11: Generate Access Control Decision Behavior.............................................................................. 26
Table 12: Request Access Control Policy Behavior ................................................................................... 29
Table 13: Request Attributes Behavior ....................................................................................................... 31
Table 14: Attribute Service Functions ......................................................................................................... 32
Table 15: Retrieve Attributes Behavior ....................................................................................................... 33
Table 16: Policy Service Functions ............................................................................................................. 34
Table 17: Retrieve Policy Behavior ............................................................................................................. 35
Table 18: ABAC Issues and Challenges ..................................................................................................... 51
Table 19: Steps for Authorization Pattern 1 ................................................................................................ 75
Table 20: Steps for Authorization Pattern 2 ................................................................................................ 77
Table 21: SSRA Authorization Patterns ...................................................................................................... 78

UNCLASSIFIED

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Executive Summary
The information-sharing paradigm is shifting from a need-to-know to need-to-share philosophy
in order to enable access to mission critical, time sensitive information. In support of mission
operations and to improve collaboration with federal agencies and coalition partners around the
globe, the Department of Defense (DoD) is developing an enterprise-wide dynamic access
control reference architecture to securely share information across administrative and
organizational boundaries. The dynamic access control reference architecture addresses the
ability to accommodate anticipated and unanticipated users,1 dynamic communities of interest
(COIs), and changing mission needs at modern day mission tempos.2 The reference architecture
combines information from the enterprise including policies, attributes, resource metadata, and
environmental attributes to provide Attribute Based Access Control (ABAC) capabilities to
dynamic operating environments.
To realize the reference architecture, the Defense Information Systems Agency (DISA) Identity
Management Division Privilege Management Branch (PEO-MA IA43) developed the ABAC
Engineering Blueprint. The Engineering Blueprint addresses dynamic access control concepts,
requirements, functionality, and logical architecture with an acute focus on issues pertaining to
decisioning and enforcement, and their interfaces for policy and attribute retrieval. The
Engineering Blueprint also includes design considerations and lessons learned that address
technical and operational issues including adoption, performance, high availability, and
deployment. The reference architecture and requirements described in this document serve as
the benchmark to research, develop, test, and evaluate dynamic access control solutions.
The efforts of DISA provide the foundation for an access control mechanism that enables the
effective and efficient sharing of information in support of the warfighter mission. To learn
more about dynamic access control, ABAC, and the efforts of DISA IA4, contact
PvM_Support@[Link].

An unanticipated user is a user that does not have an account in the resource identity store and has not pre-registered for access
to the resource.
2

DoD Privilege Management Roadmap, 6 January 2010

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Introduction

1.1 Mission Description

In support of the modern day operational environment, access to information is a key enabler for
mission success. Often, mission planners, commanders, and operational forces cannot wait for
registration to information systems and the assignment of specific permissions before accessing
mission critical, time sensitive data. To facilitate dynamic access to information, the DoD is
shifting toward a net-centric information-sharing environment -- the Global Information Grid
(GIG) 2.0.3 This shift requires information systems to evolve their current authentication and
access control approaches to support interoperability with other federal agencies, the
International Community (IC), and coalition partners.
Several defense reviews, strategies, and recommendations reports highlight the need for
enhanced access control solutions to enable secure, dynamic access to information resources.
The 2010 Quadrennial Defense Review (QDR) concluded that modern armed forces simply
cannot conduct high-tempo, effective operations withoutassured access to cyberspace.4 The
Program Decision Memorandum (PDM) III Core Enterprise Services Findings and
Recommendations Report recommended that DISA establish a common set of authorization
services for use on Non-Secure Internet Protocol Router Network (NIPRNet), Secure Internet
Protocol Router Network (SIPRNet), and the Joint Worldwide Intelligence Communications
System (JWICS), with a consideration toward Federal and Coalition networks. In addition, the
DoD Enterprise Architecture Transition Strategy identifies Information Assurance (IA)
technologies that enable transaction-based access control, information sharing across security
domains, protection of information and resources, and maintenance of Situational Awareness in
the target GIG as one of the key target GIG technologies.5
To address the need for an access control mechanism that enables secure information sharing,
DISA IA43 developed the ABAC Engineering Blueprint. The Engineering Blueprint outlines a
reference architecture for dynamic access control to resources across administrative and
organizational boundaries within the DoD enterprise and with external partners. Collaborating
with the National Security Agency (NSA) Enterprise Security Management (ESM), the DISA
and NSA joint team have started initiatives to understand the very complex access control
problem space and provide the basic building blocks needed to establish an enterprise-wide
capability. As part of this initiative, the DISA IA43 team is responsible for supporting the
development of a dynamic access control solution and leading the engineering activities to field
operational dynamic access control capabilities for the DoD enterprise.

Initial Capabilities Document for the Global Information Grid Information Assurance, NSA, 06 March 2006

Quadrennial Defense Review Report, February 2010

DoD Enterprise Architecture Transition Strategy, February 2008

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

1.2 Purpose
The purpose of the Engineering Blueprint is to describe dynamic access control concepts,
functionality, and logical reference architecture. The Engineering Blueprint defines the
architectural building blocks of a dynamic access control solution, which includes the following:

Technology standards
Protocols
Specifications
Interface definitions
Infrastructure
Performance criteria
Lessons Learned from Reference Implementations, pilots, and exercises

One of the goals of the Engineering Blueprint is to support the research, development, testing,
and evaluation of dynamic access control solutions. This document provides guidance for the
implementation of a dynamic access control solution and is the basis for product evaluations.
1.3 Intended Audience
The Engineering Blueprint target audience includes the following:

DoD, IC, coalition partners, and other federal agencies

Senior management and mission owners who enforce decisions about the IT security
budget
IT security program managers, who implement the security program
Information system security officers (ISSOs) responsible for IT security
IT system owners of system software and/or hardware used to support dynamic access
control functions
Information owners of data stored, processed, and transmitted by the IT systems
Business or functional managers, who are responsible for the IT procurement process
Technical support personnel and product vendors

1.4 Scope
The Engineering Blueprint addresses dynamic access control concepts, functionality, and logical
architecture with an acute focus on issues pertaining to access control decisioning and
enforcement, and their interfaces for policy and attribute retrieval. The goal of the Engineering
Blueprint is to design a flexible, enterprise scale access control decisioning and enforcement
mechanism to enable information sharing and accommodate anticipated and unanticipated users.
The Engineering Blueprint includes discussion of attributes and other supporting access control
and information security initiatives to highlight the dependencies and interactions with access
control decision and enforcement with related DoD/IC efforts. Although discussed, these
dependencies are currently not in the purview of DISA IA43.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

1.5 Dynamic Access Control Development Approach

In order to develop a dynamic access control reference architecture and lead the engineering
activities to develop, deploy, and sustain operational capabilities for the DoD. The DISA IA43
team investigated key Programs of Record (POR) that support Doctrine, Organization, Training,
Materiel, Leadership, Personnel, and Facilities (DOTMLPF) to identify how information is
currently accessed, stored, and where it is physically located. This information was used to
develop use cases that captured core information about access control mechanisms, information
flow models and the current technologies being used by these PORs.
In addition, DISA is working with the NSA to conduct pilots and exercises6 to demonstrate
dynamic access control technical capabilities and product performance. As part of this initiative,
DISA is collaborating with partners from the DoD, IC, Federal, Civilian, and industry to develop
standards, prototype technology, and integrate services related to dynamic access control. This
information enables DISA to develop best practices and lessons learned for developing an
enterprise scale dynamic access control capability.
Market surveys, pilots, demonstrations, and laboratory exercises, together with the Engineering
Blueprint, play a vital part for the dynamic access control development approach as illustrated in
Figure 1 below.

Figure 1: Dynamic Access Control Development Approach

Section 7.1 elaborates on DISA and NSA sponsored pilots and demonstrations.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

1.6 Assumptions
Key assumptions for the Engineering Blueprint include the following:

The following topics, although introduced and discussed in the Blueprint, are outside the
scope of IA43:
Attribute Management
User Attribute Services
Environmental Attribute Services
Digital Policy Management
Policy Services
Metadata and Resource Management
Public Key Infrastructure (PKI) and credential validation
The dynamic access control solution discussed in this document is based on eXtensible
Access Control Markup Language (XACML) version 2.0
The terminology used in this document is consistent with the DISA Identity and Access
Management (IdAM) security framework described in Appendix D.
1.7 Symbol Conventions
The figures in the Engineering Blueprint use the following color scheme to illustrate alignment
with the DISA IdAM Security Framework service categories listed in Appendix D.

Figure 2: Symbol Convention

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

ABAC from a Strategic and Operational Context

2.1 Information Sharing Paradigm

In order to maintain operational and tactical superiority on the battlefield, it is essential that
information be readily available, and easily disseminated to those that need the information,
when they need it. ABAC can facilitate secure information sharing by providing a greater
emphasis on leveraging policies, attributes, and metadata to allow access to information in a
controlled manner. Stove-piped information silos are commonplace in todays technology
infrastructure inhibiting communication and information sharing across all four major DoD
branches, other federal agencies, the intelligence communities, and coalition partners.7 The next
generation GIG 2.0 strategy addresses these issues. The GIG is a network of computer systems
and applications used to securely store, process, and disseminate data amongst systems and
warfighters, and support personnel throughout the DoD enterprise. In transitioning to GIG 2.0,
the DoD is developing innovations to effectively leverage information as a strategic asset.8 The
accessibility of information is essential when establishing an operational environment where
faster decision-making is the norm, and tactical dominance is consistently maintained and
executed. As defined by the DoD Privilege Management Roadmap and the GIG 2.0 Information
Assurance Initial Capabilities Document, the capabilities required to make GIG 2.0 a dynamic,
global, federated mission support enabler are listed in Table 1.
Table 1: Mission Support Capabilities
Mission Support Capability

Description

More Accurately Control Access to Information and

Resources

Enables mission planners, commanders, and

operational forces to discover and access
information needed to achieve mission success
regardless of domain or geography.

Support Federated Operations and Dynamic COIs

Enables operational forces to quickly share

information and collaborate with US Joint forces,
federal agencies, the IC, and coalition partners in
support of the need to share paradigm.

Employ a Standards-Based Approach

Enables use of a wide range of open source,

Commercial Off-the-Shelf (COTS), Government
Open Source (GOS) and custom technology while
maintaining interoperability and consistency of
operations.

7
8

DoD Privilege Management Roadmap, 6 January 2010

Initial Capabilities Document for the Global Information Grid Information Assurance, NSA, 06 March 2006

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Mission Support Capability

Description

Assure Enterprise Resources are Available

Ensures terminals, communications, information

systems and enterprise services remain available
and accessible to mission operators and
warfighters to satisfy mission needs when required.

Reduce Personnel Resource Demands

Enables redirection of manpower from technology

management and administration to warfighter
programs by reducing the administrative burden
required to manage and maintain service
requesters and the security of information systems.

Assured Information Sharing

Provides authorized service requesters with

appropriate access to networks, systems,
applications, and data across the enterprise; and
enables dynamic, trustworthy information sharing
across component domains to enable timely
creation and management of COIs.

As the DoD moves toward GIG 2.0 and the Net-Centric Operating Environment (NCOE), it is
critical to have access to timely and relevant mission information in a controlled fashion. The IA
Systems Technology Evolution Plan (STEP)9 provides a chronological view of capabilities and
existing technologies, expected enhancements, interim states, and theoretical elements required
to obtain the NCOE desired end states. The STEP conveys linkages between IA capabilities and
desired warfighter capabilities described in the NCOE in support of the GIG IA Portfolio. The
STEP describes the evolution of IA capabilities in support of three Capability Thread
Implementation Plans (CTIPs) from the GIG 2.0 Joint Capability Areas (JCAs): Secure
Information Exchange (SIE), Protected Data and Networks (PDN) and Respond to Attack Events
(RAE). The SIE plan focuses on ensuring assured mission success in the Net-Centric
environment through dynamic information sharing across the enterprise. Within the SIE plan,
the Engineering Blueprint directly addresses SIE 3, the Control Access to Information Resources
system function, by enabling access control decision and enforcement. Figure 3 below depicts
the different JCAs and the correlation between the different documents/frameworks that support
the Engineering Blueprint initiative:10

National Security Agency Information Assurance Directorate: STEP Practitioners Guide, September 2009

10

ALIGNMENT FRAMEWORK FOR GIG IA ARCHITECTURE, AUGUST 2009

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Figure 3: Engineering Blueprint in Support of GIG 2.0

In addition to the STEP and the SIE plan, Table 2 below identifies specific GIG 2.0 goals/objectives that
the Engineering Blueprint and ABAC support.
Table 2: JCA Alignment to Blueprint
DoD Initiative
Architecture Framework for GIG (AFG)

Related goals to the Engineering

Blueprint/ABAC Solution

Assured access, collaboration, and information

sharing

Support GIG IA Architecture to facilitate data

management and collaboration

GIG IA ICD / GIG IA Architecture

Enterprise information is securely and seamlessly

available to mission partners

Achieve net-centricity by supporting dynamic

information sharing

Cyber Identity Information Assurance (CIIA)

Enable secure mission-driven access to information

and services and also provide the ability to securely
locate data and services across the extended
information enterprise

Facilitate seamless information management and

collaboration across information security domains

Manage Access by managing identity credentials,

privileges and resources

Allow GIG service requesters to collaborate across

information or security domains.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
DoD Initiative

Related goals to the Engineering

Blueprint/ABAC Solution

Information Sharing based upon need to know while

DoD Net-Centric JCD

maximizing situational awareness (SA) with

authorized service requesters

The NCOE addresses that mission partners must

have rapid access to relevant, accurate, and timely
information, and also the ability to create and share
the knowledge required to make superior decisions in
an assured environment amid unprecedented
11
quantities of operational data
12

DoD Identity Credential and Access Management

Align existing DoD identity and access management

initiatives into an enterprise-wide set of DoD ICAM
services

Establish unified governance for enterprise-wide

secure information sharing

Establish trust foundation for secure information

sharing and collaboration for DoD and its mission
partners13

While facilitating access to the information needed for achieving mission success has taken to
the forefront of the national security agenda, the cyber capability and technology to secure
information is equally as important. The shifting nature of partnerships and alliances, the
varying levels of collaboration and trust required, and the large and diverse populations of people
requiring access to information demand more flexible mechanisms for access control. Because
mission operations are dynamic, the capability to access information seamlessly needs to be agile
to adapt rapidly to changing mission environments.
2.2 Access Control in Support of Information Sharing
Many of todays information technology environments rely heavily on pre-populated Access
Control Lists (ACL) to determine who is allowed access to certain information. Under these
traditional need-to-know constructs, only those individuals, programs, or devices that have
specific permission to use a particular resource are granted access. As shown in Figure 4, ACLs
allow for the assignment of access rights through a manual registration process, but the
management of large populations of service requesters results in significant administrative
overhead. Maintenance of exhaustive lists of service requesters for every resource is a tedious,
and error prone process. In addition, this process cannot keep pace with the dynamic nature of
information sharing required for todays operational landscape, and creates information
stovepipes impeding the ability to enable authorized access to mission essential data in a timely

11

Joint Capabilities Document (JCD) for Net-Centric Operational Environment (NCOE), December, 2006

12

DoD ICAM Harmonization Assessment Version (Draft) 0.61, 25 August 2010

13

2010 08 20 DoD ICAM Harmonization Assessment v0 6 1[Link]

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

manner. Furthermore, it creates opportunities for the exploitation of information assets due to
vulnerabilities caused by managing an overwhelming volume of service requester accounts and
permissions.

Figure 4: Access Control Today

To increase the responsiveness of DoD systems to changing operating conditions, access to

information should be governed by digital policies that can be rapidly created, modified, and
consumed by IT systems. The digital policies should define the rules and conditions under
which someone is authorized for access by using user characteristics, or attributes, and resource
characteristics, or metadata, as opposed to membership to a resource ACL. The attributes can be
collected, stored, and managed independently of the resource. Additionally, as long as a source
for the appropriate attributes and metadata is available to fulfill a policy, an access control
decision can be rendered. To quickly accommodate changing mission partners based on shifting
tactical needs, removing the need to register service requesters with resources greatly enhances
the agility of operational forces in accessing data and applications. An unregistered service
requester attempting to access a resource is known as the unanticipated user. An unanticipated
user has no prior service requester data registered with the resource identity repository, but is
part of the DoD enterprise, IC, or an external mission partner and has an appropriate credential.
As shown in Figure 5, the unanticipated user should be dynamically granted or denied access
based on policy without requiring pre-registration or approval.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

10

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Figure 5: Dynamic Access Control

In addition to ACLs, there are several common access control models that are used to decide and
enforce access. Table 3below briefly highlights the applicability of common access control
models to dynamic information sharing and the unanticipated user.
Table 3: Access Control Types
Access Control Types
Identity Based Access Control (IBAC)
Access Control List (ACL)

Description

Requires a service requester to be directly assigned

to a resource by name

Heavy Administrative burden

Does not scale to meet DoD enterprise
Does not support dynamic information sharing or
unanticipated users

Role Based Access Control (RBAC)

Policy is driven by categories of service requesters

defined by their relationship with the organization
(e.g., system administrators, logistics)

Permissions and service requesters are manually

assigned to roles

New roles often need to be created to handle

changing operating conditions or requirements

Does not support dynamic information sharing or

unanticipated users

Attribute Based Access Control (ABAC)

Policy is defined by assembling attributes and

metadata into rules

Permissions are defined through access control

policies tied to resources policies need to be modified
to handle changing operating conditions or
requirements

Does support dynamic information sharing and the

unanticipated user if the appropriate policies,
attributes, and metadata are available

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

11

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Access Control Types
Risk Adaptive Access Control (RAdAC)

Description

Policy is defined by the security risk and operational

need of the situational context in addition to access
control policies

Permissions are adapted at run time to accommodate

the value of the information being protected, mission
need, and risk tolerance

Does support dynamic information sharing and the

unanticipated user based on operational context

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

12

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Attribute Based Access Control

3.1 What is ABAC?

To accommodate federated mission operations, the appropriate policies, attributes, and metadata
need to be defined to ensure seamless operation and protect information assets across sovereign
boundaries. ABAC enables the transition away from access control based solely on identity
through evaluating and enforcing policies. It does so by leveraging enterprise sources of access
control policies, attributes, and data in support of dynamic operating environments. In line with
IA43s objective of enterprise wide capability, leveraging attributes, metadata, and digital
policies to secure access to resources requires a flexible and robust decisioning and enforcement
mechanism.
In ABAC, digital policies are defined and managed by administrators to protect specific
resources. These digital policies can be derived from partnerships between organizations, such
as a Memoranda of Agreement, or from collaboration on a particular focus area, such as
Communities of Interest. Digital policies can also be derived from compliance and information
assurance policies issued by the DoD CIO or the Joint Chiefs of Staff, such as implementing
HIPAA privacy rules or data releasability to coalition partners. ABAC enables a flexible means
of securely sharing and protecting information through the enforcement of digital policies
applicable to specific resources. Table 4 below represents how ABAC meets the goals and
objectives essential to the success of assured information sharing.
Table 4: ABAC Enablement of Mission Support Capabilities
Mission Support Capability

ABAC Enablement

More Accurately Control Access to Information and

Resources

ABAC facilitates access control to resources based

on the requesters attributes, resource metadata,
mission status, and other pertinent operational and
environmental factors.

Support Federated Operations and Dynamic

Communities of Interest

ABAC supports a federated credential, policy, and

attribute management service infrastructure in
order to operate across dynamic communities of
interest and enterprise boundaries where joint
recognition of sovereign authority is necessary to
facilitate information sharing.

Employ a Standards-Based Approach

ABAC adopts commercial and federal standards based protocols, interfaces, specifications, and
technology, which foster interoperability and
federated operations.

Assure Enterprise Resources are Available

ABAC helps control access to information objects,

applications, networked devices, and network
boundaries to ensure that information systems and
enterprise services are readily accessible to
mission operators and warfighters.

Reduce Personnel Resource Demands

ABAC helps reduce the administrative burden of

managing and maintaining service requester
accounts and ACLs by enabling dynamic access
without service requester pre-registration.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

13

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Mission Support Capability

ABAC Enablement
ABAC helps ensure that service requester access
is controlled through the proper authorization and
access control mechanisms permitting the secure
enforcement of information sharing policies,
attributes, resource metadata, and environmental
attributes among dynamic COIs.

Assured Information Sharing

3.2 ABAC Components

The building blocks of ABAC include the components described in Table 5 below.
Table 5: ABAC Components
ABAC Component

Description

Service Requester

The service requester is any subject that requests

access to resources on the GIG.

Resource

The resource provides information or a service in

response to a service request.

Policy Enforcement Point (PEP)

The PEP intercepts service requests to resources

and enforces access control decisions. The PEPs
main function is to grant or deny service requester
access to the resource and enforce workflow
obligations or constraints on the interaction. The
PEP may also support service requester
authentication, by checking the status of a service
requesters credentials and verifying authentication
assertions.

Policy Decision Service (PDS)

The primary function of the PDS is to render an

access control decision based on a policy. PDS
calculates access control decisions based on the
security context of the interaction between the
service requester and the resource. The security
context is comprised of access control parameters
including policies, attributes, resource metadata,
and environment attributes. The PDS can retrieve
the access control parameters from sources at
various levels of the enterprise to render a
decision.

Policy Service (PS)

The PS retrieves access control policies from a

policy store. Typically, the PDS will use the PS to
request the applicable policies pertaining to the
security context of a transaction. Policies may
consist of multiple rules. A rule contains a Boolean
condition and the associated effect, which the PDS
uses to calculate an access control decision.

Attribute Service (AS)

The AS retrieves service requester information on

person, personae, and NPEs from an attribute
store. The AS retrieves service requester
information by sharing, federating, exchanging, and
accessing various attributes associated with an
entitys information from variety of authoritative
identity stores such as directories and databases.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

14

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
ABAC Component
Resource Metadata Service (RMS)

14

15

Environmental Attribute Service

Description
The resource metadata service retrieves resource
IA metadata and resource context metadata from
the metadata repository. IA metadata includes
classification and releasability restrictions as
defined by the Controlled Access Program
Coordination Office (CAPCO) register. The
resource context metadata includes resource
labels such as title, author, owner, or version.
The environmental attribute service retrieves
characteristics of the operating environment for the
service requester transaction. This can include
factors such as time of day, geography, Information
Operations Condition (INFOCON) level, or Defense
Condition (DEFCON) level.

Based on the specific requirements of the information system, the ABAC components can be
structured in a number of different authorization patterns (Discussed in Architectural Patterns
and Performance Modeling Appendix F). Figure 6 below depicts the most common
authorization pattern, Authorization Pattern 1.

14

Resource Metadata Services are not discussed in the Engineering Blueprint because the service has not been defined but may
be discussed in future versions of this document.
15

Environmental Attribute Services are not discussed in the Engineering Blueprint because the service has not been defined but
may be discussed in future versions of this document.
DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

15

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

16

Figure 6: Basic ABAC Authorization Pattern

The dynamic access control process typically begins with a service requester sending a request to
interact with a target resource. The PEP intercepts the request and may request authentication if
the service requestor has not previously authenticated. Upon verifying service requester
authentication, the PEP sends an authorization decision request to the PDS for an access control
policy decision. In order for the PDS to produce a valid access control decision, it requires input
from several sources. The PDS accomplishes this by first requesting access control policies from
the policy service. The PDS then requests attributes, resource metadata, and environmental
attributes as required by policy from their respective sources. Once the PDS receives the
requested access control information, the PDS determines a policy decision to either permit or
deny access. Next, the PDS forwards the decision to the PEP to execute the enforcement of the

16 Note: The ABAC components in the figure above use the color scheme defined in the Color Conventions section of this
document.
DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

16

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

decision. The PEP then either enforces the grant or denies access control decision for the service
requesters access to the requested target resource. In the case of the unanticipated user,
assuming that the service requester is able to perform authentication and the appropriate
attributes are accessible in the enterprise, the ABAC solution can accommodate a service
requester that is new to the system without pre-registering for an account. Additionally, the
granularity of resources protected by ABAC is directly related to the level of specificity of the
PEP because the ABAC policy structure allows for policy definition down to the specific data
element.
In support of the dynamic access control process, IA43 is focusing on the access control decision
and enforcement mechanisms. There are several additional programs and initiatives across DoD,
IC, Federal Civilian, and industry that are researching and developing services and capabilities
for credentials, attributes, metadata, and access control policy. Table 6 provides a short list of
key programs and initiatives of interest for ABAC.17
Table 6: ABAC Programs and Initiatives
Program or Initiative

Description

DMDC Enterprise Identity Attribute Service (EIAS)

The EIAS capability was created to provide identity

attributes, for person and NPE, to foster people
discovery and support the DoDs push toward a
net-centric environment that incorporates an ABAC
capability.

Backend Attribute Exchange (BAE)

The BAE is an attribute retrieval specification that

involves exchanging Personal Identity Verification
(PIV) cardholder information between an Attribute
Authority (AA) and a Relying Party (RP) in a secure
and trusted manner. The BAE is exploring how to
share attributes between federal agencies.

Global Force Management Data Initiative (GFM DI)

GFM DI is establishing a Joint data standard

enabling DoD systems to exchange authorized
organization, force structure, and billet data in a
common format.

Digital Policy Management Technical Exchange

Meeting (DPM TEM)

The DPM TEM is led by the NSA and is addressing

the definition and management of digital policies.
Access control policies are one of many policy
types under consideration.

National Institute of Standards and Technology

(NIST) Access Control Policy Testing (ACPT) and
Policy Analysis

NIST is currently researching and developing

advanced tools capable of deconflicting policies.
The ACPT is a tool that is currently under
development. It helps generate enforceable
XACML policies based on policy requirements and
modeling to facilitate policy implementation.

17

For additional information on key programs and initiatives related to ABAC, visit the Privilege Management References page in
Intelink: [Link]

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

17

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Program or Initiative

Description

Geospatial eXtensible Access Control Markup

Language (GeoXACML)

GeoXACML provides an extension to the XACML

Policy Language by supporting the enforcement of
access restrictions, based on geographic data. As
an extension to XACML, GeoXACML provides
support for spatial data types and spatial
authorization decision functions.

DoD Discovery Metadata Specification (DDMS)

The DDMS specifies a metadata set to describe

any data or service asset that is made known to the
Enterprise in support of content discovery services.
In essence, the DDMSs primary function is to
define the core set of metadata elements that must
be used to describe data assets made visible to the
DoD Enterprise.

IA Metadata Community of Practice

The IA Metadata Community of Practice is by

definition a taxonomy for security and information
assurance metadata. The IA metadata describes
the security properties and protection requirements
for data assets, protections applied to data assets,
and provenance. For example, this includes
classification, handling, releasability, and
dissemination restrictions for a data asset.

Robust Certificate Validation Service (RCVS)

RCVS provides the revocation status of PKI

certificates using Online Certificate Status Protocol
(OCSP). When used in conjunction with relying
party certificate checking functions, RCVS enables
X.509 authentication, encryption, and verification of
digital signatures

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

18

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Architectural Interfaces and Specifications

As specified in Section 3.2, the ABAC consists of multiple components working together to
enable dynamic access control. This section elaborates on the ABAC components, providing
interface specifications for each component and defines core functions, behaviors, and process
flows for each of them. The interfaces and functions described for each component are derived
from the DoD/IC Service Security Reference Architecture, NCES SAML Attribute Profile,
NCES Profile of Web Service Security, NCES Profile of XACML, and Organization for the
Advancement of Structured Information Standards (OASIS) SAML 2.0 profile documentation.
The behaviors discuss the sequence of activities performed as part of each function, and the
behaviors are depicted graphically in a process flow diagram. Each behavior contains the
following information:

Summary of the function behavior

Pre-condition for the behavior to occur

Input messages received by the

interface

Nominal and Alternate flows of

activities

Output messages transmitted by the

interface

Design considerations that influence

configuration and deployment

Actors participating in the interface

sequence of activities

Assessment of how COTS products

implement the interface

4.1 ABAC Component Message Overview

Figure 7 below provides a high-level use case diagram depicting how the different ABAC
interfaces interact to provide access control. These functions and behaviors may differ based
upon different authorization patterns but specifications discussed in this section follow
Authorization Pattern 1 from the DoD/IC Service Security Reference Architecture.

Figure 7: Logical ABAC Interfaces

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

19

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

The ABAC components communicate primarily through a Simple Object Access Protocol
(SOAP)-based protocol, which consists of Security Assertion Markup Language 2.0 (SAML)
and XACML elements. SAML 2.0 is a primary protocol used to exchange authentication and
authorization data between the ABAC components. It is an Organization for the Advancement
of Structured Information Standards (OASIS) standard based on eXtensible Markup Language
(XML) and uses security tokens containing assertions to pass information. Its main functions are
to send and receive attributes and access control queries and responses. XACML v2.0 is an
XML-based access control protocol, also derived by OASIS. Its main function is to send
policies and return decisions based on applicable policies and rules.18
4.2 Message Types
The ABAC interfaces exchange messages to verify and grant access requests made by service
requesters. The interactions between the ABAC components consist of a number of message
types. These messages sent between each of the components are described in detail in Table 7
below.
Table 7: ABAC Message Types
Message Type
XACMLAuthzDecisionQuery:
The PEP will send an authorization query,
XACMLAuthzDecisionQuery, in the SAML 2.0
Profile of XACML v2.0 to the PDS to request
an access control policy decision.

XACMLAuthzDecisionStatement:
The PEP will receive an authorization
statement, XACMLAuthzDecisionStatement,
in the SAML 2.0 Profile of XACML v2.0 from
the PDS with an access control policy
decision response.

Parameters
The message will contain AT LEAST the following-

Subject (<xacml-context:Subject>)
Resource (<xacml-context:Resource>)
Action (<xacml-context:Action>)
Environment (<xacml-context:Environment>)
Authentication validation (<saml:Evidence>)
Other optional attributes may be included

The message will contain AT LEAST the following-

SAML Query Reference ID

(<samlp:ResponseInResponseTo>)

Issuer/Unique Id (<saml:Issuer>)
Subject Name (<saml:Subject>)
Validity duration of message
(<saml:ConditionsNotOnOrAfter>,
<saml:ConditionsNotBeforeOrAfter>)

Authorization decision (<xacml-context:Decision>)

18

For more information on SAML and XACML, refer to the OASIS standards, which can be found on [Link]

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

20

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Message Type
XACMLPolicyQuery:
Once the PDS receives the
XACMLAuthzDecisionQuery, it will send a
policy request to the PS, identified as the
XACMLPolicyQuery, in the SAML 2.0 profile
of XACML v2.0 format to receive all applicable
access control policies. Policies can be
retrieved by resource, policy set, or specific
policy.

Parameters
The query will contain AT LEAST the following-

Resource Match ID (<xacml:ResourceMatchMatchId>)

Resource Match Data Type
(<xacml:AttributeValueDataType>)

Resource Attribute Designator

(<xacml:ResourceAttributeDesignator>)

OR

Policy Set (<xacml-samlp:PolicySetIdReference>):

OR

Policy ID Reference (<xacml:PolicyIdReference>)

XACMLPolicyStatement:
The PDS will receive a policy response,
XACMLPolicyStatement, in the SAML 2.0
Profile of XACML v2.0 from the PS with the
applicable access control policies for the
service request.

The response will contain AT LEAST the following-

Policy Combining Algorithm

(<xacml:PolicySetPolicyCombiningAlgId>)

Method to match resource attribute

(<xacml:ResourceMatchMatchId>)

Resource attribute name

(<xacml:ResourceAttributeDesignatorAttributeId>)

Method and attributes to match the action attribute

(<xacml:ActionMatchMatchId>)

Effect that will be returned upon successful evaluation

(<xacml:RuleEffect>)

AttributeQuery:
To retrieve the attributes required to generate
a decision, the PDS will send an attribute
request to the AS, identified as the
AttributeQuery, in the SAML v2.0 format to
receive all applicable attributes.

The query will contain AT LEAST the following-

AttributeStatement:
The PDS will receive an attribute response,
AttributeStatement, in the SAML v2.0 format
from the AS with the applicable attributes to
evaluate the access control policies and
render an access control decision for the
service request.

The assertion will contain AT LEAST the following-

Subject name (<saml:NameID>)

Attribute(s) to be retrieved (<saml:AttributeName>)

Status of retrieval (<samlp:Status>)

Unique Identifier (<saml:Issuer>)
Validity duration (<saml:Conditions>)
Attribute name(s) (<saml:Attribute>)
Attribute value(s) (<saml:AttributeValue>)
Attribute service signature (<ds:Signature>)

Depending on the security requirements of the system, encryption and digital signatures may be needed to
protect the confidentiality, integrity, and non-repudiation of the ABAC messages. Appendix E of the
DoD/IC Service Oriented Architecture (SOA) Security Reference Architecture defines message level
controls that may be used by ABAC components.
PKI provides a cryptographic infrastructure for key management to enable encryption and digital
signatures. Where used, PKI certificates will need to be validated through relying party functions and
revocation status checking. Revocation status checking can be accomplished by either checking a CRL or
sending an OCSP request to the RCVS.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

21

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

4.3 PEP Specifications

All PEP interaction with the PDS must conform to the SAML v2.0 profile of XACML using the
SOAP protocol. The PEP enforces access control decisions in response to a request from a
service requester wanting to access a target resource. The Enforce Access Control Decision
function is detailed in Table 8.
Table 8: Policy Enforcement Point Functions
Function
Enforce Access Control Decision

Description
Function performs the enforcement of the access
control decision. The results are a permit, deny,
not applicable, or indeterminate decision, and if
the resulting decision was to permit access, the
message to the PEP will include the requested
data or a link to the requested resource.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

22

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

4.3.1 Component Behavior: Enforce Access Control Decision

Table 9: Enforce Access Control Decision Behavior
Enforce Access Control Decision
Inputs

ResourceRequestMessage: The PEP receives a request for a resource from a

service requester. The service requester is the entity who is requesting access
to the information. The message can be of different types depending on the
protocol in use.

XACMLAuthzDecisionStatement: The PEP will receive a XACML Authorization

Decision Assertion from the PDS, which the PEP uses to either permit or deny
access to the service requester.

Outputs
Operations

XACMLAuthzDecisionQuery: The PEP sends an authorization decision

query to the PDS.

PEP permits access to data / resource by forwarding the request to the

resource provider.

PEP denies access to data / resource by not forwarding the request to the
resource and returning a not authorized message.

Actors

Preconditions
Nominal Flow

Service Requester
PEP
PDS
Service Requester has an authenticated session
TLS session is established between the Service Requester and PEP

1. The PEP receives a request message. The PEP will first check the
message for validity (format and signature).
a. PEP verifies the message. This includes the following:

Verify request message timestamp (<wsu:Timestamp>)

Check uniqueness of request messageID (<wsa:MessageID>)
Verify SAML Authentication Assertion (<saml:Assertion>)
Verify Digital Signature
Perform relying party certificate checking functions
Check revocation status of PKI certificates
Checked for potential replay attacks

2. The PEP sends a XACMLAuthorizationDecisionQuery to the

PDS. Message must contain:

The identifier of the service attempting to be accessed

The subject that is attempting the accessing service
The operation attempting to be invoked
3. The PDS makes a decision on whether the subject is permitted or
denied access to the resource for the action requested.
4. The PDS sends the authorization decision back to the PEP.
5. The PEP receives the authorization decision from the PDS. The PEP
will first check the message for validity (format and signature) as in
step 1.
6. Once the message is validated, PEP enforces the authorization
decision received from PDS.
a. Permit: the access request is forwarded to the resource provider
b. Deny: an access denied message is sent to the requester

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

23

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Enforce Access Control Decision
Alternate Flow

Invalid Message
1b. presents a message invalid error message.

Not Applicable Access Control Decision

6c. Not Applicable: The PDS could not find an applicable policy for the request,
access is denied, and an error message is sent to the requester.

Indeterminate Access Control Decision

6d. Indeterminate: The PDS could not find the information required to evaluate the
access control policy, access is denied, and an error message is sent to the
requester.

PDS Nonresponsive
PEP resends the XACMLAuthorizationDecisionQuery to the PDS. If
the PDS returns nothing a second time, then go to alternate flow: deny
access

Figure 8: Enforce Access Control Decision

4.4 PDS Specifications

All PDS interaction utilizing SAML/XACML among the PEP, PDS, Attribute Service, and PS
must conform to the SAML v2.0 profile of XACML. Using user attributes and access control
policies, the PDS renders an access control decision. The PDS performs the following functions
as detailed in Table 10.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

24

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Table 10: Policy Decision Point Functions
Function

Description

Generate Access Control Decision

The function generates an authorization response

from an access control query it receives from the
PEP. It uses the information it receives from the
Policy and Attribute Services to generate and send
an authorization decision response to the PEP.

Request Access Control Policy

The function sends a policy query to retrieve

policies from the Policy Service. The policy service
then accepts and processes the message. Once
the Policy Service gets the information needed, it
sends a response to the PDS containing the
corresponding policies.

Request Attributes

The function sends a query to the Attribute Service

to retrieve user, resource, and/or environment
attributes. The Attribute Service receives the
message, retrieves the appropriate attributes, and
reassembles the message. Then, the Attribute
Service sends a SAML Attribute Assertion back to
the PDS.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

25

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

4.4.1 Component Behavior: Generate Access Control Decision

Table 11: Generate Access Control Decision Behavior
Generate Access Control Decision
Inputs

XACMLAuthzDecisionQuery: The PDS receives an authorization decision

query from the PEP for the service request.

Outputs

XACMLAuthzDecisionStatementType: The PDS returns a XACML

Authorization Decision Assertion with the result of the access control
decision for the resource.

Operations

PDS accepts the access control decision query from the PEP.
PDS determines access based on policy and attributes obtained from the
Policy and Attribute Services, respectively.

Actors

Preconditions

PDS packages a response and sends an access control decision to the PEP.
PEP
PDS
PS
AS
Service Requester has an authenticated session
TLS session is established between the PDS and PEP

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

26

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Generate Access Control Decision
Nominal Flow

1. PEP sends a request of type <xacmlsamlp:XACMLAuthzDecisionQuery> to PDS.

2. PDS receives the message request. The PDS will first check the
message for validity (format and signature).
a. PDS verifies the message. This includes the following:

Verify request message timestamp (<wsu:Timestamp>)

Check uniqueness of request messageID (<wsa:MessageID>)
Verify Digital Signature
Perform relying party certificate checking functions
Check revocation status of PKI certificates
Checked for potential replay attacks

3. Once message is validated, PDS retrieves the applicable policy.

4. PDS performs Retrieve Access Control Policy function using PS.
(See section 4.6.1)
5. PS sends applicable policy to PDS.
6. PDS receives the applicable policy message and validates the
message using step 2.
7. Based on the policy from PS:
a. PDS performs Retrieve Attribute function using AS. (See section
4.5.1)
8. AS sends requested attributes to PDS.
9. PDS receives the requested attributes and validates the message
using step 2.
10. With the attributes retrieved from the AS:
a. PDS evaluates the retrieved policys conditions using the
attributes in order to determine an access control decision.
11. PDS assembles the permit or deny access decision in a <xacmlsamlp:XACMLAuthzDecisionStatement> message and sends the
decision to the PEP.
12. PEP accepts the access decision message.
Alternate Flow

Invalid Message
2b. Presents a message invalid error message.
Not Applicable Access Control Decision
7b. Not Applicable: The PDS could not find an applicable policy for the request,
access is denied, and an error message is sent to the requester.

Indeterminate Access Control Decision

10d. Indeterminate: The PDS could not find the information required to evaluate
the access control policy, access is denied, and an error message is sent to
the requester.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

27

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Policy
Enforcement
Point

Policy Decision Service: Generate Access Control Decisions

Start

1
PEP Sends
Request

Authorization
Query

2b
Message Invalid
Error Message

End

End

12
Accept
Message

End

3
Retrieve
Policy

Message
Valid?

Check PKI
Certificate

Success

Certificate
Revoked?

XACML Policy
Query

6
Receives
Policy

Policy
Service

Attribute
Services

Policy Decision Service

N
2
PDS Validates
Message

4
Request
Policies

Certificate
Revoked

Certificate
Revoked
Message

7
Attribute Query

9
Receives
Attributes

10
Determines
Access

8
Query
Attributes

SAML Attribute
Message

11
Decision
Message

5
XACML Policy
Message

Figure 9: Generate Access Control Decision Process Flow

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

28

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

4.4.2 Component Behavior: Request Access Control Policy

Table 12: Request Access Control Policy Behavior
Request Access Control Policy
Inputs
Outputs
Operations

XACMLPolicyStatement
XACMLPolicyQuery

PDS sends a policy query (<xacml-samlp:XACMLPolicyQuery>) to retrieve policies

from the Policy Service.

Policy Service accepts and processes the message.

Policy Service sends a response (<xacml-samlp:XACMLPolicyStatement>) to the
PDS containing the corresponding policies.

Actors

PDS
PS

Preconditions

TLS session exists between the PDS and the PS

Nominal Flow

1. PDS sends a XACML Policy Query of type <xacml-samlp:XACMLPolicyQuery> to

the PS to extract the appropriate policy from the policy store. The policy query
will request either a XACML Target (<xacml:Target>), PolicySet ID Reference
(<xacml:PolicySetIdReference>), or Policy ID Reference
(<xacml:PolicyIdReference>)
2. PS receives the message request. The PS will first check the message for
validity (format and signature).
a. PS verifies the message. This includes the following:

Verify request message timestamp (<wsu:Timestamp>)

Check uniqueness of request messageID (<wsa:MessageID>)
Verify Digital Signature
Perform relying party certificate checking functions
Check revocation status of PKI certificates
Checked for potential replay attacks

3. Once the message is validated:

a. The PS extracts the applicable policies based on the policy request.
4. After extracting the applicable policies:
a. Policy Service will return a policy response (<xacmlsamlp:XACMLPolicyStatement>) to the PDS.
Alternate Flow

Invalid Message
2b. Presents a message invalid error message.
Not applicable Message
3b. PS could not find an applicable policy for the request, and the PDS returns a
not applicable response to the PEP
Indeterminate Message
4b. PDS receives no response from the PS, is unable to render an access control
decision, and returns an indeterminate response to the PEP.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

29

Policy Service

Policy Decision
Service

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Figure 10: Request Access Control Policy Process Flow

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

30

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

4.4.3 Component Behavior: Request Attributes

Table 13: Request Attributes Behavior
Request Attributes
Inputs
Outputs
Operations
Actors and Components

AttributeStatement
AttributeQuery
PDS sends a query (<saml:AttributeQuery>) to the Attribute Service to
retrieve user attributes.

PDS
AS

Preconditions

TLS session exists between the PDS and the AS

Nominal Flow

1. PDS sends a SAML Attribute Query of type <samlp:AttributeQuery>

to the AS for extracting the appropriate attributes from the attribute
store.
2. AS receives the message request. The AS will first check the
message for validity (format and signature).
a. AS verifies the message. This includes the following:

Verify request message timestamp (<wsu:Timestamp>)

Check uniqueness of request messageID (<wsa:MessageID>)
Verify Digital Signature
Perform relying party certificate checking functions
Check revocation status of PKI certificates
Checked for potential replay attacks

3. Once the message is validated:

a. The APS extracts the applicable attributes based on the attribute
request and the AS will return an attribute response
(<samlp:AttributeStatement>).
4. PDS receives the attribute response message and the process ends.
Alternate Flow

Invalid Message
2b. Presents a message invalid error message.
Indeterminate Message
3b. The AS returns either no response or no attributes, and the PDS is
unable to render an access control decision returning an indeterminate
response to the PEP.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

31

Attribute Service

Policy Decision
Service

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Figure 11: Request Attributes Process Flow

4.5 AS Specifications
All AS interaction using the SOAP protocol must conform to the SAML v2.0 profile of
XACML. The AS retrieves user attributes from attribute stores. The AS performs the following
functions, as detailed in Table 14.
Table 14: Attribute Service Functions
Function
Retrieve Attributes

Description
The function sends a query to the Attribute Service
to retrieve user attributes. The Attribute Service
receives the message, retrieves the appropriate
attributes, and reassembles the message. Then,
the Attribute Service sends a SAML Attribute
Assertion back to the PDS.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

32

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

4.5.1 Component Behavior: Retrieve Attributes

Table 15: Retrieve Attributes Behavior
Retrieve Attributes
Inputs
Outputs
Operations

AttributeQuery
AttributeStatement

Attribute Service receives the message and retrieves the attributes from the
Attribute Store(s).

Attribute Service send a SAML Attribute Assertion

(<samlp:AttributeStatement>) back to the Service Requester.

Actors

PDS
AS

Preconditions

TLS session exists between the Service Requester and the AS

Nominal Flow

1. The PDS sends the user distinguished name (DN) and attribute list to
the AS in <samlp:AttributeQuery>.
2. The AS receives the attribute request.
3. AS receives the message request. The AS will first check the
message for validity (format and signature).
a. AS verifies the message. This includes the following:

Verify request message timestamp (<wsu:Timestamp>)

Check uniqueness of request messageID (<wsa:MessageID>)
Verify Digital Signature
Perform relying party certificate checking functions
Check revocation status of PKI certificates
Checked for potential replay attacks

4. Once the message is validated:

a. AS will query the Attribute Store to retrieve the user attributes.
5. Attributes are filtered depending on the permissions of the service
requester.
6. The AS generates the attribute response.
7. AS returns the attributes to the PDS using the
<samlp:AttributeStatement> message.
Alternate Flow

Invalid Message
3b. Presents a message invalid error message.
No User Exists
5b. If the user does not exist, the AS will return a StatusCode and
StatusMessage to the Service Requester stating that the user does not
exist in the Attribute Store.
No User Attributes
5c. If attributes do not exist, the AS will return a StatusCode and
StatusMessage to the Service Requester stating that attributes do not
exist for the user.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

33

Attribute Service

Service
Requester

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Figure 12: Retrieve Attributes Process Flow

4.6 PS Specifications
All PS interaction using the SOAP protocol must conform to the SAML v2.0 profile of XACML.
The policy service retrieves access control policy from policy stores. The PS performs the
following functions as detailed in Table 16.
Table 16: Policy Service Functions
Function
Retrieve Policy

Description
The function sends a query to the policy store to
retrieve access control policies based on the
security context of the transaction.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

34

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

4.6.1 Component Behavior: Retrieve Policy

Table 17: Retrieve Policy Behavior
Retrieve Policy
Inputs
Outputs
Operations

XACMLPolicyQuery
XACMLPolicyStatement

PS retrieves access control policies and forwards the request to the PDS.
PS sends an invalid message to the PDS for policies that do not exist in the
Policy Store.

Actors
Nominal Flow

Service Requester
PS
1. The service requester sends a <xacml-samlp:XACMLPolicyQuery>
message to PS to request access control policy.
2. The PS receives a request message.
3. The PS will first check the message for validity (format and
signature)
a. PS verifies the message. This includes the following:

Verify request message timestamp (<wsu:Timestamp>)

Check uniqueness of request messageID (<wsa:MessageID>)
Verify Digital Signature
Perform relying party certificate checking functions
Check revocation status of PKI certificates
Checked for potential replay attacks:

4. Once the message is validated, the PS will retrieve policy from the
policy store.
5. The PS will check to see if applicable policies currently exist in the
Policy Store.
a. If policies exist, the Policy Service will retrieve the policies.
6. Attributes are filtered depending on the permissions of the service
requester. The PS returns access control policies to the service
requester in a (<xacml-samlp:XACMLPolicyStatement>) message.
Alternate Flow

Invalid Message
3b. Presents a message invalid error message.
Unsuccessful Policy Retrieval
5b. If the access control policy does not exist, the PS will return an
appropriate StatusCode and StatusMessage stating that the Policy
did not exist in the Policy Store to the service requester.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

35

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Figure 13: Retrieve Policy Process Flow

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

36

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

ABAC Demonstrations and Pilots

The DISA and NSA sponsored ABAC demonstrations and pilots have provided an understanding
of ABAC technology, showing new potential for information sharing and providing developers
and application owners ABAC experience in limited deployments. The lessons learned from the
ABAC demonstrations and pilots have illustrated several operational, technical, and support
considerations for deploying ABAC that are discussed in the Engineering Blueprint. The
following sections provide a summary of the pilots and demonstrations19 This portion of the document
has been removed as it is DoD sensitive. Please refer to the [Link] by the DoD
community.
5.1 Joint Rapid Architecture Experiment (2006/2007) Demonstration20
The Joint Record Architecture Experiment (JRAE) was intended to assist Joint DoD force
transformation by providing a venue for testing and evaluating next generation architectures and
roadmaps by collaboratively engaging in experiments and prototyping exercises across Services,
Agencies, and Coalitions. Particular emphasis was put on delivering services to the tactical edge
where bandwidth is a consideration. This is especially important because many of the message
formats specified in the blueprint are quite verbose. JRAE experimented with EFX (Efficient
XML) and found transmission times reduced by as much as 99% over standard XML. For faster
access and less message traffic, the PEP was collocated with the PDS providing faster access
times. JRAE also experimented with different techniques for accessing attributes. Authorization
Pattern 1 (discussed in Appendix F) is the most common method discussed throughout the
blueprint of having the PDS retrieves attributes from a centralized service. JRAE engineers
tested Authorization Pattern 2 where the requester authenticates locally and attributes are
asserted with the request having the PEP include them with the authorization request to the PDS.
This saves the PDS from having to retrieve them as part of its processing. Metadata was used to
identify resources and failover scenarios were explored as well as a Cross Domain Solution
(CDS). The most recent JRAE demonstrations experimented with attribute hierarchies obtaining
attributes from multiple sources.
5.2 Empire Challenge (08/09) Demonstration21Thisportionofthedocumenthas
[Link].
Empire Challenge (EC) focused on the data owners ability to share information with the DoD,
IC, and Coalition Partners. Operational scenarios involved using PKI credentials to enable the
unanticipated user, i.e. a service requester without a local account, and ABAC to conduct cross-

19

Most of the supporting information in this section is taken from two documents; DoD Privilege Management Demonstration
Summary, Version 1.1, February 2010; and Lessons Learned from DoD and IC ABAC Pilots, Version 1.0, February 2010. Additional
material is taken from the individual demonstration and pilot reports themselves.

20

Joint Rapid Architecture Experimentation, JRAE 06 Final Report, Version 1.0, December 7,2006

21

Empire Challenge 2008 Final Report PDM-III Initiative

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

37

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

domain searches and retrieve information for which they are authorized. In addition to using the
PEP/PDS to control access to information, EC also used the PEP to bracket a CDS to check
information for releasability to the network domain on the destination side of the CDS. This
CDS solution was necessary to enforce releasability constraints because while the attributes
might authorize access to the information itself, the releasability constraints of the network to
which the information was being returned was unknown at the resource PEP. The PEP at the
CDS could prohibit information that was not marked for releasability to the destination network.
Unanticipated coalition users could gain access to information as long as certificates could be
validated and as long as attributes could be obtained for the service requester. EC developers
experienced challenges with certificates because of the different formats required to properly
configure signing and encryption options in various vendor products. They also found that
expressing digital policy with the necessary Boolean relationships to conform to data access
goals of the organization was difficult and recommended striving for policy simplicity. SOA
development presented challenges in debugging and documenting component interactions, which
required use of open source tools, which would not be permitted on classified networks.
5.3 Joint Expeditionary Forces Exercises 2008 Demonstration22
A major focus of the Joint Expeditionary Forces Exercises 2008 (JEFX08) experiments was to
assess ABAC for enabling dynamic authorization to services and data, secured federated content
discovery and retrieval of Distributed Common Ground/Surface Systems (DCGS) Family of
Systems (FoS) data. Authentication by anticipated users was username/password or certificate,
and for unanticipated users was certificate. Unlike the EC demonstration, JEFX08 used ten
attributes to determine access to data resulting in more complex policy. The result of the testing
was that access controls operated as expected with acceptable performance under light system
load. However, as load increased, accesses would not complete within the timeout period and
during a very small fraction of time an access might be granted that should have been denied.
These problems were traced to issues, which manifested themselves in periods of degraded
performance. This was listed as an area of concern for ensuring the architecture can provide
secure services under all conditions including component failure modes.
5.4 The Joint Forces Command Defense Knowledge Online/Joint Knowledge
Online Pilot23
The Joint Forces Command (JFCOM) Defense Knowledge Online/Joint Knowledge Online
(DKO/JKO) Pilot was undertaken to solve a problem involving access to public DKO pages.
Depending on their attributes, foreign nationals and military dependents should be able to view
the JKO home page but not public DKO pages and services. Foreign nationals should be able to
view country specific information and other DoD affiliate/NGO users should be allowed to view

22

PDM III DCGS JEFX08 Technical Assessment Final Report, 18 August 2008

23

DKO ABAC Pilot, Lessons Learned Final Report, December 5, 2008

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

38

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

both DKO and JKO pages and services. The JFCOM pilot successfully integrated two different
vendors COTS identity management products and gained insight into areas of improvement for
the Army Knowledge Online (AKO)/DKO portal in enabling ABAC for an existing enterprise
portal. The pilot also demonstrated the successful retrieval of attributes from an enterprise
source. However, one downside discovered was that the ABAC product could not deny access
to a resource to which the native application allowed access due to the presence of allencompassing group access permissions.
5.5 PvM Pilot Phase I24
PvM Pilot I was an effort at Pacific Command (PACOM) to use attribute-based access controls
to a document library containing US-only and releasable data. Normally, US-only and releasable
information had to be stored in separate libraries but the use of ABAC allowed the data to be
combined into a single site. A COTS product was used and policy was created using resource
metadata, attributes, as well as environment variables to render an access decision. The system
worked under light loads but performance was a problem as load increased. Another issue was
that users were able to see titles of documents to which they were not authorized for access
although they were not able to see the actual content of the documents.
5.6 PvM Pilot Phase II25
PvM Pilot II is currently being implemented between the Department of Homeland Security
(DHS) and Northern Command (NORTHCOM). The objective is to allow first responders
access to NORTHCOM resources to access needed information during emergency situations.
The pilot involves federating attributes using BAE between DHS and a portal at NORTHCOM to
transfer attributes for use in ABAC decisions to portal resources. This pilot highlights not only
the technology for ABAC but also the issues with attribute sharing between organizations as well
as certification and accreditation issues.
5.7 OpenAM Reference Implementation26
OpenAM is the open source distribution of the Sun/Oracle product OpenSSO that consists of
access control and federation capabilities. OpenAM was chosen for an RI because there are a
number of PEPs available to protect different application resources. The objective of the RI was
to integrate OpenAM with a Microsoft SharePoint 2010 server and the Apache Web server. A
local attribute store, Lightweight Directory Access Protocol (LDAP), was created which
simulated an enterprise source for attributes. Authentication was performed with certificates and
access was controlled to resources using attributes and OpenAM policy conditions specifying

24

Privilege Management Pilot (PMP) Project Closeout Whitepaper

25

Privilege Management Pilot Phase II, N-NC Operational Demonstrations Presentation, 29-30 March 2010

26

Identity and Access Management Development and Sustainment Support, OpenAM Operational Administration Guide, 11
February 2011
DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

39

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

using attributes. The Internet Information Server (IIS) PEP was used to control access to
SharePoint since there was no PEP specifically for SharePoint. The project did prove that
ABAC could be used to control access to the applications but because the PEP was installed on a
front-end Web server, resources were difficult to characterize because of complicated URLs and
query strings through which they are accessed. This resulted in being able to implement access
controls to the top-level sites but not through multiple levels of folder structure identified
through query strings.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

40

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Implementation Approach and Lessons Learned

Although the pilots, demonstrations, and RIs had different objectives, all focused on
implementing an ABAC solution for controlling access to resources. The environment for
ABAC is evolving as strategies for deploying policy, attribute, and metadata infrastructure in
support of ABAC are being developed. A recurring theme in the lessons learned from pilots is
that implementing ABAC successfully will require strategizing and tackling the tasks outlined in
the following subsections efficiently for consistent results.
6.1 Integration with Native Access Controls
As mentioned, ABAC provides the ability to provide access control to unanticipated users
without prior knowledge of the requester, which is necessary with other access control
mechanisms such as ACLs or RBAC. There are a large number of existing applications
currently using legacy native access controls, which limit the access control to anticipated users
only. ABAC fills the gap and provides access to authorized unanticipated users based on user
attributes. Implementing and integrating a new access control technology into an application
with legacy native access controls may present challenges especially where applications are
supplying information essential to mission success. The legacy controls in place protecting
information assets and accompanying procedures must continue to function with ABAC
implemented. Ideally, the legacy native access controls should continue to operate while a
transition can be made to ABAC.
6.2 Policy Creation
None of the pilots and demonstrations reported being able to obtain policy from any external
source; policy had to be written as part of the exercise. Most of the pilots and demonstrations in
their final report indicated that translating organizational requirements for information protection
into digital policy was difficult and required skills that few people possessed.
6.3 Standards
In order to deploy ABAC capabilities enterprise-wide, interoperability is a critical requirement.
Enterprise and local sources for digital policy, attributes, resource metadata and environment
variables require standard interfaces. COTS products may have targeted applicability, and the
needs of the DoD and IC may differ from their target. All of the standards specified in the NCES
interface definitions are based on industry standards but some require that certain features that
are options in the standard be implemented in the NCES profile. As a result, COTS products that
claim standards compliance may not actually be compliant with NCES interface specifications
because they either dont implement all of the options or include proprietary namespaces.
Additionally, the SAML Profile for XACML 2.0 is new and leaves some room open for
interpretation.
6.4 Performance and Scalability
Many of the pilots and demonstrations are set up in specific application areas with COTS
products that do not have a proven record in large-scale enterprise deployments. Several of the
pilots and demonstrations encountered problems as load was increased. Scalability across DoD
enterprise requires robust communications paths and while JRAE tested several configurations
DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

41

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

for bandwidth optimization and failover capabilities this aspect remains an area for additional
research.
6.5 Design Considerations
When implementing ABAC components, there are several options for deploying the specified
interfaces, protocols, and message formats. Leveraging industry reports and findings from
different pilots and demonstrations, there are many industry best practices, lessons learned,
architectural considerations, and operational constraints for deploying ABAC components. The
following design considerations highlight some enhancements that can be made to components
to increase functionality or deployment capability.
6.5.1 PEP Policy Enforcement Point
The definition of a resource varies between access control products. Some products use
free text parameters that an administrator can define while others rely on using a Uniform
Resource Identifier tied to the resource location.
Some products have a resource discovery function as part of the PEP. Resource
discovery tools extract site content from protected applications and load it into the Policy
Administration Point (PAP) for policy administration. The resource discovery function
provides policy administrators with a holistic view of all the resources protected by the
PEP to facilitate the definition of access control policies.
In addition to access control provided by the PEP, the protected resource may have
internal access control mechanisms and policies defined. The internal access control
mechanisms and policies are referred to as native access controls. The use of ABAC and
the implementation of a PEP should not preclude the use of native access controls for a
protected resource.
The granularity of access control provided by ABAC is limited to the specificity of the
PEP in identifying and differentiating resources.
PEPs typically apply access controls to protocols such as HTTP requests, remote
procedure calls (RPC), or structured query language (SQL) queries. When attempting to
deploy a PEP to protect proprietary, custom, or legacy applications, an understanding of
the underlying protocols and system architecture govern how access control policies can
be enforced.
When using a PEP to protect access to resources, the PEP should fail closed. If the PEP
should become inoperable or incapable of obtaining an access decision, then all access to
resource protected by the PEP would be denied. This is a security measure to prevent
data loss and unauthorized access in the event of a PEP failure or denial of service.
The PEP should offer the option to retry access to the PDS in the event of timeouts.
Timeout period and retry count should be configurable.
For high availability, the PEP should have the ability to connect to multiple PDS so that
if one PDS is unavailable, the PEP may be able to obtain access decisions from other
sources.
The most common integration pattern of the PEP is as either an external proxy or an incontainer interceptor as shown in Figure 14 below.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

42

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Figure 14: PEP Integration Patterns

As an external proxy, the PEP can enforce policies for numerous resources by serving as
a security firewall that only allows authorized requests to reach the requested resource.
As a module, the PEP can enforce policies as an in-container interceptor within the
resource SOAP platform, application server, or code library.
The PEP should cache access decisions for an authenticated session or for an optional
defined period of time to improve performance and throughput.

6.5.2 Policy Decision Service

The PDS should be loosely coupled with the PEP, attribute, and policy stores to allow the
flexibility to integrate with multiple PEPs, AS, and PS to retrieve access control
information.
To improve performance, the PEP and PDS should offer the option to be co-located to
improve performance and minimize latency in rendering an access decision.
The PDS should be able to implement a variety of policy combining algorithms, for
example, deny-overrides, or permit-overrides.
The PDS should be capable of retrieving attributes using the SAML X.509 Attribute
Sharing Protocol as well as LDAPS.
The PDS should be capable of accessing multiple attribute services at the enterprise,
extended and local levels.
For high availability, the PDS should have the ability to connect to a primary and backup
AS so that if one AS is unavailable, the PDS may be able to obtain attributes from other
sources.
To improve performance, the PDS should offer an option to cache attributes and policy
for a configurable period of time.
For testing, the PDS should provide a policy decision simulation tool for administrators
to run what if scenarios to verify the accuracy and validity of access control policies.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

43

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

6.5.3 Attribute Service

The AS should support SAML X.509 Attribute Sharing Protocol and LDAPs.
The AS itself should have the ability to restrict the releasability of attributes based on
access control policies and data privacy policies.
The AS should be able to interface with multiple attribute stores.
6.5.4 Policy Service
The PS should be able to interface with multiple policy stores for redundancy and high
availability.
The PS should allow for the deconfliction and prioritization of access control policies
Access control COTS typically implement the PS as part of the PDS. As a result, the PS
and the PDS are typically tightly coupled and not interoperable with an external or third
party PDS. The PS should offer the option to be decoupled from the PDS.
The policy store is typically a database or an LDAP directory and the PS is the interface
to retrieve policy. Policies are typically retrieved using SQL, Web services, or LDAP.
Often, access control products implement the PS as a proprietary interface that is not
exposed.
The policy service should have a user-friendly graphical policy administration user
interface. Additionally, it should ensure the usability criterion of the policy
administration point includes features such as import/export of XACML, bulk updates,
at-glance policy status, natural language policy expression, and policy validation checks.
The PS should be able to communicate with the PDS through XACML policy requests.
While some policies are stored in proprietary language, it is important that the policies
are requested and supplied in the standards-based XACML format to allow components
from different products to interoperate.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

44

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Enabling Performance and Resiliency

From the lessons learned obtained from the demonstrations and pilots, ABAC will potentially
add more overhead to a resource request than the traditional ACLs. In IBAC, user account data
and the ACLs are stored locally with the resource. With ABAC, policy and attributes must be
retrieved from various sources and the mandate to accommodate the unanticipated user,
requiring authentication to be performed against remote sources. Furthermore, policy and
attributes may need to be retrieved from multiple sources in order to determine access. Network
delays within an enclave and between enclaves may potentially add delays, which may result in
unacceptable overhead added to resource access due to ABAC. It is important that the
infrastructure supplying attributes and policy as well as the COTS products implementing the
access controls make use of replication and caching in order to improve performance and provide
high availability access decision capabilities.
Figure 15 below is based on Authorization Pattern 1 from the SSRA and is used as the default
pattern throughout the blueprint. This pattern shows the interaction between various AS, PS, the
PDS, and the PEP.

Figure 15: Authorization Pattern 1 Flow

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

45

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

As can be seen from the diagram, policy and attributes required to make an access decision are
obtained from sources external to the ABAC components and will add overhead to the resource
access time. The following subsections will explore how performance may be improved and
explore how caching and replication in the Attributes Services and in vendor ABAC products
will be required to deliver optimum performance.
7.1 Policy Enforcement Point
The PEP will be responsible for enforcing the decision of the PDS whether the service requester
has the privilege to access the resource or not. The PEP will forward the identity of the service
requester, the resource being requested, and the requested action on the resource to the PDS.
The PDS will return a decision to allow the access or deny access. The PEP should cache access
decisions so that repeated requests can be processed without going to the PDS.
7.2 Policy Decision Service
The PDS is responsible for making an access decision based on the information received from
the PEP consisting of the service requester identity, desired resource, and action on the resource.
The PDS must obtain policy-governing access to the desired resource as well as attributes,
resource metadata and environmental attributes and then evaluate attributes against policy. In
Authorization Pattern 1, the PDS receives the proof of authentication, requested action, and
desired resource information from the PEP in the form of an authorization decision request. The
PDS must retrieve policy rules from the Policy Service and gather the necessary attributes from
various Attribute Services to make the decision. Because the PDS may need to gather
information from multiple Attribute Services, it is essential that there be little delay in obtaining
them. The PDS may download or cache policy and attributes to speed access decision
determination.
After receiving the resource request, action, and service requester identity from the PEP, the PDS
will begin to gather information to use to make an access decision. The first element needed is
the policy governing access to the desired resource. The policy will be retrieved from the Policy
Service, which will get it from a Policy Store. Policy can be retrieved as needed or downloaded
and cached to minimize access time. Policy decisions should be cached to enhance performance
of requests made to the same resource by the same service requester. Attributes will be retrieved
from Attribute Services, which will retrieve them from an Authoritative Source. Because
attribute stores may often be remote, caching or replication should be by the Attribute Services
be used to minimize retrieval time. The Attribute Service may replicate attributes in a local store
after obtaining them from an Authoritative Source and the PDS should cache attributes, as they
may be needed for subsequent requests. Resource metadata may be needed if required by policy
to make an access decision. Resource metadata will be obtained from an Authoritative Source
and may be cached by the PDS for future use. If Environment Attributes are required by policy,
these must also be retrieved from an Authoritative Source. Environment Attributes may be
cached or downloaded to the PDS to enhance performance. Another performance enhancement
for the PDS is to request attributes, resource metadata and environment attributes in parallel
instead of waiting for each request to complete before requesting other information.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

46

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

7.3 Access Control Component Horizontal Scaling

Caching and replication of information will yield performance gains for throughput and
turnaround time. In planning for an enterprise capability, deploying multiple PDS/PEP
components and spreading the load across those components may result in throughput and
capacity increases. For example, if the PEPs transaction volume is at capacity, multiple PEPs
may be used to front end a resource and a load balancer can be used to direct service requests to
different PEPs to spread out the load. In this instance, multiple PEPs are deployed and service
requests are directed to different PEPs depending on the load. If the PEP is a bottleneck, this
solution may yield performance improvements. However, this scheme would work only if the
PEP is implemented as a proxy or there are multiple applications accessing the resources. This is
illustrated in Figure 16.

Figure 16: Multiple PEPs

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

47

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Another potential bottleneck is the PDS. The PDS will need to access multiple sources to obtain
policy, attributes, resource metadata, and spreading authorization requests to multiple PDSs may
improve performance. This is illustrated in Figure 17 below.

Figure 17: Multiple PDSs

In this scenario, the PEP will send authorization decision requests to one of several possible
PDSs. A simple round robin scheme could be used or one that favors the PDS with the quickest
response time. The PDS is more likely to be a bottleneck and methods to tune performance with
multiple components may improve performance.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

48

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

7.4 High Availability Design

As ABAC components are deployed throughout the DoD/IC infrastructure, it will become
essential that access decisions be rendered in a timely fashion. It will be unacceptable if access
to an important resource is denied due to the inability to make an access decision because policy
or attribute information needed could not be obtained. ABAC must be implemented with stable
and mature COTS software backed up by a robust infrastructure that delivers policy, attributes,
and resource metadata in a secure, reliable, and timely manner. Services delivering policy
information must be robust in themselves and have high availability built in to ensure that policy
information required to make authorization decisions is continually available. Service
disruptions could be catastrophic resulting in denied access to critical information at a time when
access is needed most. Figure 18 below shows high availability components that should exist
within the services infrastructure.

Figure 18: High Availability Configuration

A basic option for high availability is for the PEP to be able to request a policy decision from a
primary location, and if unavailable, from a backup location. The Attribute Service, Policy
Service, Resource Metadata Service, and Environment Attribute Service should all have multiple
instances in case one source of access control data becomes unavailable. For example, if the
DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

49

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

PDS accesses the Attribute Service over a defined port to a given server, then if that server or
port becomes unavailable, requests should be redirected to another working server and port to
ensure availability of attributes for making access decisions. Ideally, this could be accomplished
within the infrastructure by changing the DNS or service access point to seamlessly direct
requests to an available attribute service. However, the PDS should have the option of obtaining
attributes from additional sources if the primary source is unavailable. The same architecture
should apply to all services supplying policy or attributes to ensure that policy information is
continuously available for granting access to resources.
In addition to replication of services themselves, the stores containing policy information should
also be replicated. Hardware, software, or network failures could make a single store
unavailable so mirror copies should be available from which to retrieve policy information.
Note:

A byproduct of high availability configuration can be performance increase if the secondary

services can be used in parallel with the primary services.

Finally, PDS and PEP components should also be capable of being replicated. A PEP should be
able to obtain authorization decisions from a primary PDS as well as one or more secondary
sources and multiple PEPs should be able to be deployed to control access to a single resource
where feasible. These capabilities were discussed in Section 7.3.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

50

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Issues and Challenges

The deployment of dynamic access controls and the associated technologies in the GIG poses
several difficulties. These arise from the proliferation of multiple dynamic access control
initiatives, competing standards, and multiple IdAM lexicons and vocabularies. Table 18
discusses issues and challenges inherent to successfully implementing a dynamic access control
capability across the DoD enterprise.
Table 18: ABAC Issues and Challenges
Current Shortfall

Issue/Challenge

Cultural Challenges

For decades data owners and stewards have relied

on vetting an individuals need to know information
before making that information available by
creating a local account for that individual. Relying
on attributes and policy over which they do not
have control leads to a sense of unease.

Notional buy in to increase information sharing

One of the findings of the PvM Pilot Phase I was

there was minimal support for increased
information sharing. This report noted that highlevel support can be used to break down policy
barriers and that most government net-centric
information sharing is only done when driven by
senior leadership.

Use of Directory Services Markup Language

(DSML)

While industry is moving towards Service

Provisioning Markup Language (SPML), DSML is
still in use. Both DoD and IC Pilots have noted that
authorization vendors do not support DSML rather
support SAML, XACML, Liberty, and Web Services
protocols.

Difficulty translating written policies into usable

system access control rules

Policies play an essential role in the dynamic

access control. They authorize information sharing
and collaboration between DoD and its partners.
The issues lie in translating the written policies into
usable system access control rules. The
development of Enterprise Policy and Management
Capabilities are not given careful consideration.

Lack of ABAC Standards and Implementations

Standards and technology processes are required

to evaluate complex access control policies based
on a real-time assessment of the operational
necessity for access and the security risk
associated with granting access to information. A
practical approach would be to define widely
accepted standards and plan/conduct pilots to test
functionalities as technology becomes available.

Lack of Digital Policy Management tools

Without the tools and services necessary to

construct, manage, and disseminate digital
policies, ABAC capabilities across the enterprise
will remain stagnant. Discovery and availability of
enterprise policy decision services that can be
readily integrated with, or replace, existing access
control mechanisms by the community, is needed.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

51

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Current Shortfall

Issue/Challenge

Lack of full product functionality

Significant portions of ABAC COTS products lack

the full capability to explicitly deny service
requester access. Open communication and
collaboration with commercial vendors will foster
continued improvement of existing ABAC
technology, as well as support the way ahead for
future products

There are few or missing access control

mechanisms in use

Legacy resources do not currently possess the

ability to utilize a Policy Decision Service. Meeting
this challenge will require either a modification to
the existing access control mechanism at the
resource, or establishing an external proxy to act
as a PEP that can utilize a policy decision service.

Access Denial for Unanticipated Users

Unanticipated users do not exist in the identity

store of a program, and their credentials are not
widely accepted. A strategy to implement and
define an applicable set of policies that provide
unanticipated users access based on their
credentials must be established.

Lack of an Attribute Authority

There is a need to ensure an authoritative source

will exist for different attributes across the
enterprise. Corrective measures will include
providing a unique identifier, citizenship, clearance,
and formal access approvals for all members of the
community.

Supporting Extended Operations

ABAC capabilities must support operations across

the tactical edge, enabling operations among
service requesters on the wideband networks with
those operating on low bandwidth, disconnected,
or austere environments (e.g., reconnaissance,
Special Operations).

Lack of Credential Management

ABAC functionality requires the ability to interpret

and authenticate the identity credentials of native
service requesters across the DoD enterprise, as
well as any credentials that may be used by
external service requesters that interact with DoD
networks and systems. Addressing this issue will
require ABAC technology to determine the
authenticity of a wide range of credential types and
sources, and determine the level of confidence in
the asserted identity from the authentication of
these credentials.

Access Control for Applications

Controlling access to applications and services will

require the capability to provide access to internet
sockets providing a service such as collaboration
and Web services. It also includes access controls
for Web portals, for local, organizational, and
department-wide uses.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

52

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Current Shortfall

Issue/Challenge

Resource Metadata Standards

Standards do not exist for resource metadata to

facilitate information sharing. To address this
concern, common resource metadata
requirements, built upon current DoD programs
(e.g., DDMS and Automated Metadata Population
Service (AMPS)), should be defined.

Adapting to Mission Demands

Fundamental structures including the use of

dynamic authorization policies, mission
environmental factors, and attributes have to be
structured and accessible to allow ABAC
capabilities to continue to function effectively at the
tempo of mission operations and remain flexible
and agile.

Lack of Identity Federation

A shared approach to conveying identity

information outside of the DoD and IC is required.
The foundation of this approach is the creation of
an identity federation, which will perform as a
collaborative unit of identity managers. Each
manager identifies and agrees to adhere to
collectively established standards and policies for
registering, maintaining, and sharing identities. In
order for this concept to come to fruition, standard
identity attributes shared across the federation
must be established.

Structured XACML Communications between

ABAC components

In the current state of access control, XACML has

a lack of authentication and confidentiality
requirements for communications between the PEP
and the PDS, and any other components within the
ABAC architecture. Therefore, a strategy should
be put in place to use SSL or similar mechanism to
provide confidentiality for the communication
between ABAC actors.

Lack of Metadata Governance Policies

Unless metadata is properly managed and

documented, there will be several competing
interpretations and inferences of metadata based
on individual perspectives; leading to data
confusion within and lack of interoperability within
the Enterprise.

Based on the issues and challenges highlighted above, it is evident that in order to establish a
widely known and accepted ABAC solution, a baseline understanding of the dynamic access
control reference architecture, and associated technologies must be established first. In addition,
the DoD and its coalition partners should work towards standardizing the dynamic access control
reference architecture, while being committed to implementing standard ABAC capabilities
within the larger enterprise. One way to fill the technology gap is to assess and evaluate the
ABAC requirements, technologies, and products in a laboratory setting. This activity will
minimize deviant solutions, foster standardization of ABAC baseline criteria, and provide insight
into the status of relevant technologies and products for use within the DoD enterprise.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

53

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Appendix A: Acronyms and Abbreviations

Acronym

Description

ACPT

Access Control Policy Testing

AFG

Architecture Framework for GIG

AAS

Authoritative Attribute Source

ABAC

Attribute-Based Access Control

ACL

Access Control List

AMPS

Automated Metadata Population Service

AS

Attribute Service

AA

Attribute Authority

BAE

Backend Attribute Exchange

CTIP

Capability Thread Implementation Plans

C&A

Certification and Accreditation

CA

Certificate Authority

CAC

Common Access Card

COI

Community of Interest

COTS

Commercial Off-the-Shelf

CPKI

Coalition Public Key Infrastructure

CRL

Certificate Revocation List

CVS

Certificate Validation Service

CIIA

Cyber, Identity and Information Assurance

DCGS

Distributed Common Ground/Surface Systems

DDMS

Defense Discovery Metadata Specification

DHS

Department of Homeland Security

DISA

Defense Information Systems Agency

DMDC

Defense Manpower Data Center

DMZ

Demilitarized Zone

DoD

Department of Defense

DOTMLPF

Doctrine, Organization, Training, Material,

Leadership, Personnel, and Facilities

DPM

Digital Policy Management

DSML

Directory Services Markup Language

ebXML

Electronic Business using eXtensible Markup

Language

EDI_PI

Electronic Data Interchange Personal Identifier

EIAS

Enterprise Identity Attribute Service

ESM

Enterprise Security Management

ESSF

Enterprise System Security Framework

FASC-N

Federal-Agency-Smart-Credential-Number

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

54

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Acronym

Description

FICAM

Federal Identity, Credential, and Access

Management

FoS

Family of Systems

GCDS

GIG Content Delivery Service

GCSS

Global Combatant Support System

GeoXACML

Geospatial eXtensible Access Control Markup

Language

GFM DI

Global Force Management Data Initiative

GIG

Global Information Grid

GOTS

Government off the shelf

HSPD-12

Homeland Security Presidential Directive 12

HTTP

Hypertext Transfer Protocol

HTTPS

Hypertext Transfer Protocol Secure

IA

Information Assurance

IC

Intelligence Community

ICAM

Identity, Credential, and Access Management

IdAM

Identity and Access Management

IIS

Internet Information Services

ISSO

Information System Security Officer

JCA

Joint Capability Area

JEDS

Joint Enterprise Directory Service

JFM

Joint Force Management

JPES

Joint Planning and Execution Services

JRAE

Joint Rapid Architecture Experiment

JTF

Joint Task Force

JWICS

Joint Worldwide Intelligence Communications

System

LDAP

Lightweight Directory Access Protocol

MDR

Metadata Registry

MNIS

Multi-National Information Sharing

NCES

Net-Centric Enterprise Services

NCOE

Net-Centric Operational Environment

NPE

Non-Person Entity

NIPRNet

Non-classified Internet Protocol Router Network

NIST

National Institute of Standards and Technology

NSA

National Security Agency

NSLDSS

National Senior Leaders Decision Support Systems

OASIS

Organization for the Advancement of Structured

Information Standards

OCSP

Online Certificate Status Protocol

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

55

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Acronym

Description

ORD

Operational Requirements Document

OUID

Organizational Unique Identifier

PDM

Program Decision Memorandum

PDN

Protected Data and Networks

PDS

Policy Decision Service

PEO-MA

Program Executive Office for Mission Assurance

PEP

Policy Enforcement Point

PIP

Policy Information Point

PIV

Personal Identity Verification

PKI

Public Key Infrastructure

POC

Proof of Concepts

POR

Program of Record

PRD

Policy Requirements Document

PS

Policy Service

PvM

Privilege Management

QDR

Quadrennial Defense Review

RA

Registration Authority

RAE

Respond Attack Events

RBAC

Role-Based Access Control

RI

Reference Implementation

RMS

Resource Metadata Service

RP

Relying Party

RPC

Remote Procedure Calls

RS

Resource Metadata Service

SA

Situational Awareness

SAML

Security Assertion Markup Language

SIE

Secure Information Exchange

SIPRNet

Secret Internet Protocol Router Network

SOA

Service Oriented Architecture

SOAP

Simple Object Access Protocol

SPML

Service Provisioning Markup Language

SRD

System Requirements Document

SSL

Secure Sockets Layer

STEP

Systems Technology Evolution Plan

SQL

Structured Query Language

TLS

Transport Layer Security

TS

Top Secret

TTA

Time to Authenticate

TTD

Time to Decide

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

56

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Acronym

Description

TTEv

Time to Evaluate

TTP

Transit Time to PEP

TTR

Transit Time to Resource

TTRA

Time to Retrieve Attributes

TTRE

Time to Retrieve Environment

TTRM

Time to Retrieve Metadata

TTRP

Time to Retrieve Policy

UI

User Interface

UK

United Kingdom

USA

United States of America

USAF

United States Air Force

USMC

United States Marine Corps

USN

United States Navy

XACL

XML Access Control Language

XACML

eXtensible Access Control Markup Language

XASP

X.509 Attribute Sharing Profile

XML

Extensible Markup Language

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

57

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Appendix B: Data Dictionary

Term

Definition

Reference

Action

An operation on a resource

OASIS XACML 2.0 Core Spec

Obligation

An operation specified in a policy

or policy set that should be
performed by the PEP in
conjunction with the enforcement
of an authorization decision

OASIS XACML 2.0 Core Spec

Resource

Data, service or system

component

OASIS XACML 2.0 Core Spec

Response

The element encapsulates the

authorization decision produced
by the PDS.

OASIS XACML 2.0 Core Spec

Rule

A rule is the most elementary

unit of policy. It may exist in
isolation only within one of the
major actors of the XACML
domain. In order to exchange
rules between major actors, they
must be encapsulated in a policy.

OASIS XACML 2.0 Core Spec

Subject

An actor whose attributes may

be referenced.

OASIS XACML 2.0 Core Spec

Target

The set of decision requests,

identified by definitions for
resource, subject and action, that
a rule, policy or policy set is
intended to evaluate

OASIS XACML 2.0 Core Spec

Access Control

Controlling access in accordance

with a policy

OASIS XACML 2.0 Core Spec

Assertion Markup Language

(SAML)

The SAML protocol schema

defines an attribute query used
for requesting instances of
attribute assertions, and a
response that contains the
requested instances.

NCES SAML 2.0 Profile

Attribute

A quality or characteristic
inherent in or ascribed to
someone or something.

American Heritage Dictionary,

2000

Attribute Assertion

A SAML assertion that contains

security context information
related to the attributes for an
entity.

NCES SAML 2.0 Profile

Attribute Management

Permits resource providers to

discover what attributes are
available, what values are
allowed for each attribute, where
attributes can be obtained, and
the extent to which attributes are
authoritative and reliable.

ESM Annex Document

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

58

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Term

Definition

Reference

Attribute Service

Provides attribute values that

describe subjects (either human
users or systems) for the
purpose of enabling all DoD and
IC organizations and partners to
make access control decisions
related to their data.

ICDOD_SS_AS_Spec_v1

Attribute Store

An automated system that

stores, protects, and processes
requests for values of user
attributes. Also, an organization
operating or owning such a
system.

Intellipedia

Attribute-Based Access Control

(ABAC)

A policy model that allows for

access control policy
applicability; and the associated
rules that govern access, to be
formulated based on an
extensible notion of subject,
resource, and other attributes.

ICDOD_SOA_SecurityRA_v1

Certificate Revocation List (CRL)

A time stamped list identifying

revoked certificates which is
signed by a CA or CRL issuer
and made freely available in a
public repository. Each revoked
certificate is identified in a CRL
by its serial number.

Intellipedia

Certificate Validation Service

(CVS)

Checks the revocation status of

PKI certificates

Commercial Off-the-Shelf
(COTS)

An acronym which stands for

"commercial off-the-shelf". It
refers to software which has
been produced by a commercial
entity.

Intellipedia

Common Access Card (CAC)

A United States DoD smartcard

issued as standard identification
for active duty military personnel,
reserve personnel, civilian
employees, non-DoD other
government employees and
State Employees of the National
Guard and eligible contractor
personnel.

Intellipedia

Decision

The result of evaluating a rule,

policy or policy set

OASIS XACML 2.0 Core Spec

Discovery Metadata Function

Allows data to be discovered by

creating, associating, and
publishing discovery metadata
and by allowing that data to
reside in shared spaces readily
available to authorized users

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

59

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Term

Definition

Reference

IA Metadata

Are specific data tags that clearly

define how data or resources are
to be accessed, stored, or
transmitted

Intellipedia

Identity Management

Defines standards, rules, and

procedures for the protection of
personal identity information

ESM Annex Document

Online Certificate Status Protocol

(OCSP)

The protocol used by Robust

Certificate Validation Services
(RCVS) to provide the revocation
status of X.509 certificates.

Intellipedia

Policy Combining Algorithm

The policy-combining algorithm

specifies the procedure by which
the results of evaluating the
component policies are
combined when evaluating the
PolicySet, i.e. the Decision value
placed in the response context
by the PDS is the result of
evaluating the PolicySet.

OASIS XACML 2.0 Core Spec

Policy Decision Service (PDS)

An entity that evaluates an

access request against one or
more policies to produce an
access decision.

OASIS RBAC Profile of XACML

v2.0

Policy Enforcement Point (PEP)

Enforces a policy decision and

the policy decision point.

NCES XACML Profile

Policy Management

Responsible for the lifecycle

management of policies. It is the
process that delivers tested,
verified, deconflicted, and
certified XACML policies to the
PDS, which uses them to make
the access control decisions that
are enforced by the PEP.

ESM Annex Document

Policy Service

Allows Policy Decision Service to

retrieve policies for their
resources from a policy
repository

ICDOD Security RA

Policy Set

Comprised of one or more

policies that are applicable to the
same resource.

NCES_XACML_RBAC_Profile

Policy Store

Repository of access control

policies

ICDOD Security RA

Public Key Infrastructure (PKI)

A service of products, which

provide and manage X.509
certificates for public key
cryptography.

Intellipedia

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

60

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Term

Definition

Reference

Role Based Access Control

(RBAC)

Role based access control allows

policies to be specified in terms
of subject roles rather than
strictly interims of individual
subject identities

OASIS RBAC Profile of XACML

v2.0

Rule Combining Algorithm

The rule-combining algorithm

specifies the procedure by which
the results of evaluating the
component rules are combined
when evaluating the policy, i.e.
the Decision value placed in the
response context by the PDS is
the value of the policy.

OASIS XACML 2.0 Core Spec

Service Consumer

The requesting application or

another service provider.

ICDOD Security RA

Service Provider

A mission entity that performs a

mission function for another
mission entity.
Note: A service provider may be a

NCES SAML 2.0 Profile

consumer of other service

providers.

Web Services

Web services extend the World

Wide Web infrastructure to
provide the means for software
to connect to other software
applications.

MSDN,
<[Link]

WS-Security

An OASIS standard, provides the

ability to secure SOAP Web
services by supplying
mechanisms for message
integrity and confidentiality that
are independent of the
underlying transport, and for
associating security tokens with
a message context

ICDOD_SOA_SecurityRA_v1

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

61

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Appendix C: References
The following is a list of documents that were used during the development of the Engineering
Blueprint. They provide additional insights, guidance, and requirements for the dynamic access
control reference architecture. Some documents may be relevant for a specific section only
where as other documents may be relevant in many places.
Note:

URLs are valid as of the publication date of this document.

Reference Table

A Survey of Access Control Methods, NIST/NSA, 2009

ACPT: A Tool for Modeling and Verifying Access Control Policies, JeeHyun Hwang, Tao Xie, Vincent Hu,
Mine Altunay, 11 November 2010
Alignment Framework for GIG IA Architecture
Intelink: [Link] August 2009
Department of Defense Enterprise Architecture Transition Strategy, OSD/NII, February 2008
Department of Defense Information Sharing Strategy, OSD/NII, May 2007
Deputy Assistant Secretary of Defense for Cyber, Identity, and Information Sharing (CIIA), August 2009
DKO ABAC Pilot: Lessons Learned-Final Report, DISA, 5 December 2008
DoD & IC Authorization and Attribute Services Committee (AASC): Federated ABAC Symposium
Summary Report, 15 September 2010
DoD and IC Service-Oriented Architecture Security Attribute Service Specification v1.0, DISA/ODNI, 15
April 2008
DoD and IC Service-Oriented Architecture Security Policy Decision Service Specification v1.0,
DISA/ODNI, 15 April 2008
DoD and IC Service-Oriented Architecture Security Policy Enforcement Point Specification v1.0,
DISA/ODNI, 15 April 2008
DoD and IC Service-Oriented Architecture Security Policy Service Specification v1.0, DISA/ODNI, 15
April 2008
DoD and IC Service-Oriented Architecture Security Reference Architecture v1.0, DISA/ODNI, 15 April
2008
DoD Enterprise Service Security Framework Model, DoD CIO, 07 August 2009
DoD ICAM Harmonization Assessment Version (Draft) 0.61, 25 August 2010
DoD Information Management and Information Technology Strategic Plan, DoD CIO, 2008
DoD Privilege Management Roadmap, OSD/NII, 6 January 2010
Draft Strategic Plan for DoD Privilege Management, 14 December 2008
Draft Whitepaper: DoD Enterprise Attribute Service Capability, 3 June 2009
Empire Challenge 2009 Final Report: Enterprise Services Initiative, 20 November 2009
Enterprise Security Management: A Context Overview, 20 March 2009
Enterprise Security Management: Annex for Privilege Management, NSA, 25 September 2009
Enterprise User Data Management Plan, DMDC/DISA, 2 November 2009
Evaluation of NISTs Access Control Policy Tool version 1, Technica Corporation, 11 January 2011
Federal Identity, Credential and Access Management (FICAM) Roadmap and Implementation Guidance,
DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

62

IdAM Development and Sustainment Support

Engineering Blueprint v2.0
Reference Table
GSA, 10 November 2009
Global Force Management Data Initiative (GFM DI) Concept of Operations, Joint Chiefs of Staff, 16 April
2007
GSA HSPD-12 Paper: Backend Attribute Exchange Architecture and Interface Specification Version
1.0.0,15 May 2008
Guidance for Implementing Net-Centric Data Sharing: DoD 8320.2-G, 12 April 2006
HSPD12 Backend Attribute Exchange Architecture and Interface Specification Version 1.0.0 Final, 15
May 2008.
IA Metadata Community of Practice
Intelink: [Link]
Identities, Roles, and Attributes? Generic Use Case brief, DISA, 13 August 2009
Initial Capabilities Document for the Global Information Grid Information Assurance, NSA, 06 March 2006
Instantiating Privilege Management: An evolutionary view of enterprise authorization brief, DISA/NSA, 29
April 2009
Joint Capabilities Document (JCD) for Net-Centric Operational Environment (NCOE), December, 2006
JRAE 07 Final Test Report Version 1.0, Prepared for: Space and Naval Warfare Systems Command
Operational Experiments Office, 10 December 2007
Lessons Learned from DoD and IC ABAC Pilots, DISA, February 2010
National Security Agency Information Assurance Directorate: STEP Practitioners Guide, September
2009
NCES Profile of Web Service Security: Simple Object Access Protocol Message Security, DISA/NSA, 02
May 2008
NCES Profile of XACML for RBAC, DISA/NSA, 08 April 2008
NCES SAML Attribute Profile, DISA/NSA, 30 June 2008
Net-Centric Security Pilot Phase I Overview (LCDR Neboshynsky / Capt Hannan):Net-Centric Capability
Portfolio Management, June 2009
Quadrennial Defense Review Report, OSD/NII, February 2010
Research Documentation and Results Document, Available from the DISA IA43 team
System Technology Evolution Plan (STEP), December 2009
The Office of the Associate Director of National Intelligence: Identity and Access Management,
September 2009
Unified Authorization and Attribute Service Authoritative Attribute Sources and Attribute Services
Guidelines, DoD/IC, 30 September 2008
Unified Authorization and Attribute Services Authorization Attribute Service Interface Specification,
DoD/IC, 30 August 2009

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

63

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Appendix D: Security Frameworks Overview

The intention of this section is to provide an overview of the various IdAM frameworks. The
following sections provide an overview of the DISA IdAM framework, Federal Identity,
Credentialing, and Access Management (FICAM) framework, and NSA ESM framework.
Additionally, a mapping of the frameworks has been conducted to illustrate commonalities and
differences between each framework.
DISA IdAM Framework
To provide dynamic access control and provide anticipated and unanticipated users access to
DoD resources, the DISA IA43 team has established an IdAM framework that aligns well with
other security frameworks. As depicted below in Figure 19, the high-level business process
elements that are needed to establish a Security Infrastructure are consistent between the DISA
IdAM framework and other security initiatives. These business processes are:

Identity Management Defines standards, rules, and procedures for the protection of
personal identity information. Identity Management establishes a trustworthy process for
assigning user attributes to a digital identity.
Credential Management- Binds an identity to a token possessed by an authorized user.
Credential Management supports the lifecycle of credentials. Some examples of
credentials include digital certificates, PKIs, smart cards, and tokens.
Access Management- Ensures that proper identity verification exists when individuals
access sensitive information in computer systems and physical access to buildings. It
also manages the ways in which access to resources is granted to users. This business
process consists of three service categories: Privilege Management, Metadata
Management, and Access Control.
Net-centric- Captures functional and infrastructure requirements that are global and
encompass multiple DISA services.

The six blocks highlighted in color represent the six DISA service categories that incorporate all
FICAM and ESM service categories. The Security Framework Mapping details the color code
mapping of FICAM and ESM services to DISA services; however, all of the graphics that follow
will use this color scheme to show which service categories, or parts thereof, map to the six
DISA service categories. The DISA service color scheme is as follows:
Identity Management Blue

Credential Management
Red

Access Control Green

Privilege Management
Purple

Metadata Management
Aqua

Net-centric Orange

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

64

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Figure 19: DISA IdAM Framework

The DISA IA43 team extended the Access Management process further to support an ABAC
solution that will enable dynamic access control for anticipated and unanticipated users. Access
Management consists of best practices, policies, procedures, and technical access control
mechanisms that are needed to appropriately manage access to resources in an organization. The
DISA IA43 team defined the following services to grant the appropriate access to authorized
members of a COI and denies access to unauthorized requests. These services form a functional
framework that classifies different business processes with respect to how they support business
and/or performance objectives. Figure 19 above provides the different services and associated
functional areas.

Privilege Management consists of Policy Management and Attribute Management

functional areas.
Policy Management - this process is responsible for the lifecycle management of
policies and provides the set of standards required to define, generate, structure, and store
access control policies that can be retrieved by the PDS.
Attribute Management - Permits resource providers to discover what attributes are
available, what values are allowed for each attribute, where attributes can be obtained,
and the extent to which attributes are authoritative and reliable.
Metadata Management consists of Resource IA Metadata and Resource Context
Metadata functional areas.
Resource IA Metadata - provides security properties, security requirements, and applied
protections for resource metadata.
Resource Context Metadata - provides security properties, security requirements, and
applied protections for resource context metadata.
Access Control consists of Access Control Decision and Enforcement functional areas.
Access Control Decision- decision service that permits or denies a particular request for
access to a resource or data. The decision is made after pulling information about the
user from attribute services, resource metadata, and/or environmental services and
comparing those values with policies retrieved from the policy store.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

65

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Access Control Enforcement- act of permitting or denying access to a particular

resource by the policy enforcement point based on the response received from the access
control decision provided by the policy decision service.
The Engineering Blueprint is based on the DISA IdAM Framework, which incorporates
the Business Processes of Identity Management, Credential Management, and Access
Management previously identified.

Federal Identity, Credentialing, and Access Management

The FICAM Roadmap and Implementation Guidance was developed in support of the federal
government mission to provide a common segment architecture and implementation guidance for
use by federal agencies as they continue to invest in IdAM programs27. The Presidents FY2010
budget cited the development of Federal segment architecture, stating that, one of the major
outcomes of this effort is to allow agencies to create and maintain information systems that
deliver more convenience, appropriate security, and privacy protection, with less effort and at a
lower cost. The purpose of the FICAM guide is to provide agencies with architecture and
implementation direction that addresses existing IdAM concerns and issues they face daily. It
also seeks to support the enablement of systems, policies, and processes to facilitate business
between the Government and its business partners and constituents. The document presents the
Federal Government with a common framework and implementation guidance needed to plan
and execute IdAM programs.
FICAM, like the DISA IdAM Framework, states that identity, credential, and access
management (ICAM) are the high- level business processes that create an enterprise security
solution. In support of the business processes, FICAM provides service types and components in
the FICAM services framework. This model classifies the service components with respect to
how they support business and performance objectives. DoD Enterprise System Security
Framework (ESSF) adopted and customized the FICAM framework to establish a security
framework for DoD components. The differences in FICAM and ESSF are highlighted in red
and additional services are provided in green boxes in Figure 20 below.

27

Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance, GSA, 10 November
2009

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

66

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Figure 20: FICAM Services Framework

NSA Enterprise Security Management

Developed by the NSA, the ESM Context Review Documents comprise the systems, processes,
and personnel required to order, create, disseminate, modify, suspend, and terminate
management controls to provision and operate IA services, processes, and devices across an
enterprise. IdAM is subset of the IA capabilities outlined in the ESM framework. ESM consists
of a number of services that provide dynamic management and control of IA services, processes,
and devices to optimize the enterprise for mission operations. There are nine ESM services that
are described in Figure 21 below, which include Identity Management, Credential Management,
Attribute Management, Policy Management, Privilege Management, Authentication,
Configuration Management, Audit Management, and Cryptographic Key Management. The
ESM service components together provide an efficient management process of IA services and
enable a dynamic information sharing process.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

67

IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Figure 21: ESM Services

Comparison of Security Frameworks

Even though several commonalities exist between the different security frameworks that are
described above, the terminology is being used differently. For example, the Privilege
Management service category consists of different functional areas within each security
framework: The DISA PvM service category consists of ESMs Policy Management and
Subject Attribute Management service categories, and portions of FICAMs Authorization &
Access and Privilege Management service categories.
Figure 22, below, depicts Access Management mappings for DISA IdAM to the ESM and the
FICAM security frameworks. Each FICAM and ESM service category is mapped to the DISA
service categories according to the color scheme outlined in the DISA IdAM Framework section
of Appendix D .

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

68

IdAM Development and Sustainment Support

Engineering Blueprint V2.0

Figure 22: Security Framework Mapping

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

69

IdAM Development and Sustainment Support

Engineering Blueprint V2.0

Appendix E: Supporting Documentation

This section describes how DISA has developed the Engineering Blueprint to establish a
dynamic access control reference architecture for DoD, IC, Federal Civilian, and coalition
partners.
Policy Analysis Requirements
A comprehensive analysis of domestic, international, and coalition access control related
documents was conducted to gather pertinent access control requirements. These policy
documents were reviewed to identify regulatory, policy, technical and organizational policies
that may have an impact on a program in order to develop and promulgate access and
authorization control policies to support the Engineering Blueprint. The requirements from the
Policy Analysis were categorized based on the FICAM Roadmap Document. The Policy
Requirements Document (PRD) assisted in developing the Operational Requirements Document
(ORD) as well as the System Requirements Document (SRD).
Government and Market Surveys
In order to gather operational requirements and needs of DoD communities, key PORs were
investigated that support DOTMLPF to identify how information is currently accessed, stored,
and where it is physically and logically located on networks. DISA identified eleven PORs
initially based on PDM III CES, which needed investigation. The survey documentation also
helped in identifying certain pain points that the applications are facing today in addition to
access control mechanisms.
Operational Use Cases
The information from the Market Surveys was used to develop operational use cases that
captured core information about the as-is authentication and authorization mechanisms,
information flow models, and the current technologies being used by key PORs. The use cases
illustrated the as-is process flow and identified challenges and pain points that PORs are
experiencing relating to access control. The Operational Use Case Document was used to
conduct gap analysis as well as gathering operational requirements.
Gap Analysis Document
Once the Operational Use Cases were developed, the DISA IA43 team identified gaps that exist
between the as-is state of the access control mechanisms to the target state. The target state is
defined as providing dynamic access control to anticipated and unanticipated users. The gaps
were divided into the ten functional areas of the FICAM Roadmap Document that addresses how
to achieve a comprehensive Identity and Access Management framework.
Operational Requirements Document
The Operational Requirements Document (ORD) established the functional/operational
requirements necessary to implement system-wide dynamic access control. These requirements
were derived from the following documents as well as other available sources outside of this
initiative:

Policy Requirements Document

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

70

IdAM Development and Sustainment Support

Engineering Blueprint V2.0

Operational Use Cases Document

Gap Analysis Document

These requirements were used to generate system requirements in order to develop the
Engineering Blueprint. It is important to note that the ORD was also used in conjunction with
both the Policy and SRD documents when developing the Engineering Blueprint.
Research Documentation and Results
The Research Documentation and Results Document provided comprehensive research on the
standards, specifications, and protocols required to deploy and integrate improved access control
capabilities. The Research Documentation & Results deliverable facilitated development of
system requirements and the findings were used for the Engineering Blueprint. The document
included the following content:

Attribute-Based Access Control Concepts and Capabilities

Architectural Components and Patterns
Performance Modeling & Simulation
Authentication
Attributes
Access Control Policy

System Requirements Document

The system requirements document consolidated and documented Policy/Functional/Operational
requirements necessary to execute an ABAC solution. The requirements were derived from the
following documents:

Policy Requirements Document

Operational Requirements Document
Research Documentation and Results

Risk Analysis Report

The risk analysis document followed the risk management methodology defined in NIST SP
800-30 to document known risks to the ABAC concept. Of the nine total steps defined, the
DISA IA43 team focused on the first six steps:

System Characterization
Threat Identification
Vulnerability Identification
Controls Analysis
Likelihood Determination
Impact Analysis

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

71

IdAM Development and Sustainment Support

Engineering Blueprint V2.0

Engineering Blueprint- v1
The Engineering Blueprint is an architecture document defining the detailed design of the
standards, protocols, specifications, interface definitions, infrastructure, and performance
allocations to develop and deploy ABAC for the DoD enterprise. The Engineering Blueprint
builds upon the following documents: Policy Analysis, Gap Analysis, Operational Use Cases,
Research & Results Deliverable, Operational Requirements Definition, System Requirements
Document, and Risk Analysis and was used to develop reference implementations and will be
used as evaluation criteria to test vendor products.
Proof of Concept Design Document
The DISA IA43 team delivered a Proof of Concept (POC) document for the design and
development of a viable solution to meet the specific business needs of the DISA PORs using the
dynamic access control reference architecture. The POC Design Document defines real world
operational scenario(s) for evaluating COTS access control products against the dynamic access
control reference architecture. The POC design document also contains details around the
environment setup within DISA IA43 PvM North lab, as well as technical specifications and
interfaces to meet some basic operational scenarios.
Test Plan
The DISA IA43 teams test plan established the testing approach and execution, as well as
identified the test scenarios needed to validate the access control use cases outlined in the POC
Design Document. This deliverable also outlined the specific test cases for each use case in
order to validate selected vendor products against the use cases, and established ABAC
requirements. The identified testing criteria was then used to yield a threshold of two Reference
Implementations.
Reference Implementation
The DISA IA43 team developed RIs for the purpose of identifying whether or not the access
control components chosen, are interoperable with the components of other reference
implementations. Specifically, the RI demonstrated whether a PDS chosen for one
implementation could provide an access control decision to a PEP used in another
implementation. In addition, the RI identified that an authorization policy used for one
implementation could also be used in another implementation with the same results. Ultimately,
each RI will exhibit that the access control components can interoperate with existing DoD and
external providers to securely request and receive information required to evaluate authorization
policies such as a certificate validation service, attribute service, and policy repository.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

72

IdAM Development and Sustainment Support

Engineering Blueprint V2.0

Appendix F: Architectural Patterns and Performance Modeling

The DoD and IC Service-Oriented Architecture, Security Reference Architecture (SSRA)
document provides a joint DoD/IC view for securing Web service interactions within a serviceoriented environment. This reference architecture defines an abstract Service Security layer
that is backed by vetted security patterns. The document discusses six basic Authorization
Interaction Patterns that are used as a baseline for advanced architecture patterns. Although
these advanced patterns are not an exhaustive list of all possible integrations, they provide
several example usages that build upon the basic authorization interaction patterns. These
patterns are meant for guidance purposes only. DoD/IC community users may determine which
architecture pattern works best to meet their needs based on their environment needs and existing
systems and capabilities.28
These patterns describe how the access control components specified in the Architectural
Interfaces and Specifications section can be configured differently to support various needs. It is
possible that all six patterns could support ABAC; however, for the purposes of this blueprint,
Authorization Pattern 1 was selected because it is straightforward and supported by most
privilege management software packages. Implementers may choose one or multiple patterns to
support access control to one or several applications; however, the choice of one pattern over
another will be based on which pattern works best to meet the need and which pattern is
supported by the product chosen for the implementation; a given COTS product may not support
all of the patterns. Additionally, performance considerations will play a part in deciding which
pattern or patterns to select.
Authorization Pattern 1 and 2, which are commonly used patterns, are discussed in detail below.
The remaining patterns are summarized in Table 21 following discussion of pattern 2.
Authorization Pattern 1
This pattern, used in the previous two sections, is the most basic because a user may use a thin
client, such as a Web browser, to simply make an access request for a resource protected by a
PEP. The steps associated with Authorization Pattern 1 are illustrated in Figure 23 below. After
authenticating the user (step not shown), the PEP takes the users authentication assertion along
with the resource query and desired action, and passes them to the Policy Decision Service to
request an access decision. The PDS will retrieve the appropriate policy from the Policy Service
and then retrieve the user attributes, resource metadata, and environmental attributes required by
the policy to render an access decision. The PDS will request access control information from as
many sources as required by the policy. Furthermore, multiple attribute sources for each
attribute may need to be utilized depending on the attributes required to make an access decision.
An access decision (permit/deny) is reached by evaluating the attributes against the policy rules
and passed back to the PEP along with any constraints and obligations. The PEPs sole function

28

DoD and IC Service-Oriented Architecture Security Reference Architecture, 15 April 2008

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

73

IdAM Development and Sustainment Support

Engineering Blueprint V2.0

is to enforce the decision, either permitting or denying access, and enforce constraints and
obligations.

Figure 23: Authorization Pattern 1

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

74

IdAM Development and Sustainment Support

Engineering Blueprint V2.0

Table 19: Steps for Authorization Pattern 1

Step

Description

Input

Output

1.

A Service Consumer sends a request

to a Service Provider that is managed
by a PEP.

N/A

request message
SAML Authentication
Assertion

2.

The PEP requests an access control

decision from the PDS.

Request message
SAML Authentication
Assertion

XACML Authorization
Decision Query
including the SAML
Authentication Assertion

3.

The PDS requests access control

policies from the Policy Service.

XACML Authorization
Decision Query, including
the SAML Authentication
Assertion

Get Policy Request

4.

The Policy Service returns access

control policies to the PDS.

Get Policy Request

Get Policy Response

5.

The PDS requests attributes from the

Attribute Service (AS) based on the
Service Consumer.

Get Policy Response

SAML Attribute Query

6.

The AS returns attribute assertions

with the relevant Service Consumer
attributes to the PDS.

SAML Attribute Query

SAML Attribute
Assertion

7.

The PDS makes a decision based on

the attributes and the policies, and
returns a decision assertion to the
PEP.

SAML Attribute Assertion

XACML Authorization
Decision Assertion

8.

The PEP either grants or denies

access to the Service Provider, based
on the decision assertion.

XACML Authorization
Decision Assertion

Request message
SAML Authentication
Assertion

Advantages to this method are:

Integrating with the PEP is a straightforward process that can be achieved with a Web
browser interface.
The only requirement is to pass authentication credentials.
Relevant user attributes are retrieved based on policies for the Service Provider.
Strong/Direct integration with the Policy Service, enables the PDS to perform efficient
querying of the policy store.

The disadvantages are:

Servicing multiple user requests simultaneously may cause the PDS to perform at a
slower rate since all incoming requests and access decisions must be made solely by the
PDS.
Several attribute stores may have to be queried to find the required set of Service
Consumer attributes.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

75

IdAM Development and Sustainment Support

Engineering Blueprint V2.0

Table 20 below summarizes the remaining five examples provided by SSRA. For a
complete description and process flow for each pattern, see SSRA pages 22-31.

Authorization Pattern 2
The 2007 Joint Rapid Architecture Experiment (JRAE 07) was conducted to evaluate the
performance of the proposed Fiscal Year 2008 Joint Targeting Service Oriented Architecture.29
This experiment analyzed the timeliness and accuracy of planned and emergent Joint strike
operations using capabilities from DISA, NSA, USAF, USN, UK, USA, and USMC. In addition
to Authorization Pattern 1 (discussed above), another common pattern, pattern 2, was used in the
experiment.
In Authorization Pattern 2, the Service Consumer Agent requests user attributes from the local
Attribute Service (AS). These attributes are then passed as SAML assertions when requesting
access to the protected resource. The PEP can capture the attribute assertions and pass them to
the PDS. The PDS needs to request policy as well as any other attributes required to make the
access decision. This pattern can work particularly well when the Service Consumer Agent is in
a different domain along with the user attribute service. This pattern is also characteristic of a
portal, which contains service that retrieves attributes and sends them to the resource along with
the request. Because security devices are situated between domains, putting the attributes in the
request may mean that the need for user attributes will already be met. However, if the PDS
needs to request additional attributes from another domain there will be a performance penalty.

29

JRAE 07 Final Test Report Version 1.0, prepared for: Space and Naval Warfare Systems Command Operational Experiments
Office, 10 December 2007.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

76

IdAM Development and Sustainment Support

Engineering Blueprint V2.0

Figure 24: Authorization Pattern 2

Table 20: Steps for Authorization Pattern 2
Step

Description

Input

Output

A Service Consumer requests

attributes for an end-user from
the AS.

N/A

SAML Attribute Query

The AS returns an attribute

assertion to the Service
Consumer.

SAML Attribute Query

SAML Attribute Assertion

The Service Consumer sends

the attribute assertion and the
request to a Service Provider
that is managed by a PEP.

XACML Attribute
Assertion

request message
SAML Authentication &
XACML Attribute Assertion

The PEP requests an access

control decision from the PDS.

Request message
SAML Authentication
& XACML Attribute
Assertion

XACML Authorization
Decision Query ,including a
SAML Authentication &
Attribute Assertion

The PDS requests access

control policies from the Policy
Service.

XACML Authorization
Decision Query,
including a SAML
Authentication &
Attribute Assertion

Get Policy Request

The Policy Service returns

access control policies to the
PDS.

Get Policy Request

Get Policy Response

6a

The PDS requests additional

attributes from an AS, if
necessary.

Get Policy Response

SAML Attribute Query

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

77

IdAM Development and Sustainment Support

Engineering Blueprint V2.0
Step

Description

Input

Output

6b

The AS returns an attribute

assertion to the PDS, if
necessary.

SAML Attribute Query

SAML Attribute Assertion

The PDS makes a decision

based on the attributes and the
policies, and returns a decision
assertion to the PEP.

XACML Attribute
Assertion

XACML Authorization
Decision Assertion

The PEP either grants or denies

access to the Service Provider,
based on the decision assertion.

XACML Authorization
Decision Assertion

Request message
SAML Authentication &
Attribute Assertion

Advantages to this method:

Subject attributes may be found more readily by the Service Consumer Agent.
The PDS may not need to search for additional subject attributes thereby offloading some
of the processing by the PDS.
Strong/Direct integration with the Policy Service enables the PDS to perform efficient
querying of the policy store.

Disadvantages to this method:

If the Service Consumer does not include all of the needed attributes in the request, the
PDS may need to make additional requests for user attributes, thereby adding to the
processing requirements by the PDS.
Service Consumer must be integrated with the Attribute Service and communicate using
the SAML interface.

Authorization Patterns 3 6
The remaining patterns are summarized below. For detailed description of the authorization
pattern and/or to learn more about the patterns refer to the SSRA document.
Table 21: SSRA Authorization Patterns
Pattern Number

Description

The Service Consumer Agent sends the request to the PEP, and the
PEP requests/receives the access control policies and attributes from
the PS and AS respectively. The PEP, then, sends the request,
policies, and attributes to the PDS for an access control decision. In
this pattern, the PEP performs all of the retrievals normally done by the
PDS and would have to be enhanced with more capability to determine
attributes needed by policy.

The Service Consumer Agent sends the request to the PDS, and the
PDS requests/receives access control policies and attributes from the
PS and AS respectively. The PDS then makes an access control
decision and sends the decision back to the Service Consumer Agent,
which, in turn, sends the decision to the PEP for enforcement. In this
pattern, the service consumer would need to be able to accept SAML
assertions from the PDS and send them to the PEP.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

78

IdAM Development and Sustainment Support

Engineering Blueprint V2.0
Pattern Number

Description

The Service Consumer Agent requests/receives user attributes from

the local AS first, and then forwards the request plus the attributes to
the PDS. The PDS requests/receives policies and additional attributes
(if necessary) from the PS and AS respectively, makes an access
control decision, and sends the decision back to the Service Consumer
Agent. The Service Consumer Agent sends the decision to the PEP for
enforcement. This pattern also requires the service consumer to be
able to interact with the PDS and AS using SAML protocols.

The Service Consumer Agent requests/receives access control policies

and attributes from the PS and AS respectively, and then sends the
policies, attributes, and request to the PDS. The PDS makes an
access control decision and sends the decision to the Service
Consumer Agent. The Service Consumer Agent sends the request and
PDS decision to the PEP for enforcement. This pattern would require
the Service Consumer Agent to interact with all of the ABAC services
before forwarding the request and decision to the PEP.

The SSRA document also defines hierarchical and asymmetrical authorization patterns. The
hierarchical pattern can be used for multiple PEP/PDS decisions for a single resource access.
This pattern resembles a cross-enclave access in JRAE07 where one PEP/PDS controlled access
to a resource based on the requesters attributes and resource metadata and another separate
PEP/PDS controlled access of the returning information to the network on which the requester
was located using a separate policy for releasability of the information to the destination
network. In asymmetrical situations, attributes or policies are sent to the PDS without the PDS
requesting them; another component makes the request. For example, a requester might request
his identity provider to send attributes to the PDS and then separately make a request for a
resource. When the PEP sends the authorization request to the PDS, the user attributes would
have already been sent.
Performance Modeling
The basic authorization patterns discussed above have some interface implications as well as
performance implications. Choosing one pattern over another may minimize network delays in
retrieving attributes and policy, and should be considered within the capabilities of the products
used. This section attempts to quantify transaction times to access protected resources in the
basic authorization pattern. Many DoD/IC networks contain boundary security devices,
expressed as Bdev that can add delays to requests for protected resources. One of the Empire
Challenge lessons learned reported an eight second one-way transversal of a high-speed guard.
Thus, significant performance gains can be realized by minimizing the number of times the highspeed guard is crossed. Use of some authorization patterns may minimize those transversals.
Note:

The position of the boundary devices in the timing diagrams is not absolute and may differ.

Performance optimization is a complex process. Typically, the most significant bottleneck is

addressed until another bottleneck is identified and the process is repeated. Using more
computational resources may solve some of the problems but others are a result of network
delays and complexity of process. Caching should be used whenever possible to minimize
network delays and simplification of policy may also yield performance improvements.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

79

IdAM Development and Sustainment Support

Engineering Blueprint V2.0

Although not drawn on the diagrams, the CVS may reside in a different enclave from the PEP,
therefore caching or using a CRL could yield significant benefits.
The authorization pattern above has been enhanced to consider authentication time as well as
positioning boundary devices at likely places in the information flow. The placement of
boundary devices positions the user in a different enclave from the protected resource. The PEP
and PDS would typically be in the same enclave with the resources, policy, and some attribute
sources. However, the user attribute source might be external to the resource enclave. Thus, the
authorization pattern contains 15 steps instead of the eight steps above. The Attribute Services
have been expanded into Attribute Services for user attributes, document attributes and
environment attributes. Not all Attribute Services may be needed depending on the policy
requirements.
Except for verifying the requesters certificate, timing considerations related to PKI operations
have been intentionally omitted as having a negligible effect on the transaction timing. The
reason for this is that although CVS will be required for the PEP, PDS and all other services,
CVS will be invoked for the initial certificate verification of a certificate used for a digital
signature or a Transport Layer Security (TLS) connection. However, once verified, the public
key in the certificate could be used repeatedly without verification for each use. Thus, there
would be an initial time delay for the CVS, the bulk of the transactions would incur no penalty.
The step for validation of the requesters certificate is in the timing consideration because it is
assumed that there would be a sufficiently large population of users accessing resources that
CVS timing would be a significant consideration. However, note that the timing for the Time to
Authenticate (TTA) does contain a note that the time may be zero if there is a cached decision
that can be used. Only patterns 1 and 2 are discussed in this blueprint. The performance
considerations from patterns 1 and 2 can easily be extended to the other authorization patterns
Authorization Pattern 1 Timing
Timing analysis is introduced in Figure 25. Note the numbers on the segments indicate the order
in which the steps proceed. Bdev represents a border security device which may introduce
delays into the process. In the authorization diagrams they are put in likely places but may
appear anywhere between ABAC components.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

80

IdAM Development and Sustainment Support

Engineering Blueprint V2.0

Figure 25: Authorization Pattern 1 Timing

Time to Access Data = TTP + TTA + TTD + TTR + Reply + [possible Bdev delays]
Transit Time to PEP (TTP) = transit time + [possible Bdev delays]
Transit Time to Resource (TTR) may be negligible.
Time to Authenticate (TTA) = (cache check) or ((OCSP or CRL check) + expiration check +
signature validity + certificate chain + usage check)
Time to Decide (TTD) = TTEv + TTRA + TTRE +TTRM + TTRP
Time to Evaluate (TTEv) = time required to evaluate policy statements with attributes and render
an access decision.
Time to Retrieve Attributes (TTRA) = time to retrieve attributes + [possible Bdev delays]
Time to Retrieve Policy (TTRP)
Time to Retrieve Metadata (TTRM)
Time to Retrieve Environment (TTRE)
Bdev

Possible locations for boundary devices (likely locations in cross enclave situations)
DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

81

IdAM Development and Sustainment Support

Engineering Blueprint V2.0

Authorization Pattern 1 is the most likely flow of access since there is no requirement on the user
client to interact with any attribute or authorization components. The user client would typically
only be required to present a client certificate for authentication, which is a capability of popular
browsers with ActivClient Agent. Authorization Pattern 1 puts a big processing load on the
PDS, which is tasked with retrieving all policy and attributes in order to render an authorization
decision. Establishing a cluster of PDSs to service multiple authorization requests in parallel
could yield performance increases by having PEP requests for an authorization decision load
balanced across multiple PDSs. Another performance enhancement, which will be discussed
later, is that the PDS, after retrieving policy, could request user attributes, resource metadata and
environment attributes in parallel, which would result in a maximum function of attribute access
rather than a sum of the serialization of the requests.
Authorization Pattern 1 with Multiple Services
The above timing scenario is built upon a single source each for policy, user attributes, resource
attributes and environment attributes. However, the deployment scenario for ABAC may
involve getting policy, user attributes, resource attributes, and environment attributes from
multiple sources. For example, attributes may be obtained from an Enterprise source and from
another source for mission specific attributes. Policy may be retrieved from a source at the
Enterprise level and from a local source. Furthermore, there is no architectural limit on the
number of sources for policy or attributes. This fact may warrant the addition of multiple
sources for access control information while adding some complexity to Authorization Pattern 1
and the associated timing calculations resulting from the multiple sources. Figure 26 below
illustrates the additional sources and the following timing equations take into account the time
calculation.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

82

IdAM Development and Sustainment Support

Engineering Blueprint V2.0

Figure 26: Authorization Pattern 1 Timing with Multiple Services

The equations change as follows for a Policy Decision Service that requests policy and attributes
serially:
Time to Access Data = TUA + TTP + TTA + TTD + TTR + Reply + [possible Bdev delays on
retrieval]
TUA = Time to retrieve User Attributes (shown on later diagrams)
Transit Time to PEP (TTP) = transit time + [possible Bdev delays]
Transit Time to Resource (TTR)
Time to Authenticate (TTA) = (cache check) or ((OCSP or CRL check) + expiration check +
signature validity + certificate chain + usage check)
Time to Decide (TTD) = TTEv + TTRA + TTRE +TTRM + TTRP
Time to Evaluate (TTEv)
i + [possible Bdev delays] (for n Attribute
Sources)
DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

83

IdAM Development and Sustainment Support

Engineering Blueprint V2.0

i (for n Policy Sources)

i (for n Metadata Sources)
i (for n Environment Sources)
If the PDS is able to request policy and various attribute sources in parallel, the equations for
TTRA, TTRP, TTRM and TTRE would change as follows:
Time to Retrieve Attributes (TTRA) = MAX (TTRAi for i=1,n) for n attribute sources
Time to Retrieve Policy (TTRP) = MAX (TTRPi for i=1,n) for n policy sources
Time to Retrieve Metadata (TTRM) = MAX (TTRMi for i=1,n) for n metadata sources
Time to Retrieve Environment (TTRE) = MAX (TTREi for i=1,n) for n environment sources
Authorization Pattern 2 Timing
Authorization Pattern 2, as shown in Figure 27, can realize some performance gains over
Authorization Pattern 1 by retrieving user attributes and asserting them in the resource request.
If all of the user attributes needed for the access decision are passed in the assertion, time can be
saved in retrieving user attributes likely residing in another domain likely avoiding steps 12a and
12b. If additional attributes are required in step 12a/b, then the transaction time will be slower.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

84

IdAM Development and Sustainment Support

Engineering Blueprint V2.0

Figure 27: Authorization Pattern 2 Timing

As mentioned in the discussion above on Pattern 2, the user client must be able to assert user
attributes as well as an authentication certificate.

DISTRIBUTION STATEMENT A.
Approved for public release; distribution is unlimited.

85