Presented at The Experts Conference, Las Vegas, April 2011

1. Taking Identity from the
Enterprise to the Cloud
Pat Patterson
Principal Developer Evangelist
salesforce.com

2. Safe Harbor
Safe harbor statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-looking
statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions
proves 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, including
any projections of subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans
of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or
technology 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 delivering
new functionality for our service, our new business model, our past operating losses, possible fluctuations in our operating results
and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the immature market in which
we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our
growth, new releases of our service and successful customer deployment, and utilization and selling to larger enterprise
customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our
annual report on Form 10-K filed on February 24, 2011 and in other filings with the Securities and Exchange Commission. These
documents 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 not
currently available and may not be delivered on time or at all. Customers who purchase our services should make
the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no
obligation and does not intend to update these forward-looking statements.

3. Enterprise vs Cloud
• Users authenticate to the enterprise, but
resources are increasingly moving to the cloud
– sites and APIs
• How do we allow users to securely access
resources spread across multiple providers
without spreading user credentials too?

4. Use Cases
• Log in to Windows Desktop
1. Browse to external web sites, access protected
resources without further authentication
2. Browse to web site, site accesses external,
protected API, on behalf of the user without
further authentication
3. Run desktop application, access external,
protected API without further authentication

5. Technologies
• Single sign-on
– Integrated Windows Authentication
• (Kerberos/SPNEGO)
– SAML 2.0
• Web services
– OAuth 2.0
– WS-Trust

6. Use Case 1: Single Sign-On to
External Web Sites
• Example.com has subscribed to Salesforce
CRM
• Each Example.com salesperson has their own
salesforce.com account
• How do we avoid them having to remember
another password?

7. 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) since
version 2.0 (May 2010)

8. SAML 2.0 Roles

9. SAML 2.0 Protocol
Browser
Identity Provider Service Provider
GET /something
HTTP/1.1 302 Found
Location:
http://idp.ex.com/saml?SAMLrequest=hf7893b…
&RelayState=HKFDhh383
GET
http://idp.ex.com/saml?SAMLrequest=hf78
93b…&RelayState=HKFDhh383
200 OK
SAML Assertion in HTML FORM POST /acs
SAML Assertion
HTTP/1.1 302 Found
Location: http://sp.ex.net/something
Set-Cookie: token=value; Domain=.ex.net
Authenticate

10. SAML 2.0 Assertion
<Assertion>
<Issuer/>
<Signature/>
<Subject/>
<Conditions/>
<AttributeStatement/>
<AuthnStatement/>
</Assertion>

11. SAML 2.0 Assertion - Issuer
<Assertion ID="_20f7…"
IssueInstant="2011-03-28T18:23:25.539Z"
Version="2.0">
<Issuer>
http://adfs-
dc.my.example.com/adfs/services/trust
</Issuer>
<Signature/>
<Subject/>
<Conditions/>
<AttributeStatement/>
<AuthnStatement/>
</Assertion>

12. SAML 2.0 Assertion - Signature
<Assertion>
<Issuer/>
<Signature>
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="#_20f7fb27-6bb1-4801-aaab-25b4ff862d2f">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>UrcVwqLcdqMvtJUkxiIw9CBN1h8=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>ITY8KT…</SignatureValue>
<KeyInfoxmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>MIIC6D…</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<Subject/>
<Conditions/>
<AttributeStatement/>
<AuthnStatement/>
</Assertion>

13. SAML 2.0 Assertion - Subject
<Assertion>
<Issuer/>
<Signature/>
<Subject>
<SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData
InResponseTo="_2Qwip…"
NotOnOrAfter="2011-03-28T18:28:25.539Z"
Recipient="https://login.sf.com/?saml=…" />
</SubjectConfirmation>
</Subject>
<Conditions/>
<AttributeStatement/>
<AuthnStatement/>
</Assertion>

14. SAML 2.0 Assertion - Conditions
<Assertion>
<Issuer/>
<Signature/>
<Subject/>
<Conditions
NotBefore="2011-03-28T18:23:25.537Z"
NotOnOrAfter="2011-03-28T19:23:25.537Z">
<AudienceRestriction>
<Audience>
https://superpat.my.salesforce.com
</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement/>
<AuthnStatement/>
</Assertion>

15. SAML 2.0 Assertion –
AttributeStatement
<Assertion>
<Issuer/>
<Signature/>
<Subject/>
<Conditions/>
<AttributeStatement>
<Attribute Name="mail">
<AttributeValue>
pat@superpat.com
</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement/>
</Assertion>

16. SAML 2.0 Assertion - AuthnStatement
<Assertion>
<Issuer/>
<Signature/>
<Subject/>
<Conditions/>
<AttributeStatement/>
<AuthnStatement
AuthnInstant="2011-03-28T18:23:25.501Z">
<AuthnContext>
<AuthnContextClassRef>
urn:federation:authentication:windows
</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>

17. SAML 2.0 Example
• Authenticate to example.com (identity
provider) with username/password
• Access salesforce.com (service provider)

18. SAML 2.0 Limitations
• User is authenticating to the enterprise, but
still being prompted for username/password.

19. Integrated Windows Authentication
• Single sign-on within an AD domain/forest
• Browser requests Kerberos token from
desktop OS, wraps according to SPNEGO and
includes in HTTP request
• Relying Party must register a service principal
name (SPN) in AD

20. IWA Protocol
BrowserDesktop O/S Server
GET /something
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Negotiate
InitializeSecurityContext()
NegTokenInit
GET /something
Authorization: Negotiate b64(NegTokenInit)
HTTP/1.1 200 OK
Requested Content
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Negotiate b64(responseToken)
InitializeSecurityContext(responseToken)
NegTokenTarg
GET /something
Authorization: Negotiate b64(NegTokenTarg)

21. IWA Example
• Simple intranet web site showing identity of
authenticated user

22. IWA Limitations
• Scope is limited to Windows Infrastructure
– Server must be Kerberized
• What about partners/vendors/customers?

23. Making SSO Seamless
• With SAML 2.0, our Example.com salespeople
can access salesforce.com without a
salesforce.com password
• If we add IWA to the mix, if they are logged in
to the example.com AD domain, they don’t
need to log in to salesforce.com at all!

24. SAML 2.0 + IWA
• Compose the two protocols
• AD FS acts as a broker between the AD
domain and the outside world

25. SAML 2.0 + IWA Protocols
BrowserIdentity Provider Service Provider
GET /something
HTTP/1.1 302 Found
Location: https://idp.ex.com/saml?...
GET https://idp.ex.com/saml?...
200 OK
SAML Assertion in HTML FORM
POST /acs
SAML Assertion
HTTP/1.1 302 Found
Location: https://sp.ex.net/something
Set-Cookie: token=value; Domain=.ex.net
WWW-Authenticate: Negotiate
Authorization: Negotiate a874…
WWW-Authenticate: Negotiate he83…
Authorization: Negotiate k83g…

26. SAML 2.0 + IWA Example
• Set AD FS config file to use integrated rather
than form-based authentication
• Access salesforce.com based on Windows
desktop session

27. Use Case 2: Authorizing
Third-Party Access to APIs
• Third-party web site provides value on top of
customer data
• Accesses salesforce.com via SOAP or REST APIs
• Need to be able to access API in the context of
the end user

28. 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 of
implementation

29. OAuth Roles

30. OAuth 2.0 Protocol
Browser
Authorization
Server Client App
GET /something
302 Found
Location:
https://login.ex.com/?response_ty
pe=code&client_id=…&redirect_uri
=…GET /?response_type=...
302 Found
Location:
https://app.cl.com?code=… GET /app.cl.com?code=…
Resource Server
Authenticate
POST /token
code=…&grant_type=authorization_code&client_id=…&client_secret=…&r
edirect_uri=…
GET /data
Authorization: OAuth 00D5…
200 OK
{ “access_token”: “00D5…”}
200 OK
Data200 OK
Some Content

31. OAuth 2.0 + SAML 2.0 + IWA
• Can use SAML 2.0 for the authentication step
of OAuth
• Instead of redirecting to central
salesforce.com authorization server, use
custom domain (‘My Domain’ feature)
• Triggers SP-initiated SAML 2.0 flow
• Use IWA to avoid manual login

32. OAuth 2.0 + SAML 2.0 + IWA Protocols
Browser
Authorization
Server Client App
Resource Server

33. OAuth 2.0 + SAML 2.0 + IWA Example
• Service Provider web site retrieves customer’s
data from salesforce.com via REST API
• OAuth triggers SAML, which triggers IWA

34. Use Case 3: What About
Desktop Apps?
• Desktop applications can access web APIs, but
how do we authenticate the user?
– Invoke browser for authentication?
– Collect username/password?
– Use PingFederate STS to broker enterprise
credentials for an OAuth token!

35. Security Token Service
• WS-Trust protocol
• Token in
– Username/password
– Kerberos
– SAML
– Custom
• Token out
– SAML
– Custom
• No protocol diagram required!

36. WS-Trust + SAML 2.0 + OAuth
• Exchange Kerberos Token for SAML 2.0
Assertion - PingFederate
– WS-Trust
• Exchange SAML 2.0 Assertion for OAuth 2.0
Access Token – Salesforce.com
– OAuth

37. High Level Protocol Flow
Desktop AppDesktop O/S STS
Resource Server
Get Kerberos Token
Kerberos Token
Kerberos Token
Authorization
Server
SAML Assertion
OAuth Token
GET /data
Authorization: OAuth 00D5…
200 OK
Data
OAuth Token

38. WS-Trust + SAML 2.0 + Oauth Example
• Desktop Chatter client, accessing
salesforce.com REST APIs
• Accessing API in context of end user (rather
than ‘API user’) is essential!

39. Parting Thoughts
• Building blocks exist for satisfying most single
sign-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 truly
seamless experience

40. Please Complete the Survey!
www.theexpertsconference.com

41. Questions & Answers
• Pat Patterson
– Email - ppatterson@salesforce.com
– Blog - blog.sforce.com
– Twitter - @metadaddy