Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ICAM - Demo Architecture review


Published on

Published in: Technology
  • Be the first to comment

ICAM - Demo Architecture review

  1. 1. <Insert Picture Here> FICAM : Architecture and Design Strategies Ramesh Nagappan Principal Engineer (ISVe)
  2. 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. 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. 4. 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
  5. 5. The PIV Ecosystem Core technology components of a PIV Lifecycle
  6. 6. Logical PIV Architecture Solution Putting it all together
  7. 7. PIV Solution from Oracle and ISV Partners Pre-Integrated, Pre-Verified and Pre-Tested for PIV Deployment
  8. 8. <Insert Picture Here> FICAM Architecture & Design Strategies
  9. 9. 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.
  10. 10. 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
  11. 11. 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.
  12. 12. FICAM: Services Framework FICAM – Services Framework Source: ICAM – The Future of Identity Management, Judith Spencer (GSA), Smartcard Alliance Conference 2009
  13. 13. 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
  14. 14. 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.
  15. 15. 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.
  16. 16. 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.
  17. 17. 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)
  18. 18. 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
  19. 19. PIV Authentication (PKI + Biometrics) • Fingerprints (CBEFF) matched to PIV Card. • PKI Credentials (CAK) will be validated using OCSP or CRL DP.
  20. 20. Convergence of PACS & LACS Provisioning and De-Provisioning Credentials for PACS/LACS
  21. 21. 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”.
  22. 22. 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.
  23. 23. 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.
  24. 24. BAE: SAML w. X.509 Attribute Sharing Deployment Scenario using Oracle Identity Federation / OpenSSO
  25. 25. BAE: Using SPML 2.0 for Attribute Sharing SPML based Attribute Lookup/Update from Service Provider
  26. 26. UltraSPARC T2+: For Wire-speed Security
  27. 27. RSA Performance on Oracle Sun CMT Oracle Weblogic SSL Performance on Sun CMT Servers
  28. 28. Using PIV Cards in Sun Ray Environment
  29. 29. <Insert Picture Here> Q&A Ramesh Nagappan