Appendix B - DoD_Enterprise_ICAM_Reference_Design.pdf

UNCLASSIFIED

DoD Enterprise Identity, Credential, and Access Management (ICAM)

Reference Design

Version 1.0 June 2020

Prepared by Department of Defense, Office of the Chief Information Officer (DoD CIO)

DISTRIBUTION STATEMENT C. Distribution authorized to U.S. Government agencies and their contractors (Administrative or Operational Use). Other requests for this document shall be referred to the DCIO-CS.

dkluzik Cleared As Amended

NielseRA Cross-Out ii

Document Approvals

Prepared By:

N. Thomas Lam

IE/Architecture and Engineering

Department of Defense, Office of the Chief Information Officer (DoD CIO)

Thomas J Clancy, COL US Army

CS/Architecture and Capability Oversight, DoD ICAM Lead

Approved By:

Peter T. Ranks

Deputy Chief Information Officer for Information Enterprise (DCIO IE)

John (Jack) W. Wilmer III

Deputy Chief Information Officer for Cyber Security (DCIO CS) iii

Version History

Version Date Approved By Summary of Changes

1.0 TBD TBD Renames and replaces the IdAM Portfolio

Description dated August 2015 and the IdAM Reference Architecture dated April 2014. (Existing IdAM SDs and TADs will remain valid until updated versions are established.)

Updates name from Identity and Access Management (IdAM) to Identity, Credential, and Access Management (ICAM) to align with Federal government terminology

Removes and cancels the list of formal ICAM related requirements

Restructures document for clarity

Updates ICAM Taxonomy to better conform to Federal ICAM Architecture

Updates descriptions and data flows of ICAM capabilities

Summarizes current DoD enterprise ICAM services

Defines ICAM roles and responsibilities iv

Executive Summary

The purpose of this Identity, Credential, and Access Management (ICAM) Reference Design (RD) is to provide a high-level description of ICAM from a capability perspective, including transformational goals for ICAM in accordance with the Department of Defense (DoD) Digital Modernization Strategy. As described in Goal 3, Objective 2 of the DoD Digital Modernization Strategy, ICAM “creates a secure and trusted environment where any user can access all authorized resources (including [services, information systems], and data) to have a successful mission, while also letting the Department of Defense (DoD) know who is on the network at any given time.” This objective focuses on managing access to DoD resources while balancing the responsibility to share with the need to protect. ICAM is not a single process or technology, but is a complex set of systems and services that operate under varying policies and organizations.

There are significant advantages to the DoD in providing ICAM services at the DoD enterprise level, including consistency in how services are implemented, improved security, cost savings, and attribution by having a discrete defined digital identity for a single entity. ICAM is also fundamental for the transformation to a modern data-centric identity-based access management architecture that is required in a future-state Zero Trust (ZT) Architecture. To gain these advantages, DoD enterprise ICAM services must support functionality for both the DoD internal community and DoD mission partners, must provide interfaces that are usable by Component information systems, and must minimize or eliminate gaps in supporting ICAM capabilities.

The ICAM RD promotes centralization of identity and credential management, including attribute management and credential issuance and revocation. The ICAM RD also establishes standardized processes and protocols for authentication and authorization. Access decisions must be fundamentally managed by local administrators who understand the context and mission relevance for person entities and Non-Person Entities (NPE) who require access to resources.

The RD defines an ICAM taxonomy that is based on the core elements of the Federal ICAM (FICAM) Architecture, and describes data flow patterns for each of the capabilities defined in the ICAM taxonomy. Systems and services shown in these data flows may be operated at the DoD enterprise, DoD Component, Community of Interest (COI), or local level. In addition to generic data flow patterns, the RD provides a set of implementation patterns and their related use cases for ICAM capabilities. These patterns are intended to demonstrate how capabilities may be implemented to meet a broad set of mission and other needs. They are not intended to be prescriptive for how a given information system consumes ICAM capabilities, nor are they intended to describe all possible ICAM use cases. Finally, the RD describes existing and planned DoD Enterprise ICAM services, and roles and responsibilities for ICAM service providers and for DoD Components in deploying ICAM.

This document is not intended to mandate specific technologies, processes, or procedures. Instead, it is intended to:

Aid mission owners in understanding ICAM requirements and describing current and planned DoD enterprise ICAM services to enable them to make decisions ICAM implementation so that it meets the needs of the mission, including enabling authorized access by mission partners.

Support the owners and operators of DoD enterprise ICAM services so that these services can effectively interface with each other to support ICAM capabilities.

v

Support DoD Components in understanding how to consume DoD enterprise ICAM services and how to operate DoD Component, COI, or local level ICAM services when DoD enterprise services do not meet mission needs.

Each mission owner is responsible for ensuring ICAM is implemented in a secure manner consistent with mission requirements. Conducting operational, threat representative cybersecurity testing as part of ICAM implementation efforts is a mechanism that needs to be used to check secure implementation.

vi

Contents

1. Introduction

1.1. Purpose

1.2. Applicability

1.3. DoD Community

DoD Internal Community

External Mission Partner Community

Beneficiaries

Other Entities

1.4. DoD Computing Environment

1.5. References

2. ICAM Capability Overview

2.1. Transformational Goals

2.2. ICAM Capability Taxonomy Overview (DoDAF CV-2)

Core ICAM Capabilities

2.2.1.1 Identity Management

2.2.1.2 Credential Management

2.2.1.3 Access Management

Access Accountability Capabilities

2.2.2.1 Log Collection and Consolidation

2.2.2.2 Access Review

2.2.2.3 Identity Resolution

Contact Data Capabilities

2.2.3.1 Contact Data Collection

2.2.3.2 Contact Data Lookup

2.3. Using DoD Enterprise ICAM Services

DoD Enterprise Benefits from Use of DoD Enterprise ICAM Services

Information System Benefits from Using DoD Enterprise ICAM Services

Mitigating Challenges to Using DoD Enterprise ICAM Services

3. ICAM Data Flows

3.1. Core ICAM Capabilities

Identity Management

3.1.1.1 Person Entity

3.1.1.2 NPE

3.1.1.3 Federated Entity

Credential Management

3.1.2.1 Internal Credential Management

3.1.2.2 External Credential Registration

Access Management vii

3.1.3.1 Resource Access Management

3.1.3.2 Provisioning

3.1.3.3 Authentication

3.1.3.4 Authorization

3.2. Access Accountability Capabilities

Log Collection and Consolidation

Access Review

Identity Resolution

3.3. Contact Data Capabilities

4. ICAM Patterns and Associated Use Cases

4.1. Identity and Credential Patterns

Unclassified Enterprise DoD Internal Initial Registration

Unclassified Enterprise Mission Partner Entity Registration

Community of Interest User Registration

Community of Interest Person Entity Identity Provider Registration

Secret Enterprise Registration for DoD and Federal Agencies

Secret Enterprise Registration for Non-Federal Agency Mission Partner Entities

Short-Lived NPE Registration

DoD Beneficiary Registration

DoD Applicant Registration

4.2. Access Management Patterns

Access to DoD Managed Resources

Access for Unanticipated Entities

Privileged User Access

Zero Trust

Access to Software as a Service (SaaS) Cloud Managed System

4.3. Access Accountability Patterns

Logging and Monitoring

Access Review

Identity Resolution

4.4. Contact Data Lookup

5. DoD Enterprise ICAM Services

5.1. DoD ICAM Enterprise Services Summary

5.2. Production DoD ICAM Enterprise Services

Person Data Repository (PDR)

Identity Resolution Service

Trusted Associate Sponsorship System (TASS)

DoD Public Key Infrastructure (PKI)

Real-Time Automated Personnel Identification System (RAPIDS) viii

NIPRNet Enterprise Alternate Token System (NEATS) / Alternate Token Issuance and Management System (ATIMS)

Purebred

DoD Self-service (DS) Logon

Enterprise Identity Attribute Service (EIAS)

Identity Synchronization Service (IdSS) milConnect

Enterprise Directory Services (EDS)

Global Directory Service (GDS)

5.3. Planned DoD ICAM Enterprise Services

Mission Partner Registration (MPR)

Identity Provider (IdP)

Multi-Factor Authentication (MFA) Registration Service

EIAS (Enhanced)

Backend Attribute Exchange (BAE)

DS Logon (Enhanced)

Automated Account Provisioning (AAP)

Master User Record (MUR)

6. ICAM Implementation Responsibilities

6.1. DoD ICAM Joint Program Integration Office (JPIO) Responsibilities

6.2. DoD Enterprise ICAM Service Provider Responsibilities

6.3. DoD Component Responsibilities

Establish DoD Component Level ICAM Governance

Support DoD Enterprise ICAM Services

Use DoD Enterprise ICAM Services

Operate COI and Local ICAM Services

6.4. Responsibilities Related to External Federated ICAM Service Providers

7. Summary of ICAM Service Gaps

Mapping ICAM Capabilities to the FICAM Architecture

ICAM and the Risk Management Framework

Case Study: Moving Beyond CAC Authentication and Authorization

DoD Internal Community Persona Type Codes

Non-Person Entity Type Codes

Core Authorization Attributes

Glossary of Terms

Acronyms ix

Figures

Figure 1 – DoD ICAM Vision Capability Viewpoint (CV-1) Figure 2 – Core ICAM High-Level Operational Concept Graphic (OV-1) Figure 3 – ICAM Capability Taxonomy (CV-2) Figure 4 – Person Entity Identity Creation (C1.1.1) Figure 5 – Modify Identity Attributes (C1.1.1) Figure 6 – Modify Attributes (C.1.1.1) Figure 7 – Deactivate Identity (C1.1.1) Figure 8 – Create and Maintain NPE Identity (C1.1.2) Figure 9 – Decommission NPE Identity (C1.1.2) Figure 10 – Modify Federated Identity Attributes (C1.1.3) Figure 11 – Credential Issuance (C1.2.1) Figure 12 – Derived Credential Issuance (C1.2.1) Figure 13 – Credential Revocation (C1.2.1) Figure 14 – Credential Registration (C1.2.2) Figure 15 – Resource Access Management via Hosting Information System (C1.3.1) Figure 16 – Resource Access Management via Data Tagging (C1.3.1) Figure 17 – Manual Provisioning (C1.3.2) Figure 18 – Dynamic Provisioning (C1.3.2) Figure 19 – Direct Authentication (C1.3.3) Figure 20 – Authentication using a Reverse Proxy IdP (C1.3.3) Figure 21 – Authentication using an IdP (C1.3.3) Figure 22 – Authentication of an External Entity using an External IdP (C1.3.3) Figure 23 – Direct Authorization (C1.3.4) Figure 24 – Authorization using Reverse Proxy IdP (C1.3.4) Figure 25 – Dynamic Access using ABAC (C1.3.4) Figure 26 – Log Collection and Consolidation (C2.1) Figure 27 – Person Entity Centric Access Review (C2.2) Figure 28 – Resource Centric Access Review Figure 29 – NPE Centric Access Review Figure 30 – Identity Resolution (C2.3) Figure 31 – Contact Data Collection and Lookup (C3.1, C3.2) Figure 32 – Unclassified DoD Internal Initial Registration Figure 33 – Unclassified Mission Partner Entity Registration Figure 34 – COI User Registration Figure 35 – COI IdP Registration Figure 36 – Secret Network Initial Registration Figure 37 – Secret Registration for Mission Partners Figure 38 – Cloud Elasticity Registration Figure 39 – DoD Beneficiary Registration Figure 40 – Applicant Registration Figure 41 – ICAM Service View (SvcV-1) x

Tables

Table 1 – ICAM Strategy Goals and Objectives Table 2 – Mitigating Challenges with Use of Enterprise ICAM Table 3 – ICAM Data Flow Entities and Services Table 4 – ICAM Enterprise Services Table 5 – Summary of DoD ICAM Enterprise Capability Gaps Table 6 – Mapping of ICAM Capabilities to FICAM Architecture Services Table 7– Mapping NIST SP 800-53 Controls to ICAM Table 8 – Sample Modifications to Support Mission Partner Entity Access Table 9 – Persona Type Codes Table 10 – Glossary

Identity, Credential, and Access Management (ICAM) Reference Design (RD)

1. Introduction

As described in Goal 3 Objective 2 of the Department of Defense (DoD) Digital Modernization Strategy, Identity, Credential, and Access Management (ICAM) “creates a secure and trusted environment where any user can access all authorized resources (including [services, information systems], and data) to have a successful mission, while also letting DoD know who is on the network at any given time.” To realize this objective, the DoD must support capabilities that:

• Provide identity, credential and access management services to protect DoD information systems and DoD electronic Physical Access Control Systems (PACS) resources Provide access accountability

• Enable entities to look up contact data for person entities and Non-Person Entities (NPE)

ICAM is not new to the DoD. ICAM capabilities are already pervasive throughout the DoD because Information Technology (IT) devices, systems, applications and services are in use throughout the DoD.

All of this DoD IT has some form of ICAM capability implemented to protect the full range of DoD information systems and DoD PACS resources, from the least restricted and public to the most restricted and protected. In addition, current ICAM capabilities enable DoD personnel to find and contact each other and enable accountability of user behavior when accessing DoD resources.

Even though DoD ICAM capabilities already exist, these ICAM capabilities need to evolve, and additional ICAM systems and services need to be implemented to meet the DoD ICAM objective and to better align the DoD with the Federal ICAM (FICAM) Architecture. Additionally, DoD ICAM is evolving to support new operating environments such as cloud and the transformation to a modern identity-based access management architecture that is required in a future-state Zero Trust (ZT) Architecture.

DoD ICAM is not a single process or technology but is a complex set of systems and services that operate under various policies and organizations.

The ICAM RD promotes centralization of identity and credential management, including attribute management and credential issuance and revocation. The ICAM RD also establishes standardized processes and protocols for authentication and authorization. Access decisions must be fundamentally managed by local administrators who understand the context and mission relevance for person entities and Non-Person Entities (NPE) who require access to resources.

ICAM capabilities address Risk Management Framework (RMF) security controls designed to mitigate risk and protect resources. The Access Control (AC) and Identity and Authentication (IA) controls are addressed through ICAM, but other RMF controls may also be fully or partially addressed through proper ICAM implementation. Although a complete comparison between ICAM and the RMF security controls is out of scope for this document, a mapping of security controls to related ICAM Reference Design text is provided as Attachment B.

This document summarizes the designs for DoD ICAM:

• Section 1 provides the purpose and scope for this document along with an overview of the DoD enterprise, including the user community and computing environment

• Section 2 describes the DoD ICAM vision, presents the ICAM capability taxonomy, and provides an overview description of each of the ICAM capabilities

• Section 3 provides data flow diagrams describing how ICAM services can work together to achieve ICAM capabilities

• Section 4 identifies a set of use cases for implementing ICAM capabilities for various types of users

• Section 5 identifies operational and planned DoD enterprise level ICAM systems and services that enable ICAM capabilities

• Section 6 provides DoD Component roles and responsibilities for the implementation of ICAM

• Section 7 summarizes gaps in current DoD enterprise ICAM capabilities

Details for design and implementation of DoD enterprise ICAM systems and services as well as interfaces for interacting with ICAM services are found in their respective system documentation.

1.1. Purpose

The purpose of this ICAM Reference Design (RD) is two-fold. First, as an architecture document, it supports the owners and operators of DoD enterprise ICAM services so that these services can effectively interface with each other to support ICAM capabilities, and supports developers so they can implement ICAM using consistent, standards-based methodologies. Second, as a descriptive document, it supports DoD Components in understanding how to consume DoD enterprise ICAM services and how to operate DoD Component, Community of Interest (COI), or local level ICAM services when DoD enterprise services do not meet mission needs. For this document, a COI is a community of people, information systems, and resources that share a common requirement for ICAM that is not at the DoD enterprise level or specific information system level. COIs may be part of other COIs.

There are significant advantages to the DoD to provide ICAM services at the DoD enterprise level, including cost savings from managing software licenses, economies of scale in deploying services, consistency in how services are implemented, improved security, and attribution by having a discrete defined digital identity for a single entity. However, to gain these advantages, DoD enterprise ICAM services must support functionality for both the DoD internal community and DoD mission partners, provide interfaces that are usable by Component information systems and resources, and minimize or eliminate gaps in supporting ICAM capabilities. By describing needed ICAM capabilities and documenting how DoD enterprise services are supporting these capabilities, this RD can promote adoption and use of these services.

Each mission is responsible for ensuring ICAM is implemented in a secure manner consistent with its unique mission requirements. This document is intended to aid mission owners in understanding ICAM capabilities and describing current and planned DoD enterprise ICAM services to enable mission owners to make decisions for how to implement ICAM so that it meets the needs of the mission. The intent of this document is not to mandate specific technologies, processes, or procedures, but to aid mission owners and implementers in evaluating the security and maintainability of their information systems and resources.

Some of the considerations this document will assist mission owners and implementers in assessing include:

Data Sources: provide information about available DoD enterprise sources, attributes available from those sources, requirements for obtaining those attributes, and security considerations for using these services

Identity Synchronization: enumerate common protocols, common procedures, and common technologies for obtaining and using identifiers to support synchronizing identity data between environments

Federation: processes and procedures for leveraging identity data and credentials that are managed outside of the DoD to support authentication and authorization of DoD mission partner entities

Assurance Levels: understanding identity assurance levels (IAL), authenticator assurance levels (AAL), and federation assurance levels (FAL) and their impact to assist mission owners in evaluating the right types of credentials to support in their missions

Authentication: authentication processes, procedures, leading practices, and common pitfalls for person entities and NPEs

Authorization: authorization processes, procedures, leading practices, and common pitfalls for person entities and NPEs

ICAM Technology: key ICAM technical concepts, implementation patterns, and security considerations

Audit: auditing and logging considerations to support accountability

1.2. Applicability

The contents of this document are applicable to all of the following.

The Office of the Secretary of Defense (OSD), the Military Departments, the Office of the Chairman of the Joint Chiefs of Staff (CJCS) and the Joint Staff, the Combatant Commands, the DoD Office of the Inspector General (OIG), the Defense Agencies, the DoD Field Activities, and all other organizational entities within the DoD (referred to collectively as the “DoD Components”).

All DoD unclassified, secret, top secret, and United States (US) owned releasable networks and information systems under the authority of the Secretary of Defense (e.g., Non-classified Internet Protocol Router Network [NIPRNet], Secret Internet Protocol Router Network [SIPRNet], Defense Research and Engineering Network [DREN], Secret Defense Research and Engineering Network [SDREN], SIPRNet Releasable [SIPR REL] De-Militarized Zone (DMZ), United States Battlefield Information Collection and Exploitation System [USBICES], and DoD Mission Partner Environment [MPE]). Information systems include those that are owned and operated by or on behalf of the DoD, including systems hosted at DoD data centers, Platform Information Technology (PIT) systems including weapon systems and control systems, contractor operated systems, cloud hosted systems, and systems hosted on closed operational networks with no connection to the DoD Information Networks (DoDIN).

All DoD and non-DoD person entity and NPE users (referred to as “entities”) accessing DoD unclassified, secret, or top secret networks and resources under the authority of the Secretary of Defense, including DoD mission partners and DoD beneficiaries.

All DoD ICAM capabilities, functions, systems, elements and services implemented at any and all locations, from well-connected Continental United States (CONUS) and Outside Continental United States (OCONUS) environments, to tactical environments, including the most challenging and restricted Denied, Degraded, Intermittent, or Limited bandwidth (DDIL) environments.

The ICAM taxonomy and ICAM data flows in this document apply regardless of whether systems are connected to the DoDIN and regardless of operational considerations. The use of DoD enterprise ICAM services may not be applicable for some mission environments. When DoD enterprise ICAM services are not used, the mission owner is responsible for implementing ICAM capabilities including identity proofing, credential issuance and revocation, attribute management, entitlement provisioning, and logging in accordance with this document.

The designs, requirements, and roles and responsibilities for ICAM capabilities, functions, systems, elements and services implemented by the Intelligence Community (IC) and on the Joint Worldwide Intelligence Communications System (JWICS) are the responsibility of the Director of National Intelligence (DNI) to determine. As a result, this ICAM design does not specifically apply to the following.

However, ICAM capabilities should support interoperability to support information sharing between these environments and the DoDIN.

Sensitive Compartmented Information (SCI) and information systems operated within the DoD that fall under the authority provided in Intelligence Community Directive 503

Top Secret collateral systems

Special Access Programs1

1.3. DoD Community

DoD provides resources to a broad community of users to support its core mission, provide services to beneficiaries, and to address non-traditional missions. ICAM capabilities must be flexible enough to meet the needs of information systems supporting these communities while providing sufficient security to prevent unauthorized access.

DoD Internal Community

The DoD internal community includes all people who are eligible for fully provisioned network accounts on NIPRNet or SIPRNet as a requirement of performing their job function, and NPEs that are fully managed by the DoD. Identity information for the DoD internal community person entities is managed through DoD enterprise services such as the Person Data Repository (PDR), and these entities are issued credentials for the NIPRNet on Common Access Cards (CAC) or Alternate Logon Tokens (ALT) by the DoD Public Key Infrastructure (PKI). On the SIPRNet, these entities are issued credentials by the DoD portion of the National Security System (NSS) PKI. These entities may also be issued additional credentials based on their primary credential for use in specialized environments such as mobile computing and non-traditional systems that do not support the CAC form factor. Identity information for DoD internal NPEs

1 Note that the DoD Special Access Program (SAP) community operates under a separate but similar ICAM strategy and is implementing its own program with guidance from the DoD and the National Security Agency (NSA).

Because of the highly sensitive nature of special access programs and their materials, they must be managed independently and fall under the purview of the DOD SAP Chief Information Officer (CIO) office. For additional details regarding SAP ICAM strategy and implementation, please contact the DOD SAP CIO office.

may be managed through DoD enterprise services or may be managed by the appropriate DoD Component. The DoD internal community includes:

DoD military service members including active duty, reserve, and national guard

DoD civilian employees

Eligible non-US persons who work on DoD computers at DoD facilities

Contractors who work on DoD computers at DoD facilities

Eligible contractors who do not work at DoD facilities

Roles managed by the DoD where the nature of the role requires establishment of a separate digital identity – role identities must be tightly bound to the people who perform them

NPEs that are fully managed by the DoD including o Physical devices such as physical servers, workstations, mobile devices, or routers o Virtual machines including servers and workstations o Information systems, services, and processes with a long-term existence o Information systems, services, and processes with a limited duration and targeted purpose o Non-traditional systems such as weapons systems and control systems

External Mission Partner Community

DoD interacts with a broad community of mission partners who are not eligible for DoD enterprise credentials. The DoD mission partner community includes:

Federal Department and Agency Employees and Provisioned Contractors

Contractors who do not work on DoD computer at DoD facilities and are not otherwise eligible members of the DoD internal community

Non-US persons, including allied and coalition partners

Other Government, including state, local, and tribal government employees

Non-Governmental Organizations (NGO)

External NPEs including those operated by cloud service providers

Some mission partner entities have credentials issued by external providers that are approved for use by DoD information systems, such as Federal Agency Personal Identity Verification (PIV) smart cards, Defense Industrial Base (DIB) commercial PIV-Interoperable (PIV-I) smart cards, or non-US sovereign nation supported credentials. Some mission partner entities may interact with DoD in closed environments where they are issued credentials that are only trusted within that environment. In order to interact with these mission partner entities, authentication services must be able to consume mission partner credentials by leveraging a persistent, unique identifier provided by the mission partner entity.

DoD services may map the identifier contained in the mission partner credential to a persistent, unique identifier assigned by the DoD either at an DoD enterprise, COI, or local level in order to provide an enterprise view of authentication.

Beneficiaries

DoD provides services to people who are eligible for benefits as a result of their relationship to the DoD.

Identity information for DoD beneficiaries is managed through the PDR, and these entities are eligible to obtain credentials through DoD Self-service (DS) Logon. The DoD beneficiary community includes:

DoD military service members including active duty, reserve, and national guard

Military retirees

Military spouses and other dependents

Some overseas DoD civilian employees

Designees who to represent a beneficiary, either by the beneficiary themselves or through a legal process such as dependency or power of attorney

Other Entities

Some DoD information systems interact with external entities for a limited duration or purpose. Identity information for these entities is generally not managed at the DoD enterprise level, and these entities may require locally issued credentials. Other entities include:

Vendors

Non-traditional mission non-government organizations

Military accession applicants who are not yet registered in the PDR

1.4. DoD Computing Environment

The DoD environment is a complex computing environment with a multitude of programs, stakeholders, and other complexities. ICAM is a fundamental building block that must span the environment and cannot be implemented in a one-size-fits-all manner.

ICAM must support missions operating at all security levels, including unclassified, secret, and top secret. It is recognized that a mission operating in a high bandwidth unclassified environment will perform ICAM functions differently than a mission operating in a secret level DDIL environment. The complexity of the types of environments, degree of sensitivity of resources, and devices supported are contributing factors to the difficulty of operating in the DoD environment.

Resources may be hosted in different environments, including:

DoD enterprise owned and managed data centers

DoD Component owned and managed data centers

Mission partner data centers

Private, public, or hybrid clouds including government clouds

Information systems deployed with tactical units

Person entities and NPEs accessing these resources operate from endpoint devices that include laptops and desktops, mobile phones or tablets, and virtual machines. These devices may be owned and managed by the DoD, owned and managed by DoD mission partners, or may be personally owned by person entities. These operations may also take place from within short-lived services or containers.

Information systems and endpoint devices operate in various network environments, including DoD protected high bandwidth, DDIL, closed COI enclaves, and external enclaves with varying degrees of trust such as mission partner networks, private networks, and the public internet.

1.5. References

This RD incorporates and cancels the following documents:

Identity and Access Management Reference Architecture, Version 1.0, April 2014

Identity and Access Management Portfolio Description, Version 2.0, August 2015

Joint Information Environment (JIE) Executive Committee (EXCOM) approved Identity and Access Management (IdAM) Service Descriptions (SD) and Technical Architecture Descriptions (TAD) remain valid until updated versions are established

This RD also references the following documents:

Committee on National Security Systems (CNSS) Instruction 4009, Committee on National Security Systems (CNSS) Glossary, 6 April 2015 https://www.cnss.gov/CNSS/issuances/Instructions.cfm

Department of Defense Naming Convention for People within DoD Identity, Credential, and Access Management, February 2020

DoD Digital Modernization Strategy, 12 July 2019 https://media.defense.gov/2019/jul/12/2002156622/-1/-1/1/dod-digital-modernization-strategy-2019.pdf

DoD Cyber Security Reference Architecture (CSRA)

DoD Identity, Credential, and Access Management Strategy (DRAFT), March 2020

DoD Instruction 8520.03, Identity Authentication for Information Systems, Change 1, 27 July https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/852003p.pdf

Federal Identity, Credential, and Access Management (FICAM) Architecture https://arch.idmanagement.gov/

Homeland Security Presidential Directive (HSPD) 12, Policies for a Common Identification Standard for Federal Employees and Contractors, 27 August 2004 https://www.dhs.gov/homeland-security-presidential-directive-12

Intelligence Community Directive (ICD) 503, Intelligence Community Information Technology Systems Security Risk Management, Certification and Accreditation, 15 September 2008 https://www.dni.gov/files/documents/ICD/ICD_503.pdf

National Institute of Standards and Technology (NIST) Computer Security Resource Center (CSRC) Glossary https://csrc.nist.gov/glossary

NIST Federal Information Processing Standard (FIPS) 201-2, Person Identity Verification (PIV) of Federal Employees and Contractors, August 2013 https://csrc.nist.gov/publications/detail/fips/201/2/final

NIST Special Publication (SP) 800-53-4, Security and Privacy Controls for Federal Information Systems and Organizations https://csrc.nist.gov/publications/detail/sp/800-53/rev-4/final

NIST Special Publication (SP) 800-63-3, Digital Identity Guidelines, 22 June 2017 SP 800-63A, Enrollment and Identity Proofing SP 800-63B, Authentication and Lifecycle Management SP 800-63C, Federation and Assertions https://pages.nist.gov/800-63-3

NIST SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations https://csrc.nist.gov/publications/detail/sp/800-162/final

NIST SP 800-205, Attribute Considerations for Access Control Systems https://csrc.nist.gov/publications/detail/sp/800-205/final

NISTIR 8112, Attribute Metadata: A Proposed Schema for Evaluating Federated Attributes https://csrc.nist.gov/publications/detail/nistir/8112/final

Office of Management and Budget (OMB) Memo M-19-17, Enabling Mission Delivery through Improved Identity, Credential, and Access Management, 21 May 2019 https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf

2. ICAM Capability Overview

This section provides the high-level ICAM capability perspective and includes the transformational vision (DoD Architecture Framework [DoDAF] Capability Viewpoint [CV]-1), a description of ICAM goals and objectives, and the capability taxonomy (DoDAF CV-2).

This DoD ICAM vision is depicted in Figure 1. ICAM capabilities improve mission effectiveness by providing core ICAM (which includes identity management, credential management, and access management), access accountability, and contact data capabilities to achieve ICAM results. These three ICAM operational capabilities define the complete scope of DoD ICAM.

Figure 1 – DoD ICAM Vision Capability Viewpoint (CV-1)

The high-level operational concept for ICAM is shown in Figure 2. This diagram serves as the DoDAF Operational Viewpoint (OV) 1 and as an organizing construct for ICAM enablers, capabilities, business functions and services. It identifies the classes of entities: DoD person entities, DoD NPEs (such as servers and web applications), and federated mission partner entities. The three classes of entities have different processes for identity proofing and credentialing, as discussed in Sections 3.1.1 and 3.1.2. Once credentialed and authenticated, access decisions for entities follow a common process. Access to protected resources is based on the entity and their attributes (including roles), the access labels on a resource, and the access policy that compares the entity and resource attributes and evaluates to make a grant or deny decision.

DoD Identity, Credential, and Access Management (ICAM) Objective Create a secure and trusted environment where any user can access all authorized resources to have a successful mission, while also letting DoD know who is on the network at any given time

ICAM Capabilities

Core ICAM Support Authentication

& Authorization

Access Accountability

Contact Data Collection

Person Entities

Non-Person Entities

Federated Entities

Results

Provide access to DoD resources based on mission need

Support rapid situational response

Enhance visibility and attribution

Demonstrate compliance

Figure 2 – Core ICAM High-Level Operational Concept Graphic (OV-1)

Implementing effective ICAM requires data management in accordance with data management principles, wherever ICAM data is originated or hosted. ICAM data includes identifiers and credentials to support authentication; authorization and environment attributes along with digital policy rules to support authorization; identity attributes to support contact data lookup; and access logs and provisioned entitlements to support attribution. While all data management principles are important, critical DoD Data Strategy goals include making ICAM data visible and accessible to information systems or other entities that require the data and ensuring that ICAM data has sufficient quality that it can be trusted by information systems in making access decisions.

2.1. Transformational Goals

The DoD Digital Modernization Strategy identifies eleven strategy elements in Goal 3, Objective 2, which is to “Deploy an End-to-End Identity, Credential, and Access Management (ICAM) Infrastructure.” These strategy elements are designed to focus DoD resources towards building and deploying ICAM solutions.

The resulting capabilities will facilitate information sharing across the DoD and with mission partners, while managing risks and protecting information against unauthorized access. The strategy elements are listed in Table 1.

Table 1 – ICAM Strategy Goals and Objectives

Element # Strategy Element

1 Expand Public Key Enablement Capabilities to Support ICAM

2 Implement Automated Account Provisioning

3 Implement Support for Approved Multi-Factor Authentication Capabilities

Element # Strategy Element

4 Enhance Enterprise Identity Attribute Service (EIAS)

5 Expand the Use of Derived Credentials

6 Implement a Data Centric Approach to Collect, Verify, Maintain, and Share identity and Other Attributes

7 Improve and Enable Authentication to DoD Networks and Resources through Common Standards, Shared Services, and Federation

8 Deploy Shared Services Promoting the Implementation of Enterprise ICAM

9 Enable Consistent Monitoring and Logging to Support Identity Analytics for Detecting Insider Threats and External Attacks

10 Enhance the Governance Structure Promoting the Development and Adoption of Enterprise ICAM Solutions

11 Create DoD Policies and Standards Clearly Defining Requirements for Identification, Credentialing, Authentication and Authorization Lifecycle Management

2.2. ICAM Capability Taxonomy Overview (DoDAF CV-2)

The DoD ICAM Capability taxonomy is shown in Figure 3. It consists of three high-level parent capabilities: core ICAM, access accountability, and contact data, and their second level child capabilities.

These capabilities collectively provide the DoD with the ability to enable the right person entity or NPE to access the right resource at the right time for the right reason, and support knowing who is on the network at what time and for what reason. The CV-2 is based on the core elements of the FICAM Architecture. Attachment A contains a mapping of this taxonomy to the services defined in the FICAM Architecture.

This section provides an operational description of each of the ICAM capabilities identified in Figure 3.

The intent of this section is to enumerate and describe these capabilities that must be part of DoD ICAM, but not to dictate exact implementations. ICAM capabilities may be performed at the DoD enterprise, DoD Component, COI, or local level. Some capabilities, such as identity management for mission partner entities, may also be performed externally to the DoD. Information systems may also consume capabilities from services operated at multiple levels depending on operational needs.

Figure 3 – ICAM Capability Taxonomy (CV-2)

Core ICAM Capabilities

As defined by the FICAM Architecture, ICAM is “the set of security disciplines that allows an organization to enable the right [entity] to access the right resource at the right time for the right reason.” The FICAM architecture defines five lower level capabilities as:

Identity Management allows an organization to construct a trusted digital identity based on an entity’s defining attributes

Credential Management allows an organization to associate a digital identity with authoritative proof of that claimed identity

Access Management allows an organization to leverage trusted identities and authoritative credentials to ensure only permitted entities are granted access to protected resources

Governance enables organizations to make programmatic decisions, manage enterprise policies, and promote program efficiency.

Federation allows an organization to accept ICAM information and decisions across organizational boundaries based on an established trust.

This document focuses on the first three areas of identity management, credential management, and access management. Governance is addressed in Section 6, ICAM Implementation Responsibilities.

C0. ICAM Capabilities

C1. Core ICAM Capabilities C2. Access Accountability Capabilities

C3. Contact Data Capabilities

C2.1. Log Collection and Consolidation

C2.2. Access Review

C2.3. Identity Resolution

C3.1. Contact Data Collection

C3.2. Contact Data Lookup

C1.1. Identity Management

C1.1.1. Person Entity

C1.1.2. Non-Person Entity

C1.1.3. Federated Entity

C1.2. Credential Management

C1.2.1. Internal Credential Management

C1.2.2. External Credential Registration

C1.3. Access Management

C1.3.1. Resource Access Management

C1.3.2. Provisioning

C1.3.3. Authentication

C1.3.4. Authorization

Federation is addressed within the three core areas. Core ICAM capabilities are shown inside the box in Figure 2, labeled Identity, Credential, and Access Management.

For DoD mission partner entities, ICAM capabilities can be performed internally by the DoD at the DoD enterprise, DoD Component, COI, or local level, or can be performed by federated service providers.

These external services may onboard and manage mission partner entity identity and authorization attributes, issue and maintain credentials, and even perform authentication and generate assertions as an Identity Provider (IdP). Because DoD does not operate or oversee the operations of these external services, DoD must make a determination whether the service is operated in a fashion that is appropriate for DoD parties to rely on artifacts produced by the service. This determination requires that the service provider operates in accordance with an agreed upon set of minimum requirements.

Approval may be implemented through a Memorandum of Agreement (MOA) or other formal mechanism.

Users who require a broad set of entitlements to perform their job function, or who require entitlements that allow them to manage the operations of information systems, network components, or resources are known as privileged users. Privileged users may require separate identifiers and credentials as well as additional auditing or monitoring to verify privileged user accounts are not being accessed by unauthorized users and privileged users themselves are acting within their job responsibilities. Provisioning entitlements for privileged users may leverage physical or virtual network segregation and specialized provisioning and authentication tools. However, the patterns for identity, credential, and access management for privileged users are the same as for non-privileged users.

Examples of privileged users include:

IT privileged users who have roles that allow read, write, or change access to manage IT systems including system, network, or database administrators; and security analysts who manage audit logs – IT privileged user roles are generic to all IT infrastructure, including transport, hosting environments, cybersecurity, and application deployment

Developers and users with access to test tools

Functional privileged users who have approval authorities within workflows – functional privileged user roles are specific to a mission area, such as human resources or finance

2.2.1.1 Identity Management

The baseline requirement for ICAM services is identity management. Entities must be assigned a persistent unique identifier. Attributes can then be bound to the identifier to define a digital identity. A single entity may be assigned different identifiers in different contexts. If these different contexts interconnect, it may be necessary to map identifiers from one context to another. While attributes associated with a digital identity change and evolve over time, digital identities never truly expire.

Instead, a digital identity may be deactivated.

Attributes may be categorized into different types, such as identity, contact, and authorization, depending on how they are managed and used. Person entity identity attributes are generally managed as part of a human resources function, and may include name, rank, and organizational affiliation.

Contact attributes are used to find and contact other entities, such as physical location, telephone number, and email address. Authorization attributes are used to support provisioning and access control decisions, such as clearance, training completion, and COI membership. Entitlements are an example of authorization attributes that are used to determine which information systems or resources within systems that an entity is authorized to access. Each attribute should be managed at a single source and distributed as needed.

Different authorization attributes for a single entity may be managed by different attribute services, depending on where the authoritative information for that attribute value is managed in the organization. Management and orchestration details for this distribution must be governed and controlled to ensure consistent data accuracy and to prevent collisions. It is important to note that a single attribute may be used for multiple purposes. For example, an organizational affiliation attribute may be managed as a human resource data element as an identity attribute but can also be used by a contact data lookup service as a filter or used by an information system to determine authorization to access a requested resource.

Attribute values may also have different degrees of validation. Identity attributes may be verified through background investigations or by obtaining attribute values from a trusted source. Contact attributes may be self-asserted without requiring validation. Attributes whose values are self-asserted and not verified should not be used for authentication or authorization.

Because of security and privacy considerations, it is important that the extent of the distribution of attributes be limited to what is required for specific ICAM operational capabilities. For example, if a digital policy rule only uses a specific subset of attributes to make an access decision for a resource, then only that subset should be provided. Another example is if an information system is accessed only by a subset of DoD entities, then generally only attributes for this subset of entities should be distributed to that information system. An exception might be a service that supports Contact Data capabilities, which may require distributing a subset of contact attributes for entities to that information system. Other considerations for determining the extent attributes should be distributed include privacy and legal considerations, operations security, and system performance, particularly when bandwidth is limited.

Identity management may be performed at the DoD enterprise, DoD Component, COI, or local level.

Identity management for mission partner entities may also be performed externally to the DoD.

2.2.1.1.1 Person Entity

Person entities must be assigned an identifier that is persistent and unique within the context where it is used, which might be DoD enterprise, DoD Component, COI, or local. If a COI or local information system has a combination of users who are registered at the DoD enterprise level and users who are managed locally, digital identities for DoD enterprise registered users must be mapped to their DoD enterprise identifier to support access accountability.

Person entities include people, but person entities may also be roles. For most use cases, roles should be defined as attributes of the people authorized to hold those roles. When distinct identities for roles are required, such as for IT privileged user accounts and representation of organizational affiliation for systems that do not support multiple roles based on a single identity, the role identity must be tightly bound to the individual who is acting in that role to support attribution. Because attributes, credentials, and entitlements may be associated with roles, digital identities for roles must also be managed. A role may be linked to a specific individual, such as an organizational relationship or a privileged user identity.

A role may also be shared by multiple person entities, either concurrently such as membership in a group or sequentially such as a watch officer station that is staffed by different people at different times.

For DoD internal community members and beneficiaries, identity information for person entities is managed at the DoD enterprise level by the Defense Manpower Data Center (DMDC). Person entities are assigned a unique ten digit number identifier by the Person Data Repository (PDR) when the person is first associated with the DoD, which is known as the Electronic Data Interchange Person Identifier (EDIPI). This number is permanently assigned and unchanging. In addition, person entities are assigned an Enterprise Username (EUN), which is a declarative human readable identifier based on the person’s name. The EUN is assigned when the person is first associated with the DoD. If the person changes their name, an additional EUN is assigned and it becomes the primary EUN. Because person entities may have multiple current and previous relationships with the DoD, and these relationships may have different authorizations to access DoD resources, DoD internal community person entities are also assigned one or more personas that identify the relationship of the person entity to the DoD. For example, a Military Service retiree may also be a DoD civilian employee, or a DoD contractor may also be serving in the National Guard. Personas are indicated by a Persona Type Code (PTC) that can be combined with either the EDIPI or the EUN to form a unique persona identifier.