Identity Enabling Web Services

  • 3,675 views
Uploaded on

DIDW 08 presentation

DIDW 08 presentation

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,675
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
40
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Identity enabling Web Services Ashish Jain, Director of Technology, Ping Identity Peter Dapkus, Product Manager, Salesforce.com   Eric Sachs, Product Manager, Google Security September 10, 2008
  • 2. Agenda
      • Introduction
      • WS-Trust Overview
      • OAuth Overview
      • Enterprise to Enterprise
      • OAuth Dance
      • Consumer to SaaS
      • Enterprise to SaaS
      • Summary
      • Q&A
  • 3. Introduction
    •  
      • Server to Server Mashup
      • Enterprise SOA
      • SSO + Data
      • Desktop Client
  • 4. WS-Trust
    •   To provide a framework for requesting and issuing security tokens, and to broker trust relationships.
    •  
    •  
      • OASIS Standard
      • Solutions by Microsoft, IBM, Sun, Ping Identity...
      • Related Specs - WS-Policy, WS-SecureConversation, WS-Addressing, WS-Mex, WS-SecurityPolicy...
      • Used heavily in Information Cards
      • Current Status
  • 5. OAuth
    • An open protocol to allow secure API authentication in a simple and standard method from desktop and web applications.  
    •  
      • Open Standard. Developed by Community. (http://OAuth.net).
      • Support by Google, MySpace, Yahoo, AOL, Twitter, Pownce...
      • Lightweight. Does one thing. Very well.
      • Somewhat related specs: OpenID 
      • Current Status: V1.0 in use by Google & MySpace as well as many other sites.  Some extensions proposed, but no significant modifications to the core protocol.
  • 6. WS-Trust Continued
    •  
  • 7. Enterprise Use Cases
    •  
    •  
      • Legacy Systems - API access
      • Proprietary (especially in mergers)
      • Federal /DoD - Extending PKI
      • XML security gateway
  • 8. OAuth Continued
    •  
  • 9. The OAuth "dance"
    • Step 1: Login to site A
    • Step 2: Specify site B
    • Step 3: Agree to legal doc from site A
    •  
    • Step 4: Login to site B
    • Step 5: Agree to legal doc from site B
    • Step 6: Data exchanged in either direction
  • 10.  
  • 11.  
  • 12.  
  • 13.  
  • 14.  
  • 15.  
  • 16.  
  • 17.  
  • 18. Establishing trust for consumer SaaS
    • OAuth is becoming the de-facto solution when end users want to delegate access to their data to another website
    • Example: Personal Health Record portability
    • Example: Address Book (social data) portability
    • Example: Application extensions (photo labs)
    •  
    • End users want their OWN copy of the data enterprises & portals have about them (address books, health records, financial records, power usage records, even telephone records).
    •  
    • If you don't give it to them, they will pass laws (HIPAA).  Even if you provide private portals on your site, Web 2.0 startups will screen scrape your site.
  • 19. Personal Health Records Portability
      • MS HealthVault & Google Health provide secure storage
      • Data providers such as hospitals, labs, pharmacies get the user's authorization to transfer data to MS or Google
      • 3rd party services read the data from MS or Google to provide tools such as clinical trial matching, diabetes management tools, personalized medical news, etc.
      • In the future, hospitals might read data from MS or Google to get updates on their patients from other medical providers
  • 20. Address Book Portability
      • Signup for a Social Networks, and get asked for the password of your E-mail account.
      • OAuth provides a more secure option
      • Also allows two-way data flow, such as contact sync
      • Provides an incentive to E-mail providers to develop standard API format for address books
  • 21. Application Extensions
      • Photo touchup tools, photo labs
      • Calendar/Contact sync tools
      • Health management tools
      • Blog publishing tools
    •  
    • Advanced OAuth tricks
      • http://sites.google.com/site/oauthgoog/
      • OAuth+Gadgets
      • OAuth+OpenID
      • OAuth+Google Apps Engine
      • OAuth in social apps
  • 22. Enterprise SaaS @ Saleforce.com  
  • 23. What is Salesforce.com?
  • 24. Who builds applications on Salesforce?
    • Three Types of Applications:
      • Salesforce.com Applications
      • ISV Applications
      • Custom Applications
  • 25. The Salesforce.com API
      • SOAP API with WSDL / Schema
      • Low verb count - Primarily CRUD
        • Developers can get started in 15-20 minutes
    •  
      • 100,000s of active integrations, all major platforms
      • 2 Billion API Calls a Month
      • 3 major releases a year, no broken integrations
  • 26. Multi-Tenancy Makes Cloud Computing Possible
      • Faster Vendor Innovation
      • Economies of Scale
      • Maximum Scalability
      • Automatic Upgrades
  • 27. Salesforce.com Design Principles
    • 1) Secure
      • Confidentiality, Integrity
      • Proven technologies, rigorously crypto-analyzed - e.g. SSL, client certs
      • Appropriate for public internet
    •  
    • 2) Simple
      • designed around a few well-defined uses cases
      • smarts in the service, not client or the wire protocol
      • Minimal surface area
    •  
    • 3) Re-usable
      • Built on technologies already in stack
      • Birds killed > stones
    •  
    • 4) Supportable
      • Based on interoperable standards
      • available on all major platforms
      • Reliable
  • 28. Enterprise SaaS Use Cases
  • 29. Enterprise SaaS Use Cases
  • 30. Enterprise SaaS Use Cases
  • 31. WS-Trust
  • 32. OAuth
  • 33. Salesforce.com Design Principles
    • 1) Secure
      • Confidentiality, Integrity
      • Proven technologies, rigorously crypto-analyzed - e.g. SSL, client certs
      • Appropriate for public internet
    •  
    • 2) Simple
      • designed around a few well-defined uses cases
      • smarts in the service, not client or the wire protocol
      • Minimal surface area
    •  
    • 3) Re-usable
      • Built on technologies already in stack
      • Birds killed > stones
    •  
    • 4) Supportable
      • Based on interoperable standards
      • available on all major platforms
      • Reliable
  • 34. Q&A
    • Ashish Jain - ajain@pingidentity.com
    • Peter Dapkus - pdapkus@salesforce.com
    • Eric Sachs    - esachs@google.com
  • 35. Appendix
  • 36. Summary continued
    • If you a service provider, support OAuth and you will make things simpler for your data consumers.
    • Within an enterprise or government scenario, this may be harder to do
    • For a web service, this should be your starting point
    • If you are a data consumer, and your service provider does not support OAuth, then try using WS-Trust
    • If your service provider does not support WS-Trust, then you will need to build your own proprietary bridge