Your SlideShare is downloading. ×

Identity Enabling Web Services

3,744

Published on

DIDW 08 presentation

DIDW 08 presentation

Published in: Technology, Economy & Finance
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,744
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
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

    ×