- Federal policies like HSPD-12 and OMB M-11-11 established a common credentialing standard using Personal Identity Verification (PIV) cards, but implementation challenges remain. Identity, not just credentials, should be the focus. - A digital identity record pulls together identity attributes from various sources to uniquely identify individuals across different contexts and applications. Examples of digital identity records and attribute sharing were presented. - Use cases demonstrated challenges with classified environments, credentialing non-federal employees, and integrating physical access control systems at an enterprise level while keeping local facility control. Lessons

1. Lessons Learned from Federal ICAM
Applications of Identity, Credentialing, and Access Management
Joel Rader, CISSP – Solutions Architect

2. Agenda
• Introductions
– Myself, and your interests as an interactive audience
• Federal History with ICAM
– How we arrived at today
• Enterprise Support
– Identity as a Cornerstone
• Use Cases
– Problems, Solutions, Lessons Learned

3. Introductions – Joel Rader
• 10 Years in Military and Federal Consulting
– Enterprise Architecture: Focus on identity
management
– PIV/CAC Credentials: Logical and physical access
• Biometrics (fingerprint, iris)
– Federation: Sharing of information among trusted
partners
– Radiant Logic: Why I’m Here
Affiliation
Employee
Agency/Department
Agency Name
Expires
2015JAN31
Contact
Chip
Lastname
Firstname, MI.
JAN2015
United States Government

4. Introductions – Audience Questions
• What Applications of ICAM Interest You?
– Enterprise Architecture? Fundamentals?
– Smart Cards, compatibility with other organizations?
• Other credentials?
– Physical and Logical Access Convergence?
– Federation and Data Exchange?
– Interaction with Federal/State Government, Military?
– Federal Policy? Difficulties in Practical Implementation?
– How RadiantOne Can Enable Your Success?
– Internet of Things?

5. Federal History with ICAM
HSPD-12 & OMB M-11-11
• HSPD-12
– Released in August 2004, describes need for common identification
standard
– Leads to development of FIPS-201 (‘05) & PIV Card
– Defines common credentialing standard for Federal Employees &
Contractors
• OMB M-11-11
– Released in February 2011, requires PIV usage for physical and logical
access
– Agencies must accept and electronically verify other agency PIV credentials
– Standardization as a way to reduce costs and leverage buying power

6. Federal History with ICAM
FICAM Highlights
• FICAM Roadmap and Implementation Guidance
– Version 1.0 released in November 2009, Version 2.0 in December 2011
– Describes a Segment Architecture, Use Cases, and Implementation Guidance
– Drives the development and implementation of interoperable solutions
– Builds out a Transition Roadmap and Implementation Guidance
– Goes beyond just using a standard credential, presents a high-level vision for the
government
– NIST 800 series for guidelines, recommendations, and reference materials
Key Takeaway (FICAM Roadmap):
“ICAM efforts within the Federal Government are a key enabler for addressing the nation’s
cybersecurity need.”

7. Federal History with ICAM
So Where Are We Today?
• Credential issuance is generally well understood
• Varying levels of implementation progress
• Guidance from HSPD-12, OMB M-11-11, FICAM,
others
• Significant educational progress across industry
But…. we’re not at a ideal state. Why?

8. Federal History with ICAM
Challenges in Actual Implementation
• Many choices in vendor solutions, architecture designs,
etc.
• Significant roadblocks in legacy system integration
• Every organization has unique population demographics
• Cybersecurity failings are a constant distraction
– OMB data breach (20+M records) and cyber “sprints”
• Disconnect between theory and reality
– Pretty pictures and architecture models aren’t actually helpful
– Enterprise architects need to tell you how at a finite level
– That said, DoDAF is a good documentation model to emulate
Department of Defense
Architecture
Framework

9. Identity as a Cornerstone
What Happened to the “I” in ICAM?
• PIV is a credential, not an identity
• Identity should the primary focus for an organization
• Necessary to have high level support, from both
technology and policy
• You have to build a proper foundation first
Key Takeaway:
Identity is the cornerstone of an organization’s ICAM infrastructure
Identity Management System
Notification &
Reporting
Performance
Metric Analysis
Policy &
Process Management
Authoritative
Attribute
Exchange
Identity Record
Database
Data
Segmentation

10. Identity as a Cornerstone
Building a Digital Identity Record
• Context
– Must be useful, relevant, trustworthy
– Must uniquely identify a subject within a given
context
• Consistent
– Must be able to be referenced uniformly across
applications
– Where unique identifiers are not supported,
mappings must be established
• High Assurance
– Trust that a Digital Identity represents an Identity
– Requires Identity Proofing, Vetting, and Adjudication

11. Identity as a Cornerstone
What a Digital Identity Record Looks Like
• Building a Digital Identity Record
– Generating unique identifiers (RFC 4122, UUID)
• Add in credentialing and organization data blocks
– Biographic, Biometric, and Application
• Storing Identity Records – Authoritative Identity
Service
– Federation Support
– Data Sharing – Policy, Payload, and Protocol
Adjudication Results
Human Resources Attributes
Personal Identity Verification (PIV)
Credential Attributes
Clearance
Criminal
Sponsor
Name
Address
Hire Date
Position
Medical Compensation
Dependents
Status
Unique IdentifierUUID
AgencyIssue Date
FASC-NExpiration Date
Active Directory Attributes
Full Name
Digital Identity Record
Application #1 Attributes
User ID Role
TitleEmail Company Department
Office
City

12. Identity as a Cornerstone
What a Digital Identity Record Looks Like
Auditing and Reporting
Systems and Services
CONUS Employee
or Contractor
Application #1
Application #2
Human Resources (HR)
Information
Data Transfer Standards
(XML, SOAP, REST, TLS, SAML 2.0, etc.)
D1 D2 D3Data Elements
Policy
(Purpose, Owners, Legal, Data)
Phase 2
Create Digital
Identity
Notify
Application #3
(Phases 2 & 3)
Authoritative
Identity Service
System or
Service
Active Directory
Authoritative Identity Service
Authoritative Attribute Sources
External User
Data Connection & Exchange Details
Phase 3
OCONUS User
Identity Management
System (IDMS)
External Source
(Phases 2 & 3)
Identity
Digital Identity
Universally Unique
Identifier Database
(UUID)
Federal Background
Investigation Systems
Digital Identity
Records
On-Boarding
Store
Send/Receive
AttributesProvide Attributes
Credential
Report
Access
Report
Hiring
Report
Accounts
and
Privileges
• Key Areas
– Onboarding/Offboarding
Processes
– Authoritative Sources of Data
– Application Usage
– Auditing/Reporting
• Policy, Payload, and Protocol
– Why we’re sharing
– What we’re sharing
– How we’re sharing
• Designed for Department of State

13. Identity as a Cornerstone
What a Digital Identity Record Looks Like
Adjudication Results
Human Resources Attributes
Personal Identity Verification (PIV)
Credential Attributes
Clearance
CriminalBackground
Sponsor
Name
Address
Hire Date
Position
Medical Compensation
Dependents
Clearance
Unique Identifier
Human Resources (HR)
Information
UUID
Cardholder Unique
Identifier (CHUID)
IssueDate
FASC-NExpiration Date
Active Directory Attributes
Display Name
Application #1
Application #2
Digital Identity Record
Application #2 Attributes
User ID Role
PKI Attributes
IssueDate
Expiration Date
Certificate
Hiring
Report
Credential
Report
Accounts
and
Privileges
Title
Data Pull
Data Pull
Data Push
DataConnection&Exchange
Email Company Department
Office
City
Public Key Infrastructure
(PKI) IssuanceSystem
GlobalAddress
List (GAL)
Standardization
Report
Data Pull
Identity Management System
(IDMS)
Active Directory
Authoritative
Attribute Sources
Systems and Services
Auditing and Reporting
AttributeDiscovery
Unique Identifier
Generation System
Federal Background
Investigation Systems
Phase 2 & 3 Attributes
Future Application #1
Attribute 1
Attribute 2
Attribute 3
Future Application #2Attribute 1 Attribute 2
• Building Digital Identity
Record
• Attribute Discovery
• Data Exchanges
• Applications can be both
sources and sinks for
attributes

14. Use Cases
Credentialing in a Classified Environment
Unclassified Access - PIN #1, Proximity, Contactless
• Unclassified Physical Access
• Unclassified Logical Access via Unclassified PKI
Certificate
Classified Access - PIN #2 + Biometric (Iris or Fingerprint)
• Classified Logical Access via Classified PKI Certificate
Benefits
 Maintains unclassified physical topology for privacy
 PIV interoperability in unclassified environments
 Single credential to track and support
 Allows for multi-factor classified access
 No direct link between identities if card compromised
 Maintains separate PKI certificate revocation status
Affiliation
Employee
Agency/Department
Agency Name
Expires
2015JAN31
Contact
Chip
Lastname
Firstname, MI.
JAN2015
United States Government
Customized chip
firmware &
middleware

15. Use Cases
Amtrak Enhanced Employee ID (EID)
Affiliation
Employee
Agency/Department
National Railway
Passenger
Corporation
Expires
2015JAN31
Contact
Chip
Lastname
Firstname, MI.
16026722-1A 44742
IF FOUND, PLEASE RETURN BY DROPPING INA MAILBOX. RETURN
POSTAGE GUARANTEED
Return To:
National Railroad Passenger
Corporation (AMTRAK)
P.O. Box 2597
Washington, DC 20013
Backof
Contact
Chip
To report a crime or suspicious
activity, call the AMTRAK
Police at 1-800-331-0008
• Problem: Need a modern credential to replace legacy
• PIV Card or TWIC?
• Why choose PIV? Need compatibility
• PIV Card, PIV-I, PIV-C, what are the differences?
• Design considerations for security and roles
• Non-Federal Credential Decisions
• Form factor
• Multi-factor authentication
• Mobile devices

16. Use Cases
Enterprise Physical Access Control Systems (ePACS)
Data Cache &
Reconciliation
1:N
Facility PACS
Server
PIV / PIV-I
Readers
Enterprise SAFE
Identity
Data
Active Directory
PIV System /
Non-PIIStore
Credential
Management System
ENTERPRISE
SYSTEMS
ENTERPRISE PACS
MANAGEMENT
Door & Panel
Hardware
Single PACS Facility
Validation Authority
RS-485
Facility PACS Server (Virtualized)
Local SAFE PACS Head-End
Local Facility
Data
*optional
Other Facility
PACS
Local Enrollment
Console(s)
Personnel
Dashboard *optional
Enterprise Local Facilities
SAFE
NOTES:
 Local SAFE (Optional) – Allows for future connectivity to an enterprise
version of SAFE to be streamlined
 Top PACS Server – A “reference” build can be established for new sites to
allow for quick deployment and integration
NOTES:
 Data Cache and
Reconciliation – Allows
for authoritative data to
be provided for PACS
 Enterprise SAFE –
Allows for Facility PACS
to stay local, but
leverage Enterprise
data