Taking Identity from theEnterprise to the CloudPat PattersonPrincipal Developer Evangelistsalesforce.com
Safe HarborSafe harbor statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-lookingstatements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptionsproves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, includingany projections of subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plansof management for future operations, statements of belief, any statements concerning new, planned, or upgraded services ortechnology developments and customer contracts or use of our services.The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and deliveringnew functionality for our service, our new business model, our past operating losses, possible fluctuations in our operating resultsand rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the immature market in whichwe operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage ourgrowth, new releases of our service and successful customer deployment, and utilization and selling to larger enterprisecustomers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in ourannual report on Form 10-K filed on February 24, 2011 and in other filings with the Securities and Exchange Commission. Thesedocuments are available on the SEC Filings section of the Investor Information section of our Web site.Any unreleased services or features referenced in this or other press releases or public statements are notcurrently available and may not be delivered on time or at all. Customers who purchase our services should makethe purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes noobligation and does not intend to update these forward-looking statements.
Enterprise vs Cloud• Users authenticate to the enterprise, butresources are increasingly moving to the cloud– sites and APIs• How do we allow users to securely accessresources spread across multiple providerswithout spreading user credentials too?
Use Cases• Log in to Windows Desktop1. Browse to external web sites, access protectedresources without further authentication2. Browse to web site, site accesses external,protected API, on behalf of the user withoutfurther authentication3. Run desktop application, access external,protected API without further authentication
Technologies• Single sign-on– Integrated Windows Authentication• (Kerberos/SPNEGO)– SAML 2.0• Web services– OAuth 2.0– WS-Trust
Use Case 1: Single Sign-On toExternal Web Sites• Example.com has subscribed to SalesforceCRM• Each Example.com salesperson has their ownsalesforce.com account• How do we avoid them having to rememberanother password?
SAML 2.0• Single sign-on across domains/enterprises• OASIS standard (March 2005)• Widely supported– Google Apps since October 2006– salesforce.com since Winter ’09 (October 2008)– Active Directory Federation Services (AD FS) sinceversion 2.0 (May 2010)
SAML 2.0 ProtocolBrowserIdentity Provider Service ProviderGET /somethingHTTP/1.1 302 FoundLocation:http://idp.ex.com/saml?SAMLrequest=hf7893b…&RelayState=HKFDhh383GEThttp://idp.ex.com/saml?SAMLrequest=hf7893b…&RelayState=HKFDhh383200 OKSAML Assertion in HTML FORM POST /acsSAML AssertionHTTP/1.1 302 FoundLocation: http://sp.ex.net/somethingSet-Cookie: token=value; Domain=.ex.netAuthenticate
SAML 2.0 Example• Authenticate to example.com (identityprovider) with username/password• Access salesforce.com (service provider)
SAML 2.0 Limitations• User is authenticating to the enterprise, butstill being prompted for username/password.
Integrated Windows Authentication• Single sign-on within an AD domain/forest• Browser requests Kerberos token fromdesktop OS, wraps according to SPNEGO andincludes in HTTP request• Relying Party must register a service principalname (SPN) in AD
IWA Example• Simple intranet web site showing identity ofauthenticated user
IWA Limitations• Scope is limited to Windows Infrastructure– Server must be Kerberized• What about partners/vendors/customers?
Making SSO Seamless• With SAML 2.0, our Example.com salespeoplecan access salesforce.com without asalesforce.com password• If we add IWA to the mix, if they are logged into the example.com AD domain, they don’tneed to log in to salesforce.com at all!
SAML 2.0 + IWA• Compose the two protocols• AD FS acts as a broker between the ADdomain and the outside world
SAML 2.0 + IWA Example• Set AD FS config file to use integrated ratherthan form-based authentication• Access salesforce.com based on Windowsdesktop session
Use Case 2: AuthorizingThird-Party Access to APIs• Third-party web site provides value on top ofcustomer data• Accesses salesforce.com via SOAP or REST APIs• Need to be able to access API in the context ofthe end user
OAuth 2.0• Authorization for RESTful APIs• Evolution of Google AuthSub, Yahoo BBAuth,AOL OpenAuth etc• ‘Valet key’ for the web• Emphasis on simplicity, ease ofimplementation
OAuth 2.0 + SAML 2.0 + IWA• Can use SAML 2.0 for the authentication stepof OAuth• Instead of redirecting to centralsalesforce.com authorization server, usecustom domain (‘My Domain’ feature)• Triggers SP-initiated SAML 2.0 flow• Use IWA to avoid manual login
OAuth 2.0 + SAML 2.0 + IWA Example• Service Provider web site retrieves customer’sdata from salesforce.com via REST API• OAuth triggers SAML, which triggers IWA
Use Case 3: What AboutDesktop Apps?• Desktop applications can access web APIs, buthow do we authenticate the user?– Invoke browser for authentication?– Collect username/password?– Use PingFederate STS to broker enterprisecredentials for an OAuth token!
WS-Trust + SAML 2.0 + Oauth Example• Desktop Chatter client, accessingsalesforce.com REST APIs• Accessing API in context of end user (ratherthan ‘API user’) is essential!
Parting Thoughts• Building blocks exist for satisfying most singlesign-on and web services use cases• AD FS 2.0 SAML 2.0 support was a watershed• Third-party tools are still essential for a trulyseamless experience
Please Complete the Survey!www.theexpertsconference.com
Questions & Answers• Pat Patterson– Email - firstname.lastname@example.org– Blog - blog.sforce.com– Twitter - @metadaddy