<Insert Picture Here>

FICAM : Architecture and Design Strategies

Ramesh Nagappan

Principal Engineer (ISVe)

Ramesh.Nagappan@sun.com

The following is intended for information purposes

only, and may not be incorporated into any contract.

It is not a commitment to deliver any material, code,

or functionality, and should not be relied upon in

making purchasing decisions.

The development, release, and timing of any

features or functionality described for Oracle’s

products remains at the sole discretion of Oracle.

Agenda

Quick overview on HSPD-12 Personal Identity Verification (PIV) Life-cycle Solution and its core components.

Explore the Federal Identity Credential and Access Management (FICAM) guidelines and its key architectural and design requirements.

Discuss the conceptual solution architecture and technology components for agency-wide FICAM.

Role and relevance of adopting to Oracle Identity Management Solution Suite and its supporting technologies for FICAM.

Identity

Registration

Identity Enrolment &

Adjudication

PIV Physical & Logical Access

Control

PIV Credential Issuance

PIV Credential

Termination

PIV Credential

Maintenance

The PIV Life-cyclePIV Identity Management Activities (From registration to till its retirement)

The PIV EcosystemCore technology components of a PIV Lifecycle

Logical PIV Architecture SolutionPutting it all together

PIV Solution from Oracle and ISV PartnersPre-Integrated, Pre-Verified and Pre-Tested for PIV Deployment

<Insert Picture Here>

FICAM Architecture &

Design Strategies

• Federal Identity, Credential and Access Management (FICAM)> Represents the policy and guidelines for consistent and comprehensive

approach for government-wide Identity and Access Management.

> Defines a set of goals and objectives for achieving the ICAM end-state.> Comply with Federal laws, Regulations, Standards and Governance

> Facilitate E-Government by streamlining access to services

> Improve Security posture across the Federal enterprise

> Enable Trust and Interoperability

> Reduce cost and increase efficiency

> The President’s FY2010 budgets cites the development of FICAM.

• FICAM Part A: Defines the Segment architecture outlining the principles, use cases. transition roadmap and milestones.> To ensure alignment, clarity and interoperability across agencies.

• FICAM Part B: Defines the Implementation Planning and Guidance.

FICAM – OverviewUnderstanding its rationale

Source: ICAM – The Future of Identity Management, Judith Spencer (GSA), Smartcard Alliance Conference 2009

FICAM – Conceptual Model and its key Service Areas

FICAM: Conceptual Model

1. Create and Maintain Digital Identity Record for Internal User.

2. Create and Maintain Digital Identity Record for External User.

3. Perform Background Investigation for Federal Applicant.

4. Create, Issue and Maintain PIV card.

5. Create, Issue and Maintain PKI credential.

6. Create, Issue and Maintain Password Token.

7. Provision and De-provision User Account for an Application.

8. Grant Physical Access to Employee or Contractor.

9. Grant Visitor or Local Access to Federally-controlled Facility or Site.

10. Grant Logical Access.

11. Secure Document or Communication with PKI.

12. Application of the ICAM use cases.

FICAM : Segment Architecture Use CasesHigh-level use cases that describe ICAM activities

Source: ICAM – The Future of Identity Management, Judith Spencer (GSA), Smartcard Alliance Conference 2009

FICAM – Services Framework

FICAM: Services Framework

Mandatory CredentialsPIN (Personal Identification Number)

Cardholder Unique Identifier (CHUID)

PIV Authentication Data (asymmetric key pair and corresponding PKI certificate)

Two biometric fingerprints (CBEFF)

Optional CredentialsAn asymmetric key pair and corresponding certificate for digital signatures

An asymmetric key pair and corresponding certificate for key management

Asymmetric or symmetric card authentication keys for supporting additional physical access applications

Symmetric key(s) associated with the card management system

Source: GSA USAccess

A Quick Look at PIV CardFIPS-201 Mandatory and Optional On-Card Credentials

FICAM : Agency-level Challenges

• Enforcing Identity Assurance Authentication Levels for

Physical Access Control Systems (PACS) and Logical

Access Control Systems (LACS).

• Need for multi-factor Identity assurance using PIV

credentials for accessing PACS and LACS.o OMB M-04-04 E-Authentication Guidance established 4

authentication levels.o NIST SP 800-116 defines PIV credentials based Identity

assurance levels for Uncontrolled/Controlled/Limited/Exclusion areas.

o Enabling PIV credentials for multi-factor authentication integrating Federal bridge CA and Biometric authentication middleware. Defines a “Measure of Trust” with confidence levels Labelled as SOME, HIGH and VERY HIGH and its required PIV

credentials using CHUID, PKI and Biometrics.

FICAM : Agency-level Challenges… contd.

• Secure Documents and Communications with PKI.• Digitally signed document communication and validation of PIV credentials with PKI

providers (FBCA).

• Digitally signed authorizations/approvals using PIV credentials for provisioning/de-

provisioning actions.

• Convergence of Physical and Logical Access Control

using PIV Credentials.• Automated instantaneous provisioning/de-provisioning of User

accounts, access privileges and related attributes to PACS and LACS.o Synchronization of User profile attributes, PIV credentials (PKI /

Biometrics), CRLs, roles, status/attribute changes, access privileges, rules and policies to/from target resources.

o Automation of Authorization and Approval/Denial workflows and notifications for provisioning and deprovisioning of user accounts and privileges.

FICAM : Agency-level Challenges… contd.

• Back-end Attribute Exchange (BAE) & Retrieval for Policy

Enforcement and Decisions.

• To support agency-level Policy enforcement and decision making, requires use of PIV card holder specific attributes (not available on card).

• BAE mandates fetching PIV card-holder’s off-card information from an authoritative source (Attribute Authority).

• BAE Architecture and interface must be in accordance with the specifications (v1.0 May 2008) created by FICC AWF (ICAMSC).

• Adopting SAML and SPML for lookup/fetching BAE information from inter-agency applications.

Measure of Trust for PACS & LACS

Level 4: VERY HIGH Confidence

Attended Biometric (BIO-A)

PIV Authentication Key (PKI)

Card Authentication Key (CAK) + (BIO-A)

Level 3: High Confidence

Biometric (BIO)

Level 2: Some Confidence

Visual (VIS)

Cardholder Unique Identifier (CHUID)

Card Authentication Key (CAK)

E-Authentication Identity Assurance LevelsNIST specified PIV Authentication Mechanisms : SP800-116

Identity Provider

(IDP)

OCSP

Validation

Service Provider

(SP)

Other

Service Providers

(SP)

SAML 2.0

X.509

Exchange

SAML 2.0

X.509

Exchange

• All 4 Assurance Levels

• PKI, Biometrics, CHUID

• PKI credentials verified to CA

• Fingerprints/CBEFF Match to Card

E-Authentication Assurance for LACSPIV Card Credentials based Authentication: Web SSO/Federation

• Fingerprints (CBEFF) matched to PIV Card.

• PKI Credentials (CAK) will be validated using OCSP or CRL DP.

PIV Authentication (PKI + Biometrics)

Convergence of PACS & LACSProvisioning and De-Provisioning Credentials for PACS/LACS

Digitally-signed Authorizations

• FIPS 201 and SP 800-73 mandates the use of Digital Signature for “Integrity and Authenticity”

• IDMS manages the authorization workflow and authority approval and denials.> Digitally signed approvals using PIV card credentials verified against a Federal Bridge CA/Validation

Authority (via OCSP or CRLs).

• Digital authorizations are captured in audit logs as “XML Signature”.

Back-end Attribute Exchange (BAE)

Mechanisms for securely exchanging PIV Card holder information between Relying parties and authoritative sources.• Backend Attribute Exchange Architecture & Interface specification

is defined by GSA HSPD-12 team (May 2008).• Enables PIV card holder information to relying service provider

applications.• Relying parties (RP) act as service providers that relies on Off-the-

card information (Not stored on card) from an authoritative source.o PIV Card information intended for supporting access control decisions, detecting PIV

card tampering, accessing other agency locations, medical emergency etc.

o Enabling access to User attribute profiles, roles, status/attribute changes to/from target PIV card holder privileged resources.

BAE Specification defines the architecture and implementation models for secure attribute exchange .• SAML v2. Attribute Sharing Profile for on-demand exchange of PIV

card hold attributes as a single request/response.• Mandates the requests/responses are signed (XML Signature) and encrypted (XML

Encryption).

• SPML 2.0 based request/responses for supporting lookup /updates/ batch query and retrieval of multiple PIV card holders attributes.

Exchange of PIV Card holder Information between Back-end Systems

Valid:

…

OCSP

Request/Response

SSL/TLS

SAML Attribute QueryValidation

Authority

(PKI Provider)SAML Attribute Statement

SAML Authentication Request

SAML Authentication Statement

IDP(Oracle

Identity

Federation

/OpenSSO)

SP(Fedlet)

1

2

3

4

BAE: SAML Attribute Sharing

• User authentication using the Smartcard based PKI credentials.

SP may validate the X.509 credentials directly with a PKI provider or by redirection to IDP.

• To perform authorization, the SP retrieve the user profile attributes from the IDP using SAML Attribute exchange.

SAML Attribute Sharing supports X.509 authentication based systems (SAML v2.0 XASP).

The IDP (Acting as Attribute authority) identified using pre-configured SAML Metadata info at SP.

Adopting to SAMLv2 w. X.509 Attribute Sharing Profile

BAE: SAML w. X.509 Attribute SharingDeployment Scenario using Oracle Identity Federation / OpenSSO

BAE: Using SPML 2.0 for Attribute SharingSPML based Attribute Lookup/Update from Service Provider

UltraSPARC T2+: For Wire-speed Security

RSA Performance on Oracle Sun CMTOracle Weblogic SSL Performance on Sun CMT Servers

Using PIV Cards in Sun Ray Environment

<Insert Picture Here>

Q & A

Ramesh Nagappan

Ramesh.Nagappan@Sun.com