2010 ea conf_ra track presentation_20100506.ppt

8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt

1/47

Reference Architecture Track

Terry Hagle, Office of DoD CIO/AS&I703-607-0235

[email protected]

2010 EA Conference


2/47

Agenda

Enterprise Reference Architecture Cell (ERAC) Overview

Terry Hagle

Reference Architecture (RA)Steve Ring

Principles

Technical Positions Patterns

Enterprise-wide Access to Network and Collaboration

Services (EANCS) RANorm Minekime

DoD Information Enterprise Architecture (IEA)Al Mazyck

Purpose/Background Content

Application of the DoD IEA

Example EANCS RA

Compliance with the DoD IEA

Example EANCS RA 2


3/47

ERAC OVERVIEW

3


4/47

Enterprise Reference Architecture

Cell (ERAC)

Components have expressed the need for more detailed guidance

Enterprise patterns and 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 would need to include processes, process patterns and service

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


5/47

Enterprise Reference Architecture

Mission Statement

The intent of Reference Architecture is to:

Normalize the institutional understanding of capabilities at

the enterprise level and provide a common set ofprinciples, patterns, and technical positionsfor use within

the DoD to guide development of Enterprise, Segment, or

Solution architectures.

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

5


6/47

Reference Architecture

Description

Five components of a Reference Architecture:

Strategic Purpose

Describes the context, scope, goals, purpose, and intendeduse of the RA

Principles

High-level statements about the IT environment that tie backto business goals Incorporate values, organizational culture, and business goals Drive Technical Positions (and Patterns)

Technical Positions Statements that provide technical guidance (standards,

technologies, etc) for use with each major architectural

component or service Patterns/Templates

Diagrams that address the distribution of systems functionsand how they relate topologically

Models that show relationships between components specifiedby the Technical Positions

Vocabulary

Reference Architecture Description 6


7/47

ERAC Process for Developing RA

The ERAC leverages the six step architecture

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)

Collect and Organize data/information (architects collect

& organize, SMEs provide)

Analyze architecture data/information (architects)

Document the results (architects)

Use or apply results (Architecture Owner) 7


8/47

Proposed RA Product Structure

DoDAF Models to Be Developed:AV-1, AV-2, OV-1, OV-5a, OV-6a/c, and StdV-1

Overview and Summary Information (AV-1) Contract between Architecture Owner and Architect Guides development 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 profilespolicy Use Case/Use Case Analysiso Implementation Specificso Specific Technical Standards and Profileso Deployment and Performance Considerations

8


9/47

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

DoD IEA Website

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


10/47

REFERENCEARCHITECTURE

10


11/47

Purpose

DoD CIO intends to use Reference Architecture as a means to provide

Department-wide Guidance for architectures and solutions

Reference Architecture, as currently used within DoD

Is defined at different levels of detail and abstraction (from specific to

generalized) with Has little agreementand 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 policyand directionto 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


12/47

Objectives of a Reference

Architecture

Todirect, guide and constrain

architectures and solutions within a

domain

To serve as a reference foundation of

concepts, components and their

relationships

May be used for comparison andalignment purposes


Stakeholder

Requirements

Guides and

constrains thedevelopment of

Architectures

and

Solutions

Diagram derived from: The Importance of Reference Architecture, Architecture and Change (A&C), 2007,http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture 12
http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/


13/47


is

an authoritative source of unambiguousarchitecture information within a domainenvironment

thatguides and constrains multiplearchitectures and solutions

by providingpatterns of abstractarchitectural elements, based on a strategic

purpose, principles, technical positions, together

with a common vocabulary. 13


14/47

Domain

Building a Reference Architecture

(The Five Components)

Reference Architecture Components

Principles

Patterns Vocabulary

Technical

Positions

StrategicPurpose

Architecture/

Solution

A

Guides ConstrainsAuthoritative

Source

Architecture/

Solution

B

14


15/47

DoDAF Models

Utilized in RAAV-1Overview & Summary Information

CV-1: Visionoverall strategic concept and high level scopeOV-1High Level Operational Concept Graphicwhat solution architectures are intended

to do and how they are supposed to do it

OV-6aOperational Rules Model

SvcV-10a Services Rules Model

SV-10aSystems Rules Model

OV-4Organizational Relationships Chartarchitectural

stakeholders

StdV-1Standards Profile

Operational Patterns

OV-2Operational Resource Flows

OV-5 {a,b}Activity diagrams

Service Patterns

SvcV-1Service Interfaces

SvcV-2Service Resource Flows

SvcV-4Service Functionality

SvcV-10bService State Transitions

System Patterns

SV-1System Interfaces

SV-2 System Resource Flows

SV-4System Functionality

SV-10bSystem State Transitions

Event-Based Scenario Patterns of Dynamic

Behavior

OV-6cEvent-Trace Description

SvcV-10c Services Event-Trace Description

SV-10cSystems Event-Trace DescriptionAV-2Integrated Dictionary- definitions of terms used throughout solution architectures

Strategic Purpose

TechnicalPositions

Principles

Patterns

15


16/47

Benefits

Authoritative source of architecture information within aproblem space that guides and constrains architectures andsolutions

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

16


17/47

First Usage:EANCS Reference Architecture

Supports development of

EANCS implementation

guidance and solution

architectures focuses on that por t ion of thecharacter is t ic deal ing with glo bal

authent icat ion, auth or izat ion and

access co ntro l to g lobal ly

accessible resources. It is in tended

to gu ide the developm ent ofsolut ion archi tec tures and sup por t

the development of specif ic

imp lementat ion guidance for

achieving this capabi l i ty.

Department of Defense

Enterprise-wide Access to Network and

Collaboration Services (EANCS)


Version 3.0

December 2009

Prepared by the Office of the DoD CIO 17


18/47

Enterprise-wide Access to

Networks and CollaborationServices (EANCS) Reference

Architecture (RA)

18


19/47

EANCS RABackground

Operational Requirements GIG 2.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

DoD], login, and be productive

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

Directory Service, Enterprise e-mail, DCO, Intelink) Supporting implementation of an initial authentication and access control

capability in 6 to 9 months for Enterprise User Initiative

Leveraging:

Common credentials for authentication (PKI/CAC for NIPR, PKI/hard-token for SIPR)

Authoritative identity attributes for authorization and access control (Attribute-BasedAccess Control)

19


20/47

EANCS RAPurpose 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


21/47

EANCS RADevelopment Approach

Architecture Owner organized Working Group (WG) Composed of SMEs from ASD (NII)/CIO, Military Services, Joint 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 Concept of Operations (CONOPS) for context

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


22/47

EANCS RASources

Federal

ICAM

ESSF

GIG 2.0

ORA

EANCS

RA

EANCS

CONOPS

USE

CASES

ESM

IMP

PLANIMP

PLANIMP

PLAN

Process &

Function

Operational

Requirements

- Patterns

- Rules

- Technical

Positions

- Operational

Requirements

- Implementation

Considerations

Provide

Analysis

- NIPRnet- SIPRnet

- Deployed User

-Unanticipated

User

-Maritime User

-VPN

-???

Service

Descriptions

- 6 to 9 months

- Longer Period

- Impacts

- Metrics

- Guidance

What To Do How To Do It 22

Legend ESSFEnterprise Security

Services Framework

ESMEnterprise Security

Management

ICAMIdentity, Credential, and

Access Management

ORA -Operational Reference

Architecture


23/47

EANCS RA

Arch i tectu re Art i facts

23

OV-1 (Concept

Consumer & Provider)

OV-5a (Activity

Decomposition)

OV-6a (Operational

Rules Model)

OV-6c (Event-Trace

Description)

EANCSRADocument

Department of Defense

Enterprise-wide Access to Network and

Collaboration Services (EANCS)


Version 3.0

December 2009

Prepared bythe Officeof the DoDCIO

-

GROUP TYPE NAME DESCRIPTION

OMB Policy M-04-04 This guidancerequires agencies to review new

and existingelectronic transactions to ensure

that authentication processes provide theappropriate level of assurance. It establishes and

describes four levels ofidentityassurance for

electronictransactions requiringauthentication.

Assurancelevels also provide abasis for

assessingCredential ServiceProviders (CSPs)on behalf ofFederal agencies. This document

will assist agencies in determiningtheir e-

government needs. Agencybusiness-process

owners bear theprimaryresponsibility to

identifyassurance levels and strategies forprovidingthem. This responsibility extends to

electronicauthentication systems.

OMB Policy M-05-05 This memo requires the useof ashared service

providerto mitigate the risk of commercial

managed services for publickey infrastructure

(PKI) and electronicsignatures.

OMB Policy M-05-24 This memorandum provides implementing

instructions forHSPD-12 and FIPS-201.

OMB Policy M-06-18 This memorandum provides updated direction

forthe acquisition of products and services for

the implementation ofHomeland Security

Presidential Directive-12 (HSPD-12) Policyfor

aCommon Identification Standard forFederalEmployees and Contractorsand also provides

status of implementation efforts.

Presidential

Directive

Policy HSPD-12 HSPD-12 calls foramandatory, government-

widestandard for secureand reliable forms of

ID issued bythe federal government to its

employees andemployees of federal contractors

foraccess to federally-controlled facilities andnetworks.

NIST Guidance SP 800-87 This document provides the organizational codes

forfederal agencies to establish the FederalAgencySmart Credential Number(FASC-N)

that is required to beincluded in the FIPS 201

Card HolderUnique Identifier. SP 800-87 is a

companion document to FIPS 201.

StdV-1 (Standards

Profile)Provides Department-

level guidance for

implementation of

common access

control elements

ArchitectureFederation

Enterprise-wideAccessto NetworkandCollaborationServices

ReferenceArchitecture

OverviewandSummaryInformation(AV-1)

1Architecture ProductIdentification

1.1Name: Enterprise-wideAccessto Networkand CollaborationServices (EANCS)

1.2LeadOrganization: Department ofDefenseDeputyChiefInformationOfficer. The

EnterpriseServicesReviewGroup(ESRG), as thearchitectureowner, isresponsiblefor

architecturecontent and will provideoverall coordinationto ensureappropriate

stakeholdersandsubject-matterexpertsare available; theEnterpriseReference

ArchitectureCell (ERAC), withoversight fromthe ArchitectureandStandardsReview

Group(ASRG), will support thedevelopment of appropriatearchitectureartifacts.

1.3Approval Authority: DoD CIOEnterpriseGuidanceBoard(EGB)

2Purpose andPerspective

2.1Purpose. AReferenceArchitecture(RA)abstractsandnormalizestheinstitutional

understandingofcapabilitiesat theenterpriselevel, andprovidesa commonset of

principles, technical positions, andpatternsforusewithinthe DoDtoguide development

ofEnterprise, Segment, orSolutionarchitectures.

AV-1 (Overview and

Summary)

Strategic

PurposePrinciples

Patterns Technical

Positions

AV-2 (Integrated

Dictionary)Vocabulary


24/47

Compliance

with DoD IEA

Development of RA guided by

Departments Net-centric vision to

function as one unified DoD

Enterprise, creating an informationadvantage 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 E

24


25/47

DoD Information EnterpriseArchitecture (IEA)

25


26/47

Purpose

Unify the concepts embedded in the DoDs net-centric strategies into a common vision

Drive common solutions and promote consistency

Describe the integrated Defense Information

Enterprise and the rules for information assets andresources that enable it

Foster alignment of DoD architectures with the

enterprise net-centric vision

DoD Net-centric Vision

To function as one unified DoD Enterprise, creating an information advantage

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


27/47

Background

Major Net-Centric Strategies

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

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

Data (9 May 2003) Spectrum Management (3 Aug 2006)

Services (4 May 2007) NetOps (February 2008)

Information Assurance (26 April 2006) Communications/Transport

Computing Infrastructure (September 2007) Information Sharing (4 May 2007)


28/47

Audience &

Intended Use

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


29/47

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 DesignatedDoD ES

Adds content to the Rules, App D, and App E to maintain

consistency with App G

DoD IEA v1.2

(Draft)

29


30/47

Applying the DoD IEA

(Appendix D)

30



31/47

Applying the DoD IEAEstabl ish Net Cent r ic

Context fo r EANCS RA

31

Consumer/

User

Perspective Identify DoD IE Perspective for

Architecture

Develop Net-Centric OperationalConcept

Provider/

Producer

Perspective

Understand Net-Centric Concepts

Align with Net-Centric Vision

Identify Net-Centric Assumptions

Align with JCA Taxonomy

Net-Centric Assumptions

Portable identity credentials will be used to

support user authentication

Authorization attributes have already been

defined, collected, regularly updated, and madeavailable through standard interfaces from

reliable attribute sources

Relevant DoD IEA Priority Areas

Secured Availability (SA)

Data and Services Deployment (DSD)

Relevant JCAs

Net-Centric/Enterprise Services/Core

Enterprise Services/User AccessNet-Centric/Information Assurance

OV-1 (Operational

Concept Graphic)



32/47

Applying the DoD IEAA l ign EANCS RA

Desc r ipt ion w ith DoD IEA

32

Align Operational Activities and

Processes with related DoD IEA

Activities

Incorporate applicable DoD

IEA Principles

Apply DoD IEA Rules

Use net-centric

terminology in

architecture

description

Guiding Principles and Rules for RA

Data assets, services, and applications 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. (DoD 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 accessto 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)

OV-6c (Event-Trace

Description)

Oversee

Authentication

Initiatives

Manage

Authentication

Processes

A2.8.4

A2.8.4.1

Oversee

Privilege Mgmt

Initiatives

A2.8.5

Constrain

DoD IEA Terminology

DoD Net-Centric Vision

DoD IE Perspective

User/Consumer

Producer/Provider

Priority Areas

Data and Services Deployment

Secured Availability


33/47

Compliance with the DoD IEA

(Appendix E)

Compliance is about conveying the application of DoD IEA

Principles, Rules, and Activities

Use the process described in App D and provided in App E,

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

33


34/47

Compliance w/the DoD IEA

34

Tab A to Appendix E: DoD IEA Compliance Assessment TableB. Align Architecture Description with the DoD IEA

B1. Use Net-

Centric

Terminology

2.3.2.1.1 Use key terms

contained in

the DoD IEA

Glossary

across

architecture

descriptions.

2.1.1.2.1 Describe

applicable

DoD IEA

key terms.

Describe in

the:

- AV-2

Integrated

Dictionary.

- Related

taxonomies.- ISP

descriptions

of the IE.

Q12 - Identify key

terminology from the

DoD IEA used in your

architecture/program

documents.

B2.

Incorporate

Applicable

DoD IEA

Principles

2.3.2.2.1 - Identify

applicable

DoD IEA

Principles and

use in

architecturedescriptions to

place

restrictions or

limitations on

operations.

- Use

applicable

Principles

2.1.1.2.2 Describe

DoD IEA

Principles.

Describe in

the:

- OV-1

Operational

Concept.

- OV-5Operational

Activity

Model.

- Process

Models

Q13 - Which DoD IEA

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?


35/47

Compliance with the DoD IEAEANCS RA Example

35

Incorporated description of key alignment aspects 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 Guidance for DoD Information Enterprise Architecture 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


36/47

Initiatives and Projects

Reference Architecture Description

Comment Adjudication for ASRG Approval

DoD IEA

Comment Adjudication (v1.2) for DCIO Approval

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 DoD LOBs for the FEA BRM

Recommended changes provided to OMB FEA for action36


37/47

DoD IEA Site:

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

Questions?

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


38/47

BACKUP SLIDES

38


39/47

Information Enterprise

Services and Infrastructure

Architecture

23 November 2013

IE Service/Infrastructure Context Diagram

DRAFT


40/47

Human Computer InteractionWarfighterWarfighter

DefenseIntel

DefenseIntel

NetOpsNetOpsMissionPartnersMissionPartners

BusinessBusiness

IA InfrastructureDynamic Policy Management

Assured Resource AllocationMgmt of IA Assets and Mechanisms

NetOps Infrastructure Enterprise Management

Content Management Net Assurance

Functional Capability Enterprise Services

Mandatory Core & Shared Enterprise Services (ES)

Computing & Communications Infrastructure

Enterprise Services Security Foundation

Information SharingMessaging Portal

Collaboration Mediation

Content Delivery

Enterprise ManagementServices Management

Resource Management

Content Handling


40

DiscoveryPeople/Service Discovery

Content Discovery

Metadata DiscoveryGeospatial Visualization

Mission

&Business

IT

Enterprise

Services

&

Infrastructure

Digital Identity Privilege

Management

Credentialing Authentication Authorization

& Access

Auditing &

Reporting

Cryptography Configuration

Management

Computer

Network Defense

COOP/CIP

Force

Application

Portfolio

Building

Partnerships

Portfolio

Battlespace

Awareness

Portfolio

Protection

Portfolio

Corporate Mgmt

& Support

Portfolio

Force Support

Portfolio

Command &

Control Portfolio

Logistics

Portfolio


41/47

Use Enterprise Services Framework to

Organize and Focus ES Efforts

Enterprise Services Security Foundation (ESSF)41


42/47

Use ESSF Segment Architecture to Organize and

Focus Security Efforts

42


43/47

Development Approach

Describe the components of the context diagram

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 to develop key 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 Shortfalls43

Apply Enterprise Services &


44/47

Apply Enterprise Services &

Infrastructure to GIG 2.0

Requirements through Use Cases

44

Enterpr

ise

ServicesF

oundation

Enterprise

Security

ServicesFoundation


C ll b ti S i


45/47

User

45

Local Access

Request (Logon)

End User Device

(EUD)

Authorization

DecisionRequest

ESSF Authentication

ESSF Digital

IdentityESSF Credentialing

Credential

Validation

Response

Identity

Information

Secondary

Authentication

(if required)ESSF Authorization

& Access Control

Mission Manager

Environmental

Data Response

User

Attribute

Response

ResourceAccess

Policy

Response

Policy

Management

Portable

Identity

Credential

Identity Updates

+ Authentication

Factors Authentication

Decision

Response

Resource

Metadata

Response

Policy

ConstrainedAccess

Printer

Capability

Storag

e

Office Automation

Applicationse-Mail

Collaboration

Document

Sharing

Portal

Enterprise

Directory Desktop/

Browser

Indicates Dependency

Collaboration ServicesUse Case Example

(EANCS)
http://extensions.services.openoffice.org/taxonomy/term/5http://extensions.services.openoffice.org/taxonomy/term/3http://extensions.services.openoffice.org/taxonomy/term/2http://extensions.services.openoffice.org/taxonomy/term/1


46/47

Sample Use Case (Content Request)

User

Porta

l

Information Sharing

Enterprise Services Security Framework

Authenticatio

n

1

2

Discovery

Enterprise

Management

Content

Discover

y3

Content

Mgmt

Mediation

ContentDelivery

4

Authorization &

Access Control

5

6

78

9

10

Infrastructure

46


DRAFT


47/47

Human Computer InteractionWarfighterWarfighter

DefenseIntel

DefenseIntel

NetOpsNetOpsMissionPartnersMissionPartners

BusinessBusiness

IA InfrastructureDynamic Policy Management

NetOps Infrastructure Enterprise Management

Functional Capability Enterprise Services

Mandatory Core & Shared Enterprise Services (ES)


Force

Application

Portfolio

BuildingPartnerships

Portfolio

BattlespaceAwareness

Portfolio

ProtectionPortfolio

Corporate Mgmt

& Support

Portfolio

Force Support

Portfolio

Command &

Control Portfolio

Logistics

Portfolio

Enterprise Services Security Foundation

Information SharingMessaging Portal

Collaboration Mediation

Content Delivery

Enterprise ManagementServices Management

Resource Management

Content Handling

g

DiscoveryPeople/Service Discovery

Content Discovery

Metadata DiscoveryGeospatial Visualization

Mission

&Business

IT

Enterprise

Services

&

Infrastructure

Digital Identity Privilege

Management

Credentialing Authentication Authorization

& Access

Auditing &

Reporting

Cryptography Configuration

Management

Computer

Network Defense

COOP/CIP

EANC

S RA

EU

ITI Opt

Arch

AD Opt

Arch

SAR SA

2010 ea conf_ra track presentation_20100506.ppt

Documents