An assertion or three about Assertions
20
An assertion or An assertion or three about three about Assertions Assertions John Bradley John Bradley [email protected] http://thread-safe.net http://thread-safe.net http://test-id.org http://test-id.org
description
An assertion or three about Assertions. John Bradley [email protected] http://thread-safe.net http://test-id.org. ICAM Approved Schemes. One Old Favourite SAML 2.0 Two New options IMI 1.0 (Information Cards) openID 2.0. Information Card (IMI). IMI 1.0 is an OASIS Standard - PowerPoint PPT Presentation
Transcript of An assertion or three about Assertions
An assertion or three An assertion or three about Assertions about Assertions John BradleyJohn Bradley
http://thread-safe.nethttp://thread-safe.net
http://test-id.orghttp://test-id.org
ICAM Approved ICAM Approved SchemesSchemes
One Old FavouriteOne Old Favourite
SAML 2.0SAML 2.0
Two New options Two New options
IMI 1.0 (Information Cards)IMI 1.0 (Information Cards)
openID 2.0openID 2.0
Information Card (IMI)Information Card (IMI)
IMI 1.0 is an OASIS StandardIMI 1.0 is an OASIS Standard
Profile of WS-FederationProfile of WS-Federation
Requires a browser extensionRequires a browser extension
Profile for LoA 1 - 3Profile for LoA 1 - 3
http://www.idmanagement.gov/documents/http://www.idmanagement.gov/documents/ICAM_IMI_10_Profile.pdfICAM_IMI_10_Profile.pdf
IMI ProfileIMI Profile
Token typeToken type
SAML 1.1 (SAML 2.0 and Zero Knowledge will be added later) SAML 1.1 (SAML 2.0 and Zero Knowledge will be added later)
IdP issued tokens only. (Self issued p-card tokens will be a separate IdP issued tokens only. (Self issued p-card tokens will be a separate profile)profile)
Card AuthenticationCard Authentication
Username/PasswordUsername/Password
X.509 (Includes PIV and CAC Cards)X.509 (Includes PIV and CAC Cards)
Personal CardPersonal Card
Kerberos token Kerberos token
Private Personal IdentifierPrivate Personal Identifier
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifierprivatepersonalidentifier
LoA ClaimsLoA Claims
http://idmanagement.gov/icam/2009/09/http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel1imi_1.0_profile#assuranclevel1
http://idmanagement.gov/icam/2009/09/http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel2imi_1.0_profile#assuranclevel2
http://idmanagement.gov/icam/2009/09/http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel3imi_1.0_profile#assuranclevel3
Audience RestrictionAudience Restriction
RP must be a SSL protected endpointRP must be a SSL protected endpoint
The SAML token is audience restricted and encrypted with the The SAML token is audience restricted and encrypted with the public key of the RP by the issuer.public key of the RP by the issuer.
7
Service Provider Requests Identity
CardSpace Identity Selector pops up
Token is built by Identity Selector(with Identity Provider)
Token sent to clientOutput sent to client
The IMI logon process
User ExperienceUser Experience
No WAYFNo WAYF
The RP expresses a Authorization Policy in the The RP expresses a Authorization Policy in the page markuppage markup
A smart client matches the policy against A smart client matches the policy against available credentialsavailable credentials
The Client remembers what credentials the The Client remembers what credentials the user has presented in the past.user has presented in the past.
openIDopenID
openID 2.0 is a openID Foindation (OIDF) specopenID 2.0 is a openID Foindation (OIDF) spec
openID discovery XRDS is a OASIS XRI-TC specopenID discovery XRDS is a OASIS XRI-TC spec
Profile for LoA 1Profile for LoA 1
http://www.idmanagement.gov/documents/http://www.idmanagement.gov/documents/ICAM_OpenID20Profile.pdfICAM_OpenID20Profile.pdf
The OpenID login The OpenID login processprocess
OpenID Profile OpenID Profile mitigationsmitigations
Assertion reuseAssertion reuse
Assertions include a timestamp and a nonce which is checked by Assertions include a timestamp and a nonce which is checked by the RP. The RP keeps track of assertions that were consumed the RP. The RP keeps track of assertions that were consumed
Assertion manufacture/modificationAssertion manufacture/modification
IdPs digitally sign assertion, or assertion is transmitted over TLS/SSL IdPs digitally sign assertion, or assertion is transmitted over TLS/SSL where the RP authenticates the IdP via a HMAC shared secret.where the RP authenticates the IdP via a HMAC shared secret.
Assertion redirectAssertion redirect
The signed assertion includes the identity (return_to) of the RP for The signed assertion includes the identity (return_to) of the RP for whom it was generated, and the RP verifies it.whom it was generated, and the RP verifies it.
IdentifiersIdentifiers
Must be Pair-wise Pseudonymous by RPMust be Pair-wise Pseudonymous by RP
The pseudonym is used to identify the user The pseudonym is used to identify the user to the RP in a way that protects the user's to the RP in a way that protects the user's privacy by preventing correlation among RPs. privacy by preventing correlation among RPs. The RP is identified by its realm. The RP is identified by its realm.
Must use Directed identity.Must use Directed identity.
AssociationsAssociations
Must be over SSLMust be over SSL
Should be HMAC-SHA256 Should be HMAC-SHA256
The IdP shall expire associations older than The IdP shall expire associations older than 24h24h
The IdP shall not reuse associations between The IdP shall not reuse associations between RPsRPs
The RP must key association handles by IdPThe RP must key association handles by IdP
OpenID Provider OpenID Provider Authentication Policy Authentication Policy (PAPE)(PAPE)
Authentication PoliciesAuthentication Policies
Used by RPs to request aspects of a profileUsed by RPs to request aspects of a profile
http://schemas.xmlsoap.org/ws/2005/05/http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifieridentity/claims/privatepersonalidentifier
Maximum Authentication AgeMaximum Authentication Age
Used to guarantee a fresh interactive login.Used to guarantee a fresh interactive login.
Relying Party DiscoveryRelying Party Discovery
The RP MUST publish an eXtensible Resource Descriptor The RP MUST publish an eXtensible Resource Descriptor Sequence (XRDS) discovery document for its realm per [OpenID Sequence (XRDS) discovery document for its realm per [OpenID 2.0] Section 13. 2.0] Section 13.
The XRDS MUST be published at the URL matching the realm.The XRDS MUST be published at the URL matching the realm.
The URI for the XRDS document that is discovered via Yadis The URI for the XRDS document that is discovered via Yadis MUST have an https: scheme.MUST have an https: scheme.
The IdP MUST perform RP discovery and return_to validation per The IdP MUST perform RP discovery and return_to validation per [OpenID 2.0] Section 9.2.1. [OpenID 2.0] Section 9.2.1.
If return_to validation fails, the IdP MUST return an error, or the IdP If return_to validation fails, the IdP MUST return an error, or the IdP MAY present an error message and discontinue the OpenID MAY present an error message and discontinue the OpenID authentication process.authentication process.
Assertion VerificationAssertion VerificationThe RP MUST verify that all of the following fields The RP MUST verify that all of the following fields (without the "openid." prefix prepended) are included in (without the "openid." prefix prepended) are included in the IdP signature: op_endpoint, return_to, the IdP signature: op_endpoint, return_to, response_nonce, assoc_handle, claimed_id, and identity. response_nonce, assoc_handle, claimed_id, and identity.
All OpenID extensions MUST be signed by the IdP.All OpenID extensions MUST be signed by the IdP.
The RP MUST check the openid.response_nonce to make The RP MUST check the openid.response_nonce to make sure that an assertion from the IdP with this nonce has sure that an assertion from the IdP with this nonce has not already been used. not already been used.
It is RECOMMENDED that the RP set a restriction on the It is RECOMMENDED that the RP set a restriction on the amount of elapsed time from the timestamp in the amount of elapsed time from the timestamp in the nonce until receipt.nonce until receipt.
The RP MUST check the return_to value in the assertion The RP MUST check the return_to value in the assertion to verify that the assertion was produced for the RP.to verify that the assertion was produced for the RP.
Assertion VerificationAssertion Verification
The openid.identity and openid.claimed_id The openid.identity and openid.claimed_id MUST be the same with the exception of a MUST be the same with the exception of a fragment that may be appended to the fragment that may be appended to the openid.claimed_id. openid.claimed_id.
The RP MAY use "Direct Verification" to validate The RP MAY use "Direct Verification" to validate the assertion when:the assertion when:
1.1.The IdP includes an openid.invalidate_handle The IdP includes an openid.invalidate_handle indicating that the association has expired.indicating that the association has expired.
2.2.The IdP sends an unsolicited assertion The IdP sends an unsolicited assertion
Security ConsiderationsSecurity ConsiderationsTLS/SSLv3 MUST be used at all endpoints, discovery TLS/SSLv3 MUST be used at all endpoints, discovery redirects, and the URI of the XRDS document.redirects, and the URI of the XRDS document.
The RP SHOULD negotiate a cipher suite that includes either The RP SHOULD negotiate a cipher suite that includes either Triple Data Encryption Standard (3DES) or Advanced Triple Data Encryption Standard (3DES) or Advanced Encryption Standard (AES) during the SSL/TSL handshake. Encryption Standard (AES) during the SSL/TSL handshake.
NIST encourages use of the faster and stronger AES algorithm.NIST encourages use of the faster and stronger AES algorithm.
The RP MUST verify that the IdP is authorized LOA 1 IdP The RP MUST verify that the IdP is authorized LOA 1 IdP through verification of URL endpoints and server certificates through verification of URL endpoints and server certificates during discovery and Direct Communication (see [OpenID during discovery and Direct Communication (see [OpenID 2.0] Section 5.1).2.0] Section 5.1).
During Direct Communication, the RP MUST check the During Direct Communication, the RP MUST check the revocation status of the IdP server certificate.revocation status of the IdP server certificate.
Security ConsiderationsSecurity Considerations
The RP and IdP SHOULD employ frame busting The RP and IdP SHOULD employ frame busting techniques to avoid possible eavesdropping by techniques to avoid possible eavesdropping by a third-party web site, and cross site request a third-party web site, and cross site request forgery.forgery.
The RP MUST reject any assertion where The RP MUST reject any assertion where openid.ns is other than openid.ns is other than http://specs.openid.net/auth/2.0http://specs.openid.net/auth/2.0. .
