icam (identity, credential and access management)-openid 2.0 profile
Post on 08-Jun-2015
307 Views
Preview:
TRANSCRIPT
OpenID 2.0
Profile
Ayesha KanwalMS-CCS-42011-NUST-MS-CCS-10
OpenID 2.0
Profile
Background
0 U.S. federal government initiative to merge the management of digital identities, credentials and access control into one comprehensive management approach.
0 Office of Management and Budget (OMB) issued E-Authentication Guidance for Federal Agencies.
Level 1 Level 2 Level 3 Level 4
0 General Services Administration’s (GSA) Office of Government wide Policy (OGP) is responsible for government-wide coordination and oversight of Federal Identity, Credential, and Access Management (ICAM).
0 ICAM Identity Scheme Adoption Process includes the assessment of scheme for compliance with [NIST SP 800-63] and other privacy and security requirements.
OpenID Overview0 It facilitate Portable identity through the most open set of
specifications and technologies possible.
0 The OpenID Authentication 2.0 specification is the core of the OpenID protocol.
0 The usual portable identity model includes three main actors: User, Identity provider and Relaying party
OpenID 2.0 Adopted by ICAM
0 OpenID 2.0 has completed the scheme adoption process and has been adopted by ICAM for the purpose of Level of Assurance (LOA) 1 identity authentication (i.e., conducting low risk transactions with the Federal government).
Use Case 1
Use Case 2
Features
0 Single Sign-On
0 Reduced Sign-on
0 Session Reset
0 Attribute Exchange
0 Authentication Policy
0 Pseudonymous Identifiers
Security
0 SSL/TLS is used to positively identify one another during all direct communication ( IdP & RP).
0 The RP verifies that the IdP is an ICAM-authorized LOA 1 IdP.
0 An RP and IdP establish a Hash Message Authentication Code (HMAC) secret and a reference to the HMAC called an Association Handle.
1) Digital signature 2) Request/response Verification
End User Activation
0 The first time an end user authenticates to an RP via assertion, the RP must perform end user activation.
0 End user activation is the process an RP uses to associate a new or existing local identity record with the end user's identifier from the IdP.
1) Existing Account Linking 2) New Account Provisioning
High-level Programmed Trust Process Flow
TECHNICAL PROFILE
Federal ICAM
Profile for the
OpenID 2.0
specification
Directed Identity
0 End users MUST select an ICAM-approved Identity Provider (IdP) from a list provided by the Relying Party (RP).
0 The RP MUST only discover the OpenID Provider (OP) Identifier Element for initial discovery.
Association Handles
0 The RP SHOULD request an association type of HMAC-SHA256.
0 The IdP SHALL set the expires_in value for an association.
0 The IdP SHALL NOT reuse the HMAC secret across association handles.
0 To avoid association poisoning the OP Endpoint Uniform Resource Locator (URL) is used.
Provider Authentication Policy Extension (PAPE) Request
0 IdP MUST generate a pseudonymous identifier for the end user http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier
0 IdP is an ICAM-authorized LOA 1 IdP http://www.idmanagement.gov/schema/2009/05/icam/openid-trust-level1.pdf
0 the IdP MUST NOT include any PII in the response http://www.idmanagement.gov/documents/no-pii.pdf
Positive Assertion Formulation
0PAPE Response
0Private Personal Identifiers
0Simple Registration and Attribute Exchange
PAPE Response
0 A positive assertion MUST contain a PAPE 1.0 response that addresses the requested PAPE 1.0 authentication policies
Private Personal Identifiers
0 The pseudonym is used to identify the end user to the RP in a way that protects the end user's privacy by preventing propagation of the end user's common identifier throughout the Federal Government.
0 This Private Personal Identifier (PPID) SHALL be expressed in both the openid.identity and openid.claimed_identity fields within positive assertions about the end user.
0 The IdP MUST construct a pseudonym in a way that ensures that it cannot be reverse engineered to help identify an end user across multiple realms.
Simple Registration and Attribute Exchange
0 The assertion MUST NOT include any end user PII (i.e., AX and SREG) unless the RP specifically requests the attribute(s).
0 The IdP MAY implement a mechanism for the end user to opt in to always sending the listed attributes to the specific RP for subsequent transactions.
Positive assertion verification
0 The RP MUST verify that all of the following fields are included in the IdP signature: op_endpoint, return_to, response_nonce, assoc_handle, claimed_id, and identity.
0 The RP MUST check the openid.response_nonce and return_to.
Unsolicited Positive Assertions
0 RP MAY accept the unsolicited response if it is an ICAM-authorized LOA 1 IdP.
0 The RP MUST reject an unsolicited assertion that does not contain the following PAPE 1.0 authentication policies
0 The RP MUST reject an unsolicited assertion if it contains PII that it would not otherwise request or is not authorized to accept.
Relying Party Discovery
0 The RP MUST publish an eXtensible Resource Descriptor Sequence (XRDS) discovery document.
0 The IdP MUST perform RP discovery and return_to validation.
Thank you
top related