2010 EA Conference

Reference Architecture Track

Terry Hagle, Office of DoD CIO/AS&I
703-607-0235 terry.hagle@osd.mil

Agenda g
Enterprise Reference Architecture Cell (ERAC) Overview T Terry Hagle H l Reference Architecture (RA) Steve Ring
Principles Technical Positions Patterns

Enterprise-wide p Access to Network and Collaboration Services (EANCS) RA Norm Minekime DoD Information Enterprise Architecture (IEA) Al Mazyck
Purpose/Background p g Content Application of the DoD IEA
Example a p e EANCS CS RA

Compliance with the DoD IEA

Example EANCS RA
2

ERAC OVERVIEW

Enterprise Reference Architecture C ll (ERAC) Cell

Components have expressed the need for more detailed guidance
E Enterprise t i patterns tt and d processes Army CIO/G-6 Comment on DoD IEA v1.1: establish a separate DoD IEA Reference Architecture with sufficient granularity to enable interoperability across the DOD IE/GIG. To foster such interoperability, these reference architectures hit t would ld need dt to include i l d processes, process patterns tt and d service i patterns, as well as service interfaces and metrics.

Purpose:
Develop the reference architecture (artifacts) Assist IT Decision Makers/Components/Programs/Solution Architects as directed
Work as an advisor to the functional architect Assist in the proper application of the DoD IEA, DoDAF and DARS

Conduct architecture assessments as directed

Assess architecture compliance w/DoD IEA Event Driven - Net Centric Reviews (ED-NCR) JCIDS/DAS Milestone Reviews

Management:
ERAC funded by and resources managed by EA&S Taskings and guidance from the EGB/ASRG
4

Enterprise Reference Architecture Mission Statement

Th The i intent t t of fR Reference f A Architecture hit t i is t to:
Normalize the institutional understanding of capabilities at the enterprise level and provide a common set of principles, patterns, and technical positions for use within the DoD to guide development of Enterprise, Segment, or S l ti hit t Solution architectures.

p Development of a Reference Architecture is a process that results in the required content

Reference Architecture D Description i ti

Five components of a Reference Architecture: Strategic Purpose
Describes the context, scope, goals, purpose, and intended use of the RA High-level statements about the IT environment that tie back to business goals Incorporate values, organizational culture, and business goals Drive Technical Positions ( (and Patterns) ) Statements that provide technical guidance (standards, technologies, etc) for use with each major architectural component or service Diagrams that address the distribution of systems functions and how they relate topologically Models that show relationships between components specified by the Technical Positions
6

Principles

Technical Positions

Patterns/Templates P tt /T l t

Vocabulary Reference Architecture Description

ERAC Process for Developing RA

Th The ERAC l leverages th the six i step t architecture hit t development process of the DoDAF The process steps are:
Clarify Purpose (Architects & Architecture Owner) Clarify Scope (Architects & Architecture Owner) Identify key questions (Architects & Architecture Owner) Determine required data/information (architects) C ll t and Collect dO Organize i d data/information t /i f ti ( (architects hit t collect ll t & organize, SMEs provide) Analyze architecture data/information (architects) Document the results (architects) Use or apply results (Architecture Owner)

Proposed RA Product Structure

DoDAF Models to Be Developed: AV-1, AV-2, OV-1, OV5 OV 5a, OV-6a/c, 6 / and d StdV StdV-1 1 Overview and Summary Information (AV-1)
Contract between Architecture Owner and Architect Guides development p of the RA Executive level presentation of RA DM2: Vocabulary and Semantics

Reference Architecture Document

Introduction ( (Content from AV-1) ) Context and Relationships (Resulting Principles) Term Definitions Architectural Patterns Generic Standards and p profiles p policy y Use Case/Use Case Analysis o Implementation Specifics o Specific Technical Standards and Profiles p y and Performance Considerations o Deployment
8

DoD IEA Website

http://cio-nii.defense.gov/sites/diea/ p g

REFERENCE ARCHITECTURE

10

Purpose
DoD CIO intends to use Reference Architecture as a means to provide D Department-wide t t id Guidance G id for f architectures hit t and d solutions l ti Reference Architecture, as currently used within DoD : Is defined at different levels of detail and abstraction (from specific to generalized) with : Has little agreement and much confusion : Has multiple meanings relative to the context of the environment To support the DoD CIO intent, a common definition of Reference Architecture is needed that ; Provides policy and direction to the DoD enterprise (commands, services, agencies) that guides and constrains architectures and solutions ; Can be equally applied across the wide spectrum of DoD environments IT/ Business and Service (SOA) domains Warfighter domains
11

Objectives of a Reference A hit t Architecture

Reference Architecture

Guides id and d constrainsthe developmentof Stakeholder Requirements

Architectures and Solutions

To direct, guide and constrain architectures and solutions within a domain To serve as a reference foundation of concepts components and their concepts, relationships May be used for comparison and alignment purposes

Diagram derived from: TheImportanceofReferenceArchitecture,ArchitectureandChange(A&C),2007, http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture

12

Reference Architecture is
anauthoritative th it ti sourceof funambiguous bi architectureinformationwithinadomain environment thatg guides andconstrains multiple p architecturesandsolutions byprovidingpatterns ofabstract architecturalelements,basedonastrategic purpose principles, purpose, principles technicalpositions positions,together withacommonvocabulary. 13

Building a Reference Architecture (Th t ) (The Fi Five C Components)

Domain
Reference Architecture Components
Principles Strategic St t i Purpose
Authoritative Source Guides Constrains Patterns Vocabulary

Technical Positions

Architecture/ Solution A

Architecture/ Solution B
14

Strategic Purpose Principles

AV-1 Overview & Summary Information CV-1: Vision overall strategic concept and high level scope OV-1 High Level Operational Concept Graphic what solution architectures are intended to do and how they are supposed to do it OV-6a Operational Rules Model SvcV-10a Services Rules Model StdV-1 Standards Profile
SV-10a Systems Rules Model OV-4 Organizational Relationships Chart architectural stakeholders

DoDAFModels UtilizedinRA

Technical Positions

Operational Patterns OV-2 Operational Resource Flows OV-5 {a,b} Activity diagrams
Patterns

Service Patterns S V 1 Service SvcV-1 S i I Interfaces t f SvcV-2 Service Resource Flows SvcV-4 Service Functionality SvcV-10b Service State Transitions

System Patterns SV-1 System Interfaces SV-2 System Resource Flows SV-4 System Functionality SV-10b System State Transitions E Event-Based tB dS Scenario i Patterns P tt of f Dynamic D i Behavior OV-6c Event-Trace Description SvcV-10c Services Event-Trace Description SV-10c Systems y Event-Trace Description p

AV-2 Integrated Dictionary- definitions of terms used throughout solution architectures 15

Benefits
Authoritative source of architecture information within a problem space that guides and constrains architectures and solutions Simplifies and standardizes solutions for complex problems by providing common repeatable patterns Provides early, focused guidance at a sufficient level of abstraction and detail before concrete implementation decisions are known A tool to ensure interoperable architectures and solutions based on common guidance g
16

FirstUsage:
EANCSReferenceArchitecture
Department of Defense Enterprise-wide Access to Network and Collaboration Services (EANCS)
Reference Architecture

Supports development of EANCS implementation guidance and solution architectures

focuses on that portion of the characteristic dealing with global authentication, authorization and access control to globally accessible resources. It is intended to guide the development of solution architectures and support the development of specific implementation guidance for achieving hi i this thi capability bilit .
17

Version 3.0 30

December 2009

Prepared by the Office of the DoD CIO

Enterprise-wide Access to Networks and Collaboration Services (EANCS) Reference Architecture (RA)

18

EANCS RA
Background
Operational Requirements
GIG 2 2.0 0 Operational Reference Architecture (ORA) describes requirement for Global Authentication, Access Control, and Directory Services Vice Chairman Joint Chiefs of Staff (VCJCS) directed ability to go anywhere [in ], login, g , and be productive p DoD],

EANCS RA to address these requirements by:

Providing basis for implementation guidance/roadmap for Enterprise Services Security Foundation (ESSF) Describing Authentication and Authorization and Access Control to networks (NIPRNet and SIPRNet) and designated Enterprise Services (e.g., Enterprise y Service, , Enterprise p e-mail, , DCO, , Intelink) ) Directory Supporting implementation of an initial authentication and access control capability in 6 to 9 months for Enterprise User Initiative Leveraging: g g
Common credentials for authentication (PKI/CAC for NIPR, PKI/hard-token for SIPR) Authoritative identity attributes for authorization and access control (Attribute-Based Access Control)

19

EANCS RA
Purpose and Scope
Purpose
Gain Department-wide consensus on requirements for authenticating users and authorizing user access to DoD Information Enterprise (IE) and, more specifically, to representative collaborative services, to include portals and enterprise e-mail Describe architectural patterns to guide, standardize, and enable the most rapid and cost-effective implementations of an authentication and authorization capability in support of secure information sharing across DoD

Scope
To Be Architectural Description Document requirements, activities, and information for authentication and authorization and access control Document standard/common authentication and authorization and access control processes

20

EANCS RA
Development Approach
Architecture Owner organized Working Group (WG)
Composed of SMEs from ASD (NII)/CIO, (NII)/CIO Military Services Services, Joint Staff/J6 Staff/J6, Defense Manpower Data Center (DMDC), Defense Information Systems Agency (DISA), and National Security Agency (NSA) Team members represented their stakeholder organizations

Architecture Owner worked with ERAC to establish RA purpose, perspective, and scope WG developed d l d Concept C t of f Operations O ti (CONOPS) for f context t t WG provided necessary architecture data/information
Existing documents served as knowledge baseline SME knowledge and experience provided rest of information

ERAC organized collected data into DoDAF-compliant RA description WG approved RA content (Dec 2009) Submitted to Architecture and Standards Review Group (ASRG) for approval and federation into DoD EA 21

EANCS RA
Sources
Process & Function Operational Requirements

Federal ICAM

Legend
ESSF Enterprise Security Services Framework ESM Enterprise Security Management ICAM Identity, Credential, and Access Management ORA -Operational Reference Architecture

ESM

GIG 2.0 ORA

ESSF

Service Descriptions

- Patterns - Rules R l - Technical Positions

EANCS RA

EANCS CONOPS

- Operational Requirements - Implementation Considerations -6t to 9 months th - Longer Period - Impacts - Metrics - Guidance

- NIPRnet et - SIPRnet - Deployed User USE - Unanticipated User CASES - Maritime User - VPN - ???

Provide Analysis

IMP IMP PLAN IMP PLAN PLAN

What To Do

How To Do It

22

EANCS RA
Architecture Artifacts
Architecture Federation
Enterprise-wide Access to Network and Collaboration Services Reference Architecture Overview and Summary Information (AV-1)

Strategic Purpose

Principles

1 Architecture Product Identification 1.1 Name: Enterprise-wide Access to Network and Collaboration Services (EANCS) 1.2 Lead Organization: Department of Defense Deputy Chief Information Officer. The Enterprise Services Review Group (ESRG), as the architecture owner, is responsible for architecture content and will provide overall coordination to ensure appropriate stakeholders and subject-matter experts are available; the Enterprise Reference Architecture Cell (ERAC), with oversight from the Architecture and Standards Review Group (ASRG), will support the development of appropriate architecture artifacts. 1.3 Approval Authority: DoD CIO Enterprise Guidance Board (EGB) 2 Purpose and Perspective 2.1 Purpose. A Reference Architecture (RA) abstracts and normalizes the institutional understanding of capabilities at the enterprise level, and provides a common set of principles, technical positions, and patterns for use within the DoD to guide development of Enterprise, Segment, or Solution architectures.

EANC CS RA Document

Department of Defense Enterprise-wide Access to Network and Collaboration Services (EANCS)

Reference Architecture

AV-1 (Overview and Summary)

OV-1 (Concept Consumer & Provider)

OV-6a (Operational Rules Model)

GROUP OMB TYPE Policy NAME M-04-04 DESCRIPTION This guidance requires agencies to review new and existing electronic transactions to ensure that authentication processes provide the appropriate level of assurance. It establishes and describes four levels of identity assurance for electronic transactions requiring authentication. Assurance levels also provide a basis for assessing Credential Service Providers (CSPs) on behalf of Federal agencies. This document will assist agencies in determining their egovernment needs. Agency business-process owners bear the primary responsibility to identify assurance levels and strategies for providing them. This responsibility extends to electronic authentication systems. This memo requires the use of a shared service provider to mitigate the risk of commercial managed services for public key infrastructure (PKI) and electronic signatures. This memorandum provides implementing instructions for HSPD-12 and FIPS-201. This memorandum provides updated direction for the acquisition of products and services for the implementation of Homeland Security Presidential Directive-12 (HSPD-12) Policy for a Common Identification Standard for Federal Employees and Contractors Contractors and also provides status of implementation efforts. HSPD-12 calls for a mandatory, governmentwide standard for secure and reliable forms of ID issued by the federal government to its employees and employees of federal contractors for access to federally-controlled facilities and networks. This document provides the organizational codes for federal agencies to establish the Federal Agency Smart Credential Number (FASC-N) that is required to be included in the FIPS 201 Card Holder Unique Identifier. SP 800-87 is a companion document to FIPS 201.

P tt Patterns

Technical Positions

OMB

Policy

M-05-05

OMB OMB

Policy Policy

M-05-24 M-06-18

Presidential Directive

Policy

HSPD-12

Version 3.0

December 2009

OV-5a (Activity Decomposition)

NIST

Guidance

SP 800-87

Prepared by the Office of the DoD CIO

OV-6c (Event-Trace Description)

Provides Departmentlevel guidance for implementation of common access control elements

StdV-1 (Standards Profile)

Vocabulary

AV-2 (Integrated Dictionary)

23

Compliance with ith DoD IEA

Development of RA guided by Departments Net-centric vision to function as one unified DoD Enterprise, creating an information advantage for DoD, its people, and its mission partners, as described in DoD IEA Alignment with DoD IEA built-in during RA development IAW DoD IEA Appendix D Compliance with DoD IEA documented in IAW DoD IEA Appendix pp E 24

DoD Information Enterprise Architecture (IEA) ( )

25

Purpose p
Unify the concepts embedded in the DoDs netcentric strategies into a common vision Drive common solutions and promote consistency Describe the integrated Defense Information Enterprise and the rules for information assets and resources that enable it Foster alignment of DoD architectures with the enterprise net-centric vision
DoD Net-centric Vision T function To f ti as one unified ifi d DoD D D Enterprise, E t i creating ti an information i f ti advantage d t for our people and mission partners by providing:
A rich information sharing environment in which data and services are visible, accessible, understandable, and trusted across the enterprise. An available and protected network infrastructure (the GIG) that enables responsive information-centric operations using dynamic and interoperable communications and computing capabilities.

26

Background
Major Net-Centric Strategies
Data (9 May 2003) Services (4 May 2007) Information Assurance (26 April 2006) Computing Infrastructure (September 2007) Spectrum Management (3 Aug 2006) NetOps (February 2008) Communications/Transport Information Sharing (4 May 2007)

DoD IEA v1.0 (Approved 11 April 2008)

Established five priority areas for realizing net-centric goals Provided key principles, rules, and activities for priority areas Positioned as a tool to guide the net-centric transformation of the I f Information ti Enterprise E t i (IE)

DoD IEA v1.1 (Approved 27 May 2009)

Describes a process for applying the DoD IEA content (App D) Describes compliance areas and criteria (App E) Provides activity mapping between the DoD IEA and the NCOW RM (App F)
27

Audience & I t d d Use Intended U

IT Architects
Align architecture with the DoD IEA Apply DoD IEA content (rules, activities, etc) to guide and constrain information enterprise solutions

Managers of IT Programs (PM, PEO, etc.)

Use the DoD IEA to support program design design, development development, and implementation Through solution architectures properly aligned with the DoD IEA

IT Decision-Makers (CPM, IRB, CIO, etc.)

Use the DoD IEA to support investment decisions Through enterprise and solution architectures properly aligned with the DoD IEA

28

DoD IEA v1.2 (Draft)

Adds DoD EA Compliance Requirements (Appendix G)
Compliance with DoD IEA Compliance with Capability and Component EAs Compliance with the DISR Compliance with Mandatory Core and Shared Designated DoD Enterprise Services (ES) Architecture Registration Requirements Provides a table of Mandatory Core and Shared Designated DoD ES Adds content to the Rules, App D, and App E to maintain consistency with App G

29

Applying the DoD IEA (A (Appendix di D)

30

Applying the DoD IEA

Establish Net Centric Context for EANCS RA
Relevant DoD IEA Priority Areas Secured S dA Availability il bilit (SA) Data and Services Deployment (DSD)

Understand Net-Centric Concepts Align with Net-Centric Vision Identify Net-Centric Assumptions

Net-Centric Assumptions Portable identity credentials will be used to support user authentication Authorization attributes have already been defined, collected, regularly updated, and made available through standard interfaces from reliable attribute sources

Identify DoD IE Perspective for Architecture Develop Net Net-Centric Centric Operational Concept

Consumer/ User Perspective Provider/ Producer Perspective

OV-1 (Operational Concept Graphic)

Align with JCA Taxonomy

Relevant JCAs Net-Centric/Enterprise Services/Core Enterprise Services/User Access Net-Centric/Information Assurance

31

Applying the DoD IEA

Align EANCS RA Description with DoD IEA
Guiding Principles and Rules for RA Data assets, , services, , and applications pp on the GIG shall be visible, , accessible, , understandable, , and trusted to authorized (including unanticipated) users. (DoD IEA, GP 03) Global missions and globally dispersed users require global network reach. Information Assurance mechanisms and processes must be designed, implemented, and operated so as to enable a seamless Defense Information Enterprise. (DoD IEA, SAP 03) Authoritative data assets, services, and applications shall be accessible to all authorized users in the Department of Defense, and accessible except where limited by law, policy, security classification, or operational necessity. necessity (DoD IEA, IEA DSDR 01) All DoD information services and applications must uniquely and persistently digitally identify and authenticate users and devices. These services, applications, and networks shall enforce authorized access to information and other services or devices according to specified access control rules and quality of protection requirements for all individuals, organizations, COIs, automated services, and devices. (DoD IEA, SAR 07)

Incorporate applicable DoD IEA Principles pp y DoD IEA Rules Apply

Align Operational Activities and Processes with related DoD IEA Activities

Oversee Authentication Initiatives

A2.8.4

Constrain
Manage Authentication Processes
A2.8.4.1

Use net-centric t terminology i l in i architecture description

DoD IEA Terminology DoD Net-Centric Vision DoD IE Perspective User/Consumer U /C Producer/Provider Priority Areas Data and Services Deployment Secured Availability

Oversee Privilege Mgmt Initiatives

A2.8.5

OV-6c (Event-Trace Description)

32

Compliance with the DoD IEA (A (Appendix di E)

Compliance is about conveying the application of DoD IEA Principles, Rules, and Activities process described in App pp D and provided p in App pp E, , Use the p Tab A Questions that expose the compliance process and application of DoD IEA content are captured in the Enhanced ISP tool Assessment of compliance is based on:
Completed Compliance table ISP and Architecture EISP Report R t
33

Compliance p w/the DoD IEA

Tab A to Appendix E: DoD IEA Compliance Assessment Table
B1. Use NetCentric Terminology 2.3.2.1.1 B. Align Architecture Description with the DoD IEA B Use key terms 2.1.1.2.1 Describe Describe in contained in applicable the: the DoD IEA DoD IEA - AV-2 Glossary key terms. Integrated y across Dictionary. architecture - Related descriptions. taxonomies. - ISP descriptions of the IE. - Identify if 21122 2.1.1.2.2 Describe i Describe i in i applicable DoD IEA the: DoD IEA Principles. - OV-1 Principles and Operational use in Concept. architecture - OV-5 descriptions to Operational place Activity restrictions or Model. limitations on - Process p operations. Models - Use applicable Principles Q12 - Identify key terminology from the DoD IEA used in your architecture/program documents.

B2. 2 Incorporate Applicable DoD IEA Principles

23221 2.3.2.2.1

Q13 - Which i DoD IEA A Principles apply to your Program? Q14 - How do the Principles apply to your Program? Q15 - How are the applicable Principles addressed in your architecture/program documents?

34

Compliance with the DoD IEA

EANCS RA Example
Incorporated p description p of key y alignment g aspects p into RA document
Added section describing RA alignment with JCAs and DoD IEA Priority Areas Added text descriptions of how process patterns align with DoD IEA activities into pattern discussions

Filled out Tab A Compliance Matrix for RA Developed eISP excerpt for RA
Used G Guidance idance for DoD Information Enterprise Architect Architecture re in EISP 2.0 to identify and locate DoD IEA questions to be answered Incorporated information and text from RA document Generated compliance matrix using Xml2PDF 2007 application and ISP_DoD_IEA_Compliance_Table style sheet
35

Initiatives and Projects j

Reference Architecture Description
Comment Adjudication for ASRG Approval

DoD IEA
Comment C Adj Adjudication di i ( (v1.2) 1 2) f for DCIO A Approval l Work on future versions of the DoD IEA

EANCS RA
Delivered to owner; now in FAC/ASRG approval process

Document Process for Developing RA

Describe the process used to develop the EANCS RA

FEA BRM Extension

Extend E t d DoD D D LOB LOBs for f the th FEA BRM Recommended changes provided to OMB FEA for action
36

DoD IEA Site:

http://cio-nii.defense.gov/sites/diea/

Q Questions? ?
37

BACKUP SLIDES

38

Information Enterprise Services and Infrastructure Architecture

8 June 2013

DRAFT

IE Service/Infrastructure Context Diagram

Business Warfighter Warfighter Defense Defense Intel Intel Mission Mission Partners Partners NetOps NetOps

Human Computer Interaction

Mission & Business IT
Force Application Portfolio Building Partnerships Portfolio Command & Control Portfolio Logistics Portfolio Battlespace Awareness Portfolio Protection Portfolio Force Support Portfolio Corporate Mgmt & Support Portfolio

Functional Capability Enterprise Services

Information Sharing
Messaging M i Collaboration Content Delivery Portal P t l Mediation

Discovery
People/Service P l /S i Discovery Di Content Discovery Metadata Discovery Geospatial Visualization

Enterprise Management
S i Services Management M t Resource Management Content Handling

Digital Identity Auditing & Reporting

Privilege Management Cryptography

Credentialing Configuration Management

Authentication Computer Network Defense

Authorization & Access COOP/CIP

Enterprise Services & Infrastructure

Enterprise Services Security Foundation

Mandatory Core & Shared Enterprise Services (ES)

C Computing ti & C Communications i ti Infrastructure I f t t

IA Infrastructure
Dynamic Policy Management Assured Resource Allocation Mgmt of IA Assets and Mechanisms

NetOps Infrastructure
Enterprise Management Content Management Net Assurance

40

Use Enterprise Services Framework to O Organize i and d Focus F ES Efforts Eff t

Enterprise Services Security Foundation (ESSF)

41

Use ESSF Segment Architecture to Organize and Focus Security Efforts

42

Development Approach
Describe the components p of the context diagram g Build use cases based on GIG 2.0 Attributes to establish relationships between its functional components (Mandatory Core & Shared Enterprise Services)
Global Authentication, Access Control, and Directory Services Information and Services From The Edge Joint Infrastructure Common Policies and Standards Unity of Command

Analyze use cases through identification, sequencing, and prioritization of functional components p to develop p key y or foundational Services first Apply analysis to prioritize and manage:
Reference Architecture Development (Principles, Technical Positions, Patterns) Sequence and Monitor Initiatives, Projects, and Programs Identify Issues, Gaps, and Shortfalls

43

Apply Enterprise Services & Infrastructure to GIG 2.0 Requirements through Use Cases
Enterpr rise Services Foun ndation

E Enterprise e Security y Se ervices Foundatio F on

Computing & Communications Infrastructure

44

Use Case Example

(EANCS)
User EndUserDevice (EUD)
LocalAccess Request(Logon) Authorization Decision Request Policy Constrained Access

Collaboration Services

Enterprise Directory

Desktop/ Browser

Document Sharing

Printer Capability

eMail

OfficeAutomation Applications

+Authentication Factors

Portal

Collaboration

Storag e

Authentication Decision Response

Resource Metadata Response

Secondary Authentication (ifrequired)

Portable Identity Credential

ESSFAuthentication
Credential Validation Response

ESSFAuthorization &AccessControl

User Attribute Response

Resource R Access Policy Response

Environmental DataResponse

MissionManager

Identity Information I f ti Policy Management

ESSFCredentialing
IdentityUpdates

ESSFDigital Identity

Indicates Dependency

45

Sample p Use Case (Content Request) q

InformationSharing
1 10

Discovery Content Discover y

User

Porta l
2

Mediation
8 7

Content Delivery

Content Mgmt
5

I f t t Infrastructure

Enterprise Management g

Authenticatio Authorization & n Access Control EnterpriseServicesSecurityFramework

46

DRAFT

IE Service/Infrastructure Context Diagram

Business Warfighter Warfighter Defense Defense Intel Intel Mission Mission Partners Partners NetOps NetOps

Human Computer Interaction

Mission & Business IT
Force Application Portfolio Building Partnerships Portfolio Command & Control Portfolio Logistics Portfolio Battlespace Awareness Portfolio Protection Portfolio Force Support Portfolio Corporate Mgmt & Support Portfolio

Functional Capability Enterprise Services

Information Sharing
SAR SA
Messaging M i Collaboration Content Delivery Portal P t l Mediation

Discovery
People/Service P l /S i Discovery Di Content Discovery Metadata Discovery Geospatial Visualization

Enterprise Management
S i Services Management M t Resource Management Content Handling

EANC S RA

Digital Identity Auditing & Reporting

Privilege Management Cryptography

Credentialing Configuration Management

Authentication Computer Network Defense

Authorization & Access COOP/CIP

Enterprise Services & Infrastructure

Enterprise Services Security Foundation

EU

Mandatory Core & Shared Enterprise Services (ES)

AD Opt Arch

ITI Opt Arch

C Computing ti & C Communications i ti Infrastructure I f t t

IA Infrastructure
Dynamic Policy Management Assured Resource Allocation Mgmt of IA Assets and Mechanisms

NetOps Infrastructure
Enterprise Management Content Management Net Assurance

47