HC1028-12-R-0044-0002.doc

SECTION SF 30 BLOCK 14 CONTINUATION PAGE

SUMMARY OF CHANGES

SECTION J - LIST OF DOCUMENTS, EXHIBITS AND OTHER ATTACHMENTS

The following have been added by full text:

PEP/PDP ENGINEERING BLUEPRINT

The following have been modified:

RESPONSES TO QUESTIONS

(End of Summary of Changes)

_1399970612.doc IdAM Development and Sustainment Support

Engineering Blueprint v2.0

Attribute Based Access Control (ABAC)

Engineering Blueprint v. 2.0

18 May 2011

DISA

Identity Management Division (PEO-MA, IA4)

Table of Contents

1Executive Summary

Introduction

21.1 Mission Description

31.2 Purpose

31.3 Intended Audience

31.4 Scope

41.5 Dynamic Access Control Development Approach

51.6 Assumptions

51.7 Symbol Conventions

ABAC from a Strategic and Operational Context

62.1 Information Sharing Paradigm

92.2 Access Control in Support of Information Sharing

Attribute Based Access Control

133.1 What is ABAC?

143.2 ABAC Components

Architectural Interfaces and Specifications

194.1 ABAC Component Message Overview

204.2 Message Types

224.3 PEP Specifications

234.3.1 Component Behavior: Enforce Access Control Decision

244.4 PDS Specifications

264.4.1 Component Behavior: Generate Access Control Decision

294.4.2 Component Behavior: Request Access Control Policy

314.4.3 Component Behavior: Request Attributes

324.5 AS Specifications

334.5.1 Component Behavior: Retrieve Attributes

344.6 PS Specifications

354.6.1 Component Behavior: Retrieve Policy

ABAC Demonstrations and Pilots

375.1 Joint Rapid Architecture Experiment (2006/2007) Demonstration

375.2 Empire Challenge (08/09) Demonstration

385.3 Joint Expeditionary Forces Exercises 2008 Demonstration

385.4 The Joint Forces Command Defense Knowledge Online/Joint Knowledge Online Pilot

395.5 PvM Pilot Phase I

395.6 PvM Pilot Phase II

395.7 OpenAM Reference Implementation

Implementation Approach and Lessons Learned

416.1 Integration with Native Access Controls

416.2 Policy Creation

416.3 Standards

416.4 Performance and Scalability

426.5 Design Considerations

426.5.1 PEP – Policy Enforcement Point

436.5.2 Policy Decision Service

446.5.3 Attribute Service

446.5.4 Policy Service

Enabling Performance and Resiliency

467.1 Policy Enforcement Point

467.2

477.3 Access Control Component Horizontal Scaling

497.4 High Availability Design

Issues and Challenges

54Appendix A: Acronyms and Abbreviations

58Appendix B: Data Dictionary

62Appendix C: References

64Appendix D: Security Frameworks Overview

64DISA IdAM Framework

66Federal Identity, Credentialing, and Access Management

67NSA Enterprise Security Management

68Comparison of Security Frameworks

70Appendix E: Supporting Documentation

70Policy Analysis Requirements

70Government and Market Surveys

70Operational Use Cases

70Gap Analysis Document

70Operational Requirements Document

71Research Documentation and Results

71System Requirements Document

71Risk Analysis Report

72Engineering Blueprint- v1

72Proof of Concept Design Document

72Test Plan

72Reference Implementation

73Appendix F: Architectural Patterns and Performance Modeling

73Authorization Pattern 1

76Authorization Pattern 2

78Authorization Patterns 3 – 6

79Performance Modeling

80Authorization Pattern 1 Timing

82Authorization Pattern 1 with Multiple Services

84Authorization Pattern 2 Timing

List of Figures

4Figure 1: Dynamic Access Control Development Approach

5Figure 2: Symbol Convention

8Figure 3: Engineering Blueprint in Support of GIG 2.0

10Figure 4: Access Control Today

11Figure 5: Dynamic Access Control

16Figure 6: Basic ABAC Authorization Pattern

19Figure 7: Logical ABAC Interfaces

24Figure 8: Enforce Access Control Decision

28Figure 9: Generate Access Control Decision Process Flow

30Figure 10: Request Access Control Policy Process Flow

32Figure 11: Request Attributes Process Flow

34Figure 12: Retrieve Attributes Process Flow

36Figure 13: Retrieve Policy Process Flow

43Figure 14: PEP Integration Patterns

45Figure 15: Authorization Pattern 1 Flow

47Figure 16: Multiple PEPs

48Figure 17: Multiple PDSs

49Figure 18: High Availability Configuration

65Figure 19: DISA IdAM Framework

67Figure 20: FICAM Services Framework

68Figure 21: ESM Services

69Figure 22: Security Framework Mapping

74Figure 23: Authorization Pattern 1

77Figure 24: Authorization Pattern 2

81Figure 25: Authorization Pattern 1 Timing

83Figure 26: Authorization Pattern 1 Timing with Multiple Services

85Figure 27: Authorization Pattern 2 Timing

List of Tables

6Table 1: Mission Support Capabilities

8Table 2: JCA Alignment to Blueprint

11Table 3: Access Control Types

13Table 4: ABAC Enablement of Mission Support Capabilities

14Table 5: ABAC Components

17Table 6: ABAC Programs and Initiatives

20Table 7: ABAC Message Types

22Table 8: Policy Enforcement Point Functions

23Table 9: Enforce Access Control Decision Behavior

25Table 10: Policy Decision Point Functions

26Table 11: Generate Access Control Decision Behavior

29Table 12: Request Access Control Policy Behavior

31Table 13: Request Attributes Behavior

32Table 14: Attribute Service Functions

33Table 15: Retrieve Attributes Behavior

34Table 16: Policy Service Functions

35Table 17: Retrieve Policy Behavior

51Table 18: ABAC Issues and Challenges

75Table 19: Steps for Authorization Pattern 1

77Table 20: Steps for Authorization Pattern 2

78Table 21: SSRA Authorization Patterns

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, dynamic communities of interest (COIs), and changing mission needs at modern day mission tempos.

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@disa.mil.

1 Introduction

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.

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 without…assured access to cyberspace.”

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.

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.

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.

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

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.

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 exercises 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

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.

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

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 today’s technology infrastructure inhibiting communication and information sharing across all four major DoD branches, other federal agencies, the intelligence communities, and coalition partners.

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.

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.

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) 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:

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 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 data

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 partners

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.

Access Control in Support of Information Sharing

Many of today’s 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 today’s operational landscape, and creates information stovepipes impeding the ability to enable authorized access to mission essential data in a timely 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

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

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 IA43’s 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 requester’s 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.

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.

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 PEP’s 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 requester’s 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 entity’s information from variety of authoritative identity stores such as directories and databases.

Resource Metadata Service (RMS)

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 Service

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.

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 decision. The PEP then either enforces the grant or denies access control decision for the service requester’s 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.

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 DoD’s 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.

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 DDMS’s 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

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.

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

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 (<samlp:ResponseInResponseTo>)

· Issuer/Unique Id (<saml:Issuer>)

· Subject Name (<saml:Subject>)

· Validity duration of message

(<saml:ConditionsNotOnOrAfter>, <saml:ConditionsNotBeforeOrAfter>)

· Authorization decision (<xacml-context:Decision>)

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

· Subject name (<saml:NameID>)

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

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

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.

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

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

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.

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

Nominal Flow

7. PEP sends a request of type <xacml-samlp:XACMLAuthzDecisionQuery> to PDS.

8. 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:

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

10. PDS performs Retrieve Access Control Policy function using PS. (See section 4.6.1)

11. PS sends applicable policy to PDS.

12. PDS receives the applicable policy message and validates the message using step 2.

13. Based on the policy from PS:

a. PDS performs Retrieve…