Automating Google Workspace (GWS) & more with Apps Script
ICAM - Demo Architecture review
1. <Insert Picture Here>
FICAM : Architecture and Design Strategies
Ramesh Nagappan
Principal Engineer (ISVe)
Ramesh.Nagappan@sun.com
2. 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.
3. 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.
4.
5. The PIV Life-cycle
PIV Identity Management Activities (From registration to till its retirement)
Identity
Registration
Identity
PIV Credential
Enrolment &
Termination
Adjudication
PIV Credential PIV Credential
Maintenance Issuance
PIV Physical &
Logical Access
Control
10. FICAM – Overview
Understanding its rationale
• 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.
11. FICAM: Conceptual Model
FICAM – Conceptual Model and its key Service Areas
Source: ICAM – The Future of Identity Management, Judith Spencer (GSA), Smartcard Alliance Conference 2009
12. FICAM : Segment Architecture Use Cases
High-level use cases that describe ICAM activities
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.
14. A Quick Look at PIV Card
FIPS-201 Mandatory and Optional On-Card Credentials
Mandatory Credentials
PIN (Personal Identification Number)
Cardholder Unique Identifier (CHUID)
PIV Authentication Data (asymmetric key pair
and corresponding PKI certificate)
Two biometric fingerprints (CBEFF)
Optional Credentials
An asymmetric key pair and corresponding
Source: GSA USAccess
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
15. 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.
16. 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.
17. 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.
18. E-Authentication Identity Assurance Levels
NIST specified PIV Authentication Mechanisms : SP800-116
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)
19. E-Authentication Assurance for LACS
PIV Card Credentials based Authentication: Web SSO/Federation
SAML 2.0
Service Provider X.509
(SP) Exchange
OCSP
Validation
Identity Provider
(IDP)
SAML 2.0
X.509
Exchange
• All 4 Assurance Levels Other
Service Providers
• PKI, Biometrics, CHUID
(SP)
• PKI credentials verified to CA
• Fingerprints/CBEFF Match to Card
20. PIV Authentication (PKI + Biometrics)
• Fingerprints (CBEFF) matched to PIV Card.
• PKI Credentials (CAK) will be validated using OCSP or CRL DP.
21. Convergence of PACS & LACS
Provisioning and De-Provisioning Credentials for PACS/LACS
22. 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”.
23. Back-end Attribute Exchange (BAE)
Exchange of PIV Card holder Information between Back-end Systems
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.
24. BAE: SAML Attribute Sharing
Adopting to SAMLv2 w. X.509 Attribute Sharing Profile
1 SAML Authentication Request
2 SAML Authentication Statement
Valid:
…
SSL/TLS OCSP
Request/Response
SP IDP
(Fedlet) Validation
3 SAML Attribute Query (Oracle
Identity Authority
Federation
4 SAML Attribute Statement (PKI Provider)
/OpenSSO)
• 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.
25. BAE: SAML w. X.509 Attribute Sharing
Deployment Scenario using Oracle Identity Federation / OpenSSO
26. BAE: Using SPML 2.0 for Attribute Sharing
SPML based Attribute Lookup/Update from Service Provider
