The userwhocameinfromthecloud devcon2010-v_5

The User Who Came In From the Cloud

Best Practices for Relying Parties

Farhang Kassaei, Marketplaces Architecturehttp://SoftwareForAllSeasons.blogspot.com

Share, reuse, and remix this talk

This presentation is available under Creative

Commons Attribution-Noncommercial-Share Alike 3.0

You can share this information with others.

Don’t forget to tag it eBay DevCon 2010.

© 2010, eBay Inc. Some rights reserved.

eBay and the eBay logo are among the registered trademarks of eBay Inc.

Other trademarks and brands are the property of their respective owners.

What is to come

• Problem: Managing Digital Identity

• Solution: Federated Identity

• General Architecture Model

• oAuth, Facebook Connect, OpenID

• Relying Party Best Practices

• Closing Thoughts

Audience Profile

• Single Sign On (SSO)

• OpenID

• OAuth

• Facebook Connect

• Google Friend Connect

• WRAP

• The NASCAR Problem

• SAML and SAML Profiles

• Intergalactic Federation of Sovereign Planets (IFSP)

• Open eBay

The Problem - Managing Digital Identity (the famous version)

• Too many accounts

• Too many passwords

• Too difficult to manage for users

• Insecure, Tough to use, Expensive

• Makes you think why we did this to begin with

• Too costly to secure for service providers

• At least gives user some control

• But …

• And does not have big brother perception

• Businesses (e.g. eBay Sellers) have the same problem.

• They use multiple applications (that you write)–Market Research

–Ordering and SCM

–Marketing

–Promotions

–Pre Sales

–Inventory

–CRM

–Label Printing

–Returns and Claims

–Accounting

• Not only set up, but manage permissions and roles in each

application.

• Consolidated Reporting, Auditing, Managing Change.

The Problem - Managing Digital Identity (the less famous version)

The Solution – Federated Identity

• Do not let the name scare you.

• Outsource the management of identities and their

attributes to someone else

• Let’s call “some one else” an Identity Provider (IDP)

• And you are, naturally, Relying Party

• Trustworthy• Reliable (operational worthy)

• Complementary not a competitor (Business Worthy)

• Someone you can … well …Rely On.

• The Identity being managed is called Consumer.

What is up with “Federation”?

•Federated Entity is an entity made up of parts provided but

multiple sources.

• Federated Identity is an identity made up of assertions

provided multiple sources, well, at least two.

• IDP provides unique identifier, authentication assertions,

optionally email, picture etc., you provide the rest perhaps

credit card number, user segment etc.

• Notice that Identity != Identifier

• The two sources are the IDP and You (maybe more)

General Architectural Model

Paypal

Facebook

eBayFed.

SignIn

STS

Primary IDPs

Service Providers

G G G

1

2

3

4

5

6

8

7

6

6

4

3

3

2PayPalFed.

SignIn

STSG G G

Service Providers

1

5

General Architectural Model

BrowserBrowser

Browser

RP Best Practices & Major Considerations

Choose The Right IDP

– Type of Identity and profile data.

– Quality (accuracy, freshness) of Identity profile data

– Assurance level for Identity data

• BOT Worthy

– Protocol Sophistication

• Business worthy, Operational worthy, Trustworthy

– *abilities (reliability, scalability, etc.)

Contain the IDP token

• Create your own STS and make that the

“currency of the land”

• Do not expose all of your services or commands

to IDP token.

• Consider cases where you should handle multiple

IDPs – how much change do you need to make?

Understand The Protocol

• Do you need prior relationship (register) with IDP?

• Does IDP support Force Authentication?

• Can you Request extended attributes?

• Do you need to exchange secrets with IDP? Do

you need to run IDP code on your servers?

• Do you need to register your call back URLs?

• Can you make “back channel” calls with in UNP

(User Not Present) mode.

• Does IDP generates events (e.g. profile data change)

Re-design your Sign-In Page Properly

• Avoid the NASCAR Problem

• Do not confuse existing users or users who do not user

external IDP

• Let user know what to expect

– It is secure

– It will require authorization from them

– Their privacy is respected

Decide what you are Relying on IDP For

• Registration pre-fill

• Complementary Identity Provider

• Exclusive Identity provider

• Check out and Transaction identity

• Confirmation, Assurance, Reputation, Credit Decision

• Low Consequence activities (blog post, comments etc.)

Link Accounts and give user control

• In your “Account” section, let people view their

primary identity provider, change it if they need to or

use another account.

• If you have information about users’ other accounts,

create a formal link and let users manage it.

• Eventually IDPs with larger federation may remove

this need, but the state of industry is far from that goal.

Manage Session Properly

• Respect IDP’s advice about the token expiration

• But you can be more conservative if you wish

• Protect IDP’s token, do not put it in a cookie

• Implement a log out and report it to IDP

• Create your own session, do not reuse IDP session.

Keeping Data Sync

• What if users change address or other information in

their profile in IDP?

• Would be great if they do not have to do it again in

your application/site as well.

• If IDP has profile change events, implement its listeners

• If IDP has back channel API, poll it via batch jobs

• If IDP allows for extended attribute, ask for them at

the start of each session and sync your data.

Forget your password?

• If users forget their password and can not retrieve it

with IDP, should they be locked out of your service?

• Capture and manage one or more local secrets (e.g.

secret questions etc.)

• Allow users to unlink the old IDP account from local

account and/or link a new IDP account to local

account.

Size of Federation Matters

• The user is logged into your application, now, and on

user’s behalf (let’s assume a seller), your app needs to

– Access eBay API to create a listing

– and PayPal API later to get reports or issue refund

– and FaceBook API to add it to users fan page

– and a Supply Chain Service they use to order more

• Would you want user to go through four more

authorization flow?

• Wouldn’t it be great if you could use the original token?

• The extent and size of federation matters!

Closing Thoughts

• The problem for business users is real

• Not all Identities are created equal

• Business Identities

• Personal Identities

• Transactional Identities

• Not all identity providers are created equal

• This is a “Winner take Most” type of a game, but perhaps

one winner for each type of identity.

• Architecturally requires RPs to model and abstract out

identity from legacy systems.

• Commercial Identities

Q&A

Farhang Kassaei, Marketplace Architecture

Email: [email protected]

Blog: SoftwareForAllSeasons.Blogspot.com

Questions?

To learn more, visitwww.ebay.com/devcon

Thank you!

Backup Slides

RP Best Practices in a Glance

1. Choose The Right IDP

2. Determine what you relying on your IDP for

3. Understand the Protocol

4. Re-Design Your Sign-In Page Properly

5. Contain IDP token

6. Link Accounts and give user control

7. Manage Session Properly

8. Keep identity profile sync with your IDP

9. What if user forget her IDP password? Provide an out.

10.Scope and Extend of Federation Matters