abac engine

UNCLASSIFIED

UNCLASSIFIED

Attribute Based Access Control (ABAC)

Engineering Blueprint v. 2.0

18 May 2011

DISA

Identity Management Division (PEO-MA, IA4)

IdAM Development and Sustainment Support Engineering Blueprint v2.0

ii

UNCLASSIFIED

Table of Contents

Executive Summary .................................................................................................................... 11 Introduction .......................................................................................................................... 21.1 Mission Description ............................................................................................................................. 21.2 Purpose ............................................................................................................................................... 31.3 Intended Audience .............................................................................................................................. 31.4 Scope .................................................................................................................................................. 31.5 Dynamic Access Control Development Approach .............................................................................. 41.6 Assumptions ........................................................................................................................................ 51.7 Symbol Conventions ........................................................................................................................... 5

2 ABAC from a Strategic and Operational Context ............................................................. 62.1 Information Sharing Paradigm ............................................................................................................ 62.2 Access Control in Support of Information Sharing .............................................................................. 9

3 Attribute Based Access Control ....................................................................................... 133.1 What is ABAC?.................................................................................................................................. 133.2 ABAC Components ........................................................................................................................... 14

4 Architectural Interfaces and Specifications .................................................................... 194.1 ABAC Component Message Overview ............................................................................................. 194.2 Message Types ................................................................................................................................. 204.3 PEP Specifications ............................................................................................................................ 224.3.1 Component Behavior: Enforce Access Control Decision ............................................................ 23

4.4 PDS Specifications ............................................................................................................................ 244.4.1 Component Behavior: Generate Access Control Decision ......................................................... 264.4.2 Component Behavior: Request Access Control Policy ............................................................... 294.4.3 Component Behavior: Request Attributes ................................................................................... 31

4.5 AS Specifications .............................................................................................................................. 324.5.1 Component Behavior: Retrieve Attributes ................................................................................... 33

4.6 PS Specifications .............................................................................................................................. 344.6.1 Component Behavior: Retrieve Policy ........................................................................................ 35

5 ABAC Demonstrations and Pilots .................................................................................... 375.1 Joint Rapid Architecture Experiment (2006/2007) Demonstration .................................................... 375.2 Empire Challenge (08/09) Demonstration ......................................................................................... 375.3 Joint Expeditionary Forces Exercises 2008 Demonstration ............................................................. 385.4 The Joint Forces Command Defense Knowledge Online/Joint Knowledge Online Pilot .................. 385.5 PvM Pilot Phase I .............................................................................................................................. 395.6 PvM Pilot Phase II ............................................................................................................................. 395.7 OpenAM Reference Implementation ................................................................................................. 39

6 Implementation Approach and Lessons Learned .......................................................... 416.1 Integration with Native Access Controls ........................................................................................... 416.2 Policy Creation .................................................................................................................................. 416.3 Standards .......................................................................................................................................... 416.4 Performance and Scalability ............................................................................................................. 416.5 Design Considerations ...................................................................................................................... 426.5.1 PEP Policy Enforcement Point ................................................................................................. 426.5.2 Policy Decision Service ............................................................................................................... 436.5.3 Attribute Service .......................................................................................................................... 446.5.4 Policy Service .............................................................................................................................. 44


iii

UNCLASSIFIED

7 Enabling Performance and Resiliency ............................................................................ 457.1 Policy Enforcement Point .................................................................................................................. 467.2 Policy Decision Service ..................................................................................................................... 467.3 Access Control Component Horizontal Scaling ................................................................................ 477.4 High Availability Design ..................................................................................................................... 49

8 Issues and Challenges ...................................................................................................... 51Appendix A: Acronyms and Abbreviations ............................................................................ 54Appendix B: Data Dictionary ................................................................................................... 58Appendix C: References .......................................................................................................... 62Appendix D: Security Frameworks Overview ........................................................................ 64DISA IdAM Framework ............................................................................................................................. 64Federal Identity, Credentialing, and Access Management ....................................................................... 66NSA Enterprise Security Management ..................................................................................................... 67Comparison of Security Frameworks ........................................................................................................ 68

Appendix E: Supporting Documentation ................................................................................ 70Policy Analysis Requirements ................................................................................................................... 70Government and Market Surveys ............................................................................................................. 70Operational Use Cases ............................................................................................................................. 70Gap Analysis Document ............................................................................................................................ 70Operational Requirements Document ....................................................................................................... 70Research Documentation and Results ..................................................................................................... 71System Requirements Document ............................................................................................................. 71Risk Analysis Report ................................................................................................................................. 71Engineering Blueprint- v1 .......................................................................................................................... 72Proof of Concept Design Document ......................................................................................................... 72Test Plan ................................................................................................................................................... 72Reference Implementation ........................................................................................................................ 72

Appendix F: Architectural Patterns and Performance Modeling.......................................... 73Authorization Pattern 1 .............................................................................................................................. 73Authorization Pattern 2 .............................................................................................................................. 76Authorization Patterns 3 6 ...................................................................................................................... 78Performance Modeling .............................................................................................................................. 79Authorization Pattern 1 Timing .................................................................................................................. 80Authorization Pattern 1 with Multiple Services .......................................................................................... 82Authorization Pattern 2 Timing .................................................................................................................. 84

List of Figures

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


iv

UNCLASSIFIED

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

List of Tables

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


v

UNCLASSIFIED

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


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

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 [email protected].

1 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



1 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.

3 Initial Capabilities Document for the Global Information Grid Information Assurance, NSA, 06 March 2006 4 Quadrennial Defense Review Report, February 2010 5 DoD Enterprise Architecture Transition Strategy, February 2008



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.



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

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



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



2 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 DoD Privilege Management Roadmap, 6 January 2010 8 Initial Capabilities Document for the Global Information Grid Information Assurance, NSA, 06 March 2006



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

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

10 ALIGNMENT FRAMEWORK FOR GIG IA ARCHITECTURE, AUGUST 2009



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 Related goals to the Engineering Blueprint/ABAC Solution

Architecture Framework for GIG (AFG) 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.



DoD Initiative Related goals to the Engineering Blueprint/ABAC Solution

DoD Net-Centric JCD Information Sharing based upon need to know while 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 quantities of operational data11

DoD Identity Credential and Access Management12 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 1https://www.us.army.mil/suite/doc/25916685



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.



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 Description Identity Based Access Control (IBAC) Access Control List (ACL)

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



Access Control Types Description Risk Adaptive Access Control (RAdAC) 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



3 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.



Mission Support Capability ABAC Enablement Assured Information Sharing 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.

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.



ABAC Component Description

Resource Metadata Service (RMS) 14 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.

Environmental Attribute Service15 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.



Figure 6: Basic ABAC Authorization Pattern16

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.



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: https://www.intelink.gov/wiki/NSA_%26_DISA_Privilege_Management_Project_References



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



4 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



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 Parameters 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.

The message will contain AT LEAST the following- Subject () Resource () Action () Environment () Authentication validation () Other optional attributes may be included

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.

The message will contain AT LEAST the following- SAML Query Reference ID

() Issuer/Unique Id () Subject Name () Validity duration of message

(, )

Authorization decision ()

18 For more information on SAML and XACML, refer to the OASIS standards, which can be found on http://www.oasis-open.org.



Message Type Parameters 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.

The query will contain AT LEAST the following- Resource Match ID () Resource Match Data Type

() Resource Attribute Designator

() OR Policy Set ():

OR Policy ID Reference ()

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

() Method to match resource attribute

() Resource attribute name

() Method and attributes to match the action attribute

() Effect that will be returned upon successful evaluation

() 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- Subject name () Attribute(s) to be retrieved ()

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- Status of retrieval () Unique Identifier () Validity duration () Attribute name(s) () Attribute value(s) () Attribute service 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.



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 Description Enforce Access Control Decision 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.



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 XACMLAuthzDecisionQuery: The PEP sends an authorization decision query to the PDS.

Operations 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 Service Requester PEP PDS

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

Nominal Flow 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 () Check uniqueness of request messageID () Verify SAML Authentication 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



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.



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.



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. PDS packages a response and sends an access control decision to the PEP.

Actors PEP PDS PS AS

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



Generate Access Control Decision

Nominal Flow 1. PEP sends a request of type 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 () Check uniqueness of request 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 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.



Policy Decision Service: Generate Access Control DecisionsPo

licy

Enfo

rcem

ent

Poin

tPo

licy

Dec

isio

n Se

rvic

ePo

licy

Serv

ice

Attr

ibut

e Se

rvic

es

1PEP Sends

RequestStart

AuthorizationQuery

2PDS Validates

Message Message

Valid?

3Retrieve Policy

XACML Policy Query

4Request Policies

5XACML Policy

Message

8Query

Attributes

SAML Attribute Message

9Receives Attributes

End12

Accept Message

N

2bMessage Invalid Error Message

6Receives

Policy

7Attribute Query

10Determines

Access

11Decision Message

Check PKICertificateY

Certificate Revoked Message

Success Certificate Revoked?N Y

Certificate Revoked

End End

Figure 9: Generate Access Control Decision Process Flow



4.4.2 Component Behavior: Request Access Control Policy Table 12: Request Access Control Policy Behavior

Request Access Control Policy

Inputs XACMLPolicyStatement

Outputs XACMLPolicyQuery

Operations PDS sends a policy query () to retrieve policies from the Policy Service.

Policy Service accepts and processes the message. Policy Service sends a response () 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 to the PS to extract the appropriate policy from the policy store. The policy query will request either a XACML Target (), PolicySet ID Reference (), or Policy ID Reference ()

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:


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 () 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.



Polic

y Se

rvic

ePo

licy

Dec

isio

n Se

rvic

e

Figure 10: Request Access Control Policy Process Flow



4.4.3 Component Behavior: Request Attributes Table 13: Request Attributes Behavior

Request Attributes

Inputs AttributeStatement

Outputs AttributeQuery

Operations PDS sends a query () to the Attribute Service to retrieve user attributes.

Actors and Components PDS AS

Preconditions TLS session exists between the PDS and the AS

Nominal Flow 1. PDS sends a SAML Attribute Query of type 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:


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 ().

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.



Attr

ibut

e Se

rvic

ePo

licy

Dec

isio

n Se

rvic

e

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 Description Retrieve Attributes 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.



4.5.1 Component Behavior: Retrieve Attributes Table 15: Retrieve Attributes Behavior

Retrieve Attributes

Inputs AttributeQuery

Outputs AttributeStatement

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

Attribute Service send a SAML Attribute Assertion () 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 .

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:


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

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.



Serv

ice

Req

uest

erA

ttrib

ute

Serv

ice

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 Description Retrieve Policy The function sends a query to the policy store to

retrieve access control policies based on the security context of the transaction.



4.6.1 Component Behavior: Retrieve Policy Table 17: Retrieve Policy Behavior

Retrieve Policy

Inputs XACMLPolicyQuery

Outputs XACMLPolicyStatement

Operations 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 Service Requester PS

Nominal Flow 1. The service requester sends a 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 () Check uniqueness of request 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 () 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.



Figure 13: Retrieve Policy Process Flow



5 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 original.conducted 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) Demonstration21ThisportionofthedocumenthasbeenremovedasitisDoDsensitive.Pleaserefertotheoriginal.

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



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

abac engine

Documents

access control decision

abac components

support of information

pep specifications

pds specifications

information sharing

component behavior

message types