1 / 20

openID & Information Card Profiles for ICAM

openID & Information Card Profiles for ICAM. John Bradley jbradley@mac.com http://thread-safe.net http://test-id.org. Information Card (IMI). IMI 1.0 is an OASIS Standard Profile of WS-Federation Requires a browser extension Profile for LoA 1 - 3

Download Presentation

openID & Information Card Profiles for ICAM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. openID & Information Card Profiles for ICAM • John Bradley • jbradley@mac.com • http://thread-safe.net • http://test-id.org

  2. Information Card (IMI) • IMI 1.0 is an OASIS Standard • Profile of WS-Federation • Requires a browser extension • Profile for LoA 1 - 3 • http://www.idmanagement.gov/documents/ICAM_IMI_10_Profile.pdf

  3. openID • openID 2.0 is a openID Foindation (OIDF) spec • openID discovery XRDS is a OASIS XRI-TC spec • Profile for LoA 1 • http://www.idmanagement.gov/documents/ICAM_OpenID20Profile.pdf

  4. Out of Scope • Verification of assertion attributes

  5. IMI Profile • Token type • 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 profile) • Audience Restriction • RP must be a SSL protected endpoint • The SAML token is audience restricted and encrypted with the public key of the RP by the issuer.

  6. Private Personal Identifier • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier • LoA Claims • http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel1 • http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel2 • http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel3 • Card Authentication • Username/Password • X.509 • Personal Card • Kerberos token

  7. OpenID Profile mitigations • Assertion reuse • Assertions include a timestamp and a nonce which is checked by the RP. The RP keeps track of assertions that were consumed • Assertion manufacture/modification • IdPs digitally sign assertion, or assertion is transmitted over TLS/SSL where the RP authenticates the IdP via a HMAC shared secret. • Assertion redirect • The signed assertion includes the identity (return_to) of the RP for whom it was generated, and the RP verifies it.

  8. Identifiers • Must be Pair-wise Pseudonymous by RP • The pseudonym is used to identify the user to the RP in a way that protects the user's privacy by preventing correlation among RPs. The RP is identified by its realm. • Must use Directed identity.

  9. Associations • Must be over SSL • Should be HMAC-SHA256 • The IdP shall expire associations older than 24h • The IdP shall not reuse associations between RPs • The RP must key association handles by IdP

  10. OpenID Provider Authentication Policy (PAPE) • Authentication Policies • Used by RPs to request aspects of a profile • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier • Maximum Authentication Age • Used to guarantee a fresh interactive login.

  11. Relying Party Discovery • The RP MUST publish an eXtensible Resource Descriptor Sequence (XRDS) discovery document for its realm per [OpenID 2.0] Section 13. • The XRDS MUST be published at the URL matching the realm. • The URI for the XRDS document that is discovered via Yadis MUST have an https: scheme. • The IdP MUST perform RP discovery and return_to validation per [OpenID 2.0] Section 9.2.1. • If return_to validation fails, the IdP MUST return an error, or the IdP MAY present an error message and discontinue the OpenID authentication process.

  12. Assertion Verification • The RP MUST verify that all of the following fields (without the "openid." prefix prepended) are included in the IdP signature: op_endpoint, return_to, response_nonce, assoc_handle, claimed_id, and identity. • All OpenID extensions MUST be signed by the IdP. • The RP MUST check the openid.response_nonce to make sure that an assertion from the IdP with this nonce has not already been used. • It is RECOMMENDED that the RP set a restriction on the amount of elapsed time from the timestamp in the nonce until receipt. • The RP MUST check the return_to value in the assertion to verify that the assertion was produced for the RP.

  13. Assertion Verification • The openid.identity and openid.claimed_id MUST be the same with the exception of a fragment that may be appended to the openid.claimed_id. • The RP MAY use "Direct Verification" to validate the assertion when: • The IdP includes an openid.invalidate_handle indicating that the association has expired. • The IdP sends an unsolicited assertion

  14. Security Considerations • TLS/SSLv3 MUST be used at all endpoints, discovery redirects, and the URI of the XRDS document. • The RP SHOULD negotiate a cipher suite that includes either Triple Data Encryption Standard (3DES) or Advanced Encryption Standard (AES) during the SSL/TSL handshake. • NIST encourages use of the faster and stronger AES algorithm. • The RP MUST verify that the IdP is authorized LOA 1 IdP through verification of URL endpoints and server certificates during discovery and Direct Communication (see [OpenID 2.0] Section 5.1). • During Direct Communication, the RP MUST check the revocation status of the IdP server certificate.

  15. Security Considerations • The RP and IdP SHOULD employ frame busting techniques to avoid possible eavesdropping by a third-party web site, and cross site request forgery. • The RP MUST reject any assertion where openid.ns is other than http://specs.openid.net/auth/2.0.

  16. Questions? jbradley@mac.com

  17. openID history • May 2005 invented by Brad Fitzpatric at SixApart (LiveJournal) • Oct 2005 XRDS • March 2006 Simple Registration 1.0 (JainRain) • May 2006 openID 1.1 • Dec 2007 openID 2.0 and Atribute Exchange 1.0

  18. openID Providers • Google • Yahoo • AOL • MySpace • PayPal • JanRain • Orange (France Telecom) • Facebook (soon)

  19. openID Relying Partys • FaceBook • MapQuest (AOL) • Plaxo • Blogger (Google) • TypePad (Six Apart)

More Related