« "The eBay Motor Parts compatibility" - An opportunity worth looking into | Main | Blogging for Brands: Bartending with Information »

How to deal with the fast approaching Open Identity!

A User Who Came in From the cloud: How to Deal with the Fast-Approaching Open Identity Paradigms.  Best Practices for Relying Parties.  Farhang Kassaei Web

Problem: Managing Digital Identity
  •   We have too many accounts with too many passwords.  This is too difficult to manage for users, and its costly to secure for service providers.  Its insecure, tought to use and expensive.  Makes you think why we did this to begin with.
  • This is also a problem for businesses (e.g. eBay Sellers), who use multiple applications such as:  Market research, Ordering and SCM, Marketing, Promotions, Pre Sales, Inventory, CRM, etc.

Solution: Federated Identity

  •     What does Federated Identity mean?  Outsource the management of identities and their attributes to someone else.  This someone else has to be trustworthy, reliable (operational worth), complimentary to your business and not a competitor.  This someone else is the Identity provider, you are the relying party, and your customers are the consumers.

Gerneral Architecture Model - oAuth, Facebook Connect, OpenID

  •   Your consumer goes to your federated sign in page, and your app asks the consumer, which Identity Provider to use (eg Paypal, eBay, Facebook, etc).  The IDP provides an authorization token, which allows your consumer to consume the pages that are in your app.

Relying Party Best Practices

  •   Choose the right Identity Provider.  They should be business worthy, operational worthy, trustworthy.  The criteria includes type of identity, and profile data.  Quality of Idenityt profile data, Assurance level for Identity data.
  •   Contain the IDP Token.  Create your own STS and make that the "currency of the land".  Don't expose all of your services with the IDP.
  •   Understand the Protocol.  Do you need a prior relationship to register with the IDP?  Can you request extended attributes?  Can you make "back channel" calls in User Not Present mode?  Do you need to register a call back URL?  Do you need to exchange secretes with the IDP?  Do you need to run IDP code on your servers?
  •   Decide what you are relying on the IDP for.  Registration pre-fill.  Complimentary Identity Provider.  Exclusive Identity Provider.  Checkout and Transaction identity.  Confirmation, Assurance Reputation, Credit Decision.  Low consequence actvities like blog posts, etc.
  •   Link Accounts and give user control. In your account section, let people view thier primary identity provider, change it if they need to.
  •   Manage Session Properly.  Respect IDP's advice about token expiration.  Create your own session, do not reuse IDP session.  Protect IDP's token, do not put i in a cookie.  Implement a log out and report it to the IDP.

What happens when the user forgets their password?

  •   If users forget their password and cannot retrieve it with the IDP, should they be locked out of your service?  You should capture and manage one or more local secretes (eg. Secrete Questions etc)  Allow users to unlink the old IDP account from local accoutn and/or link with new ones.

The size of the federation Matters.

  •   What does this mean?  Let's say the user is logged into your application, now, and on the user's behalf, your app needs to:
  1. Access eBay API to create a listing.
  2. Paypal API later to get reports or issue refund
  3. FaceBook API to add it to users fan page
  4. Supply Chain Service they use to order more.

June 10, 2010 in Developer Community, Developer Education, Developer Website, Developers Conference | Permalink