• Save
UserCentric Identity based Service Invocation
Upcoming SlideShare
Loading in...5
×
 

UserCentric Identity based Service Invocation

on

  • 4,940 views

From XTech 2008 conference in Dublin

From XTech 2008 conference in Dublin

Statistics

Views

Total Views
4,940
Views on SlideShare
4,802
Embed Views
138

Actions

Likes
6
Downloads
0
Comments
0

3 Embeds 138

http://dev.aol.com 128
http://www.slideshare.net 9
http://74.125.93.104 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • With the growing acceptance of OpenID across the web as a simple and easy way to exchange Online Identities, now is the time to look at how the new protocol OAuth helps in doing Identity based Service Invocations to help in building useful Web 2.0 applications (including Widgets and Gadgets for Social Networks) all under user’s control. This session introduces the OAuth protocol and how it can be used in various use cases. While doing so we will cover how it fits into the existing deployments with OpenID and possibly, other Authentication protocols as well. We will also discuss how OAuth fits into the two most common models where both User Identity and Services are managed by the same Provider or by different Providers. This of course opens up lot of questions about how OAuth and OpenID would work with each other and how the user’s permissions are managed. We will also look at how easy it is to add OAuth support into an existing Service using AOL’s WebAIM Service as an example.

UserCentric Identity based Service Invocation UserCentric Identity based Service Invocation Presentation Transcript

  • ‘ User-Centric Identity’ based Service Invocation America Online LLC Praveen Alavilli XTech 2008 (Dublin)
  • Mashups, Gadgets, Widgets, Social Networks, Social Graphs, …..
    • no longer just about
      • presenting content/feeds from multiple places
      • the user and his/her friends
    • it’s also about
      • how users can use multiple services together
      • the global mapping of everybody and how they are related
    • Opening up a lot of questions about Data Portability .
  • Service Invocation
    • Actions that a client/user-agent performs to use a Web Service / API
    • Several definitions when it’s related to a user
      • ‘ Deputization’ of services
      • ‘ Delegation’ of actions (act on behalf of a user)
  • Identity still at the ‘core’
    • So the users can
      • control the flow of their data/information
      • authorize access to their information
      • personalize applications/data
      • communicate
      • publish content online
    • Call it User-Centric or User-Centered :-)
  • User-Centric Identity
    • Open, Community driven and standards based
      • OpenID
        • No support for Service Invocation
      • InfoCard (CardSpace)
        • No direct support for Service Invocation (although you can define a security token as another claim)
      • SAML
      • Liberty ID-WSF
      • WS-*
        • Too heavy for browser based apps and designed mainly for XML based Web Services (SOAP)
        • Complex message formats and protocols for developers and browser based apps
  • Proprietary Protocols
    • AOL OpenAuth
    • Yahoo! BBAuth
    • Google Account Auth API (AuthSub)
    • Windows Live ID
    • All support service invocation with user’s consent (authorization) across all their Open Services but ….
      • Different ways to obtain user consent/permission
      • Different user experience
      • Different protocols, message formats and parameter names
        • Each defines it’s own: URL format, Parameters naming convention, Response specification, and Status Codes
      • Lack of consistent model for rich clients (like Flash/Flex Apps, desktop clients) and browser based apps
  • AOL Open Services http://dev.aol.com
  • AOL OpenAuth and Open Services Untrusted Site (ex. netvibes.com) User (Browser) 1. Access protected content 2. Redirect to OpenAuth 3. login 4. Login page 5. sn/pwd 6. Redirect to site w/ token 7. Redirect to site w/ token 8. Get buddylist W/ token 9. Validate token 10. Return buddy list AIM Service 11. Return Personalized content
  • AOL OpenAuth and Open Services
  • AOL OpenAuth and Open Services
  • Yahoo! Open APIs/Services http://developer.yahoo.com
  • Yahoo! BBAuth
  • Yahoo! BBAuth
  • Yahoo! BBAuth
  • Google Open APIs/Services (GData) http://code. google .com/more/
  • Google AuthSub
  • Google AuthSub
  • And the list goes on… Source: http://programmableweb.com/apis
  • What do we need ?
    • A open standard for Service Invocation that’s
      • authentication method agnostic
      • easy for users to understand
      • provide Security and Privacy where ever appropriate
      • consistent and easy to implement for developers
      • open source code libraries
      • open and community driven specification
  • OAuth (Oh! Auth)
    • An Open protocol to allow Secure API Authentication in a simple and standard method from desktop and web applications.
  • What it’s Not ?
    • User Authentication Protocol
    • Token specification
    • Web/Client SSO Protocol
    • Part of OpenID spec nor an extension
    • Consumer Key (developer key) and Secret provisioning protocol
  • What it really provides ?
    • A simple and easy way to request user’s authorization , and a consistent way to access services on behalf of the user (service invocation).
    • Analogous to AOL/Yahoo/Google/…. Open Service protocols but Authentication is left out of scope intentionally !
  • OAuth protocol
    • Defines 3 request URLs:
      • Request Token URL
        • to obtain unauthorized token
      • User Authorization URL
        • to obtain user authorization for consumer access
      • Access Token URL
        • to exchange user-authorized token with an access token
    • + an easy to extend framework (guidelines) to suit your needs
  • OAuth Parameters
    • oauth_consumer_key
    • oauth_consumer_secret
    • oauth_token
    • oauth_token_secret
    • oauth_signature
    • oauth_signature_method
    • oauth_timestamp
    • oauth_nonce
    • oauth_version
    • oauth_callback
    • **Service Providers can add additional request parameters as per their needs but they MUST NOT begin with “oauth_” **
  • Where are they passed ?
    • URL Query Parameters
    • HTTP POST request body (as form params)
    • HTTP Authorization Header (most preferred way)
  • Request Signing
    • All token requests and protected resources requests MUST be signed to prevent token misuse.
    • OAuth does not mandate a particular signature method (HMAC-SHA1, RSA-SHA1, etc.) but it does define how you construct Signature Base String.
    • Signature Base String = HTTP Request Method + ‘&’ + request URL + ‘&’ + Normalized Request Parameters
    • Signing Key = oauth_consumer_secret + “&” + oauth_token_secret
  • Various use-cases still being worked on !
    • Auto discovery of OAuth end points and auto-provisioning
    • User - Gadget - Container - Service Provider interactions (for Gadget/Widget containers like Netvibes, iGoogle, etc.)
    • Consumer using a Service Provider that provides multiple resources
    • Consumer using Multiple Service Providers using same IDP
    • Consumer using a Service Provider outsourcing Identity to some one other IDP using OpenID/InfoCard/etc.
    • Consumer - Service Provider Transactions with no User (two-legged scenario)
    • Security related - session extension, additional/expired authorizations, token revocation, etc..
    • Out of band Authorization
  • Extensions in draft mode
    • Error Reporting Extension
    • RSA Key Rotation Extension
    • Gadgets Extension
    • Session Extension
    • Language Preference Extension
    • Consumer Request Extension for two-legged scenarios
    • Multi-Resource Authorization Extension
  • OAuth Discovery Extension
    • Provides a way for discovering the Service Providers using a XRDS Document
      • to indicate where it’s end points are, and
      • how to obtain required configuration data
  • Sample XRDS Document
    • <!-- Request Token -->
    • <Service>
    • <Type>http://oauth.net/core/1.0/endpoint/request</Type>
    • <Type>http://oauth.net/core/1.0/parameters/auth-header</Type>
    • <Type>http://oauth.net/core/1.0/parameters/post-body</Type>
    • <Type>http://oauth.net/core/1.0/parameters/uri-query</Type>
    • <Type>http://oauth.net/core/1.0/signature/HMAC-SHA1</Type> <URI>https://api.screenname.aol.com/auth/oauth_request_token</URI>
    • </Service>
    • <!-- User Authorization -->
    • … .
    • <!-- Access Token -->
    • … .
    • <!-- Protected Resources -->
    • <Service>
    • <Type>http://oauth.net/core/1.0/endpoint/resource</Type>
    • <Type>http://oauth.net/core/1.0/parameters/auth-header</Type>
    • <Type>http://oauth.net/core/1.0/parameters/post-body</Type>
    • <Type>http://oauth.net/core/1.0/parameters/uri-query</Type>
    • <Type>http://oauth.net/core/1.0/signature/HMAC-SHA1</Type>
    • </Service>
    • <!-- Consumer Identity -->
    • <!-- Manual Consumer Identity Allocation -->
    • <Service>
    • <Type>http://oauth.net/discovery/1.0/consumer-identity/oob</Type>
    • <URI>https://dev.aol.com/keys</URI>
    • </Service>
  • How does OAuth fit in your existing deployments ?
  • Deployment Models
    • SP has Central IDP
      • OAuth endpoints handled by IDP
      • OAuth endpoints handled by SP
    • SP is IDP
      • Oauth endpoints handled by SP
    • SP with no IDP
      • Using OpenID or InfoCard or any other Protocol
  • Central IDP Model - 1
      • OAuth
      • endpoints
      • handled by
      • IDP.
      • SP OAuth
      • Discovery
      • Document
      • returns
      • endpoints as
      • IDP Urls.
  • Central IDP Model - 2
      • OAuth
      • endpoints
      • handled by
      • SP
      • Example:
      • A simple
      • OAuth Proxy
      • Sevlet that
      • routes all
      • requests to
      • IDP internally.
  • SP is IDP
      • OAuth
      • endpoints
      • handled by
      • SP
  • SP with no IDP
      • OAuth
      • endpoints
      • handled by
      • SP but
      • Authentication
      • handled by
      • OpenID (or
      • InfoCard, or
      • any other
      • mechanism)
  • Supporting OAuth in existing Services
    • Sample WebAIM call: (http://dev.aol.com/webaim/)
      • http://api.oscar.aol.com/aim/startSession? f=xml&events=myinfo,presence,buddylist & a =<token>& k = co1dDRMvlgZJXvWK
    • OAuth enabled:
      • http://api.oscar.aol.com/aim/startSession?oauth_consumer_key=co1dDRMvlgZJXvWK&oauth_token=<token>&oauth_signature_method=HMAC-SHA1&oauth_signature=<signature>&oauth_nonce=<nonce>&oauth_timestamp=1191232096&f=xml&events=myinfo,presence,buddylist
      • (OR)
      • http://api.oscar.aol.com/aim/startSession?f=xml&events=myinfo,presence,buddylist
        • HTTP Header: Authorization: OAuth realm=&quot;http://api.oscar.aol.com/&quot;,
          • oauth_consumer_key=&quot; co1dDRMvlgZJXvWK &quot;,
          • oauth_token=“<token>&quot;,
          • oauth_signature_method=&quot;HMAC-SHA1&quot;,
          • oauth_signature=”<signature>&quot;,
          • oauth_timestamp=&quot; 1191232096 &quot;,
          • oauth_nonce=”<nonce>&quot;,
          • oauth_version=&quot;1.0&quot;
  • If you are still wondering ‘why is it useful ?’ …
    • For End users
    • Security
      • All requests are signed
      • Nonce & timestamp for stopping replay attacks
      • User login credentials are not exposed
      • Tokens can be revoked (if supported by IDP) to stop a malicious Consumer from having continuous access to protected resources
    • Privacy
      • Consumer authorization under user’s control
      • User information not shared with Consumers
    • User Experience
      • Consistent Login experience
      • Easy to understand authorization process
      • Control on information/data access
  • For Developers and Service Providers
    • Developers
      • Consistent APIs across different Service Providers for passing Identity Information
      • No need to worry about managing Identities and Authentication
      • Platform/OS independent
      • Simple Protocol and Message format
    • Service Providers
      • Easy way to increase adoption of their Services
      • Provides security and privacy of their users
      • One Consistent and Simple API to maintain for both Rich Clients and Browser Based Apps.
  • Questions/Comments
    • Reference Sites:
    • OAuth: http://oauth.net
    • OAuth Group: http://groups. google .com/group/ oauth
    • OAuth Extensions: http://groups.google.com/group/oauth-extensions
    • OAuth Code: http:// oauth .net/code/
    • AOL OpenAuth: http://dev.aol.com/openauth
    • Contact Info:
    • Praveen Alavilli
    • AlavilliPraveen @aol.com
    • http://dev.aol.com/blog/82