taking identity from the enterprise to the cloud

Taking Identity from the Enterprise to the Cloud

Pat PattersonPrincipal Developer Evangelistsalesforce.com

Safe HarborSafe 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.

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?

Use Cases

• Log in to Windows Desktop1. Browse to external web sites, access protected

resources without further authentication2. 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

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 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?

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)

SAML 2.0 Roles

SAML 2.0 ProtocolBrowserIdentity Provider Service Provider

GET /something

HTTP/1.1 302 FoundLocation: http://idp.ex.com/saml?

SAMLrequest=hf7893b…&RelayState=HKFDhh383GET http://idp.ex.com/saml?

SAMLrequest=hf7893b…&RelayState=HKFDhh383

200 OKSAML Assertion in HTML FORM POST /acs

SAML Assertion

HTTP/1.1 302 FoundLocation: http://sp.ex.net/something

Set-Cookie: token=value; Domain=.ex.net

Authenticate

SAML 2.0 Assertion

<Assertion> <Issuer/> <Signature/> <Subject/> <Conditions/> <AttributeStatement/> <AuthnStatement/></Assertion>

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>

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> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <X509Data> <X509Certificate>MIIC6D…</X509Certificate> </X509Data> </KeyInfo> </Signature> <Subject/> <Conditions/> <AttributeStatement/> <AuthnStatement/></Assertion>

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>

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>

SAML 2.0 Assertion – AttributeStatement

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

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>

SAML 2.0 Example

• Authenticate to example.com (identity provider) with username/password

• Access salesforce.com (service provider)

SAML 2.0 Limitations

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

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

IWA ProtocolBrowserDesktop O/S Server

GET /something

HTTP/1.1 401 UnauthorizedWWW-Authenticate: Negotiate

InitializeSecurityContext()

NegTokenInitGET /something

Authorization: Negotiate b64(NegTokenInit)

HTTP/1.1 200 OKRequested Content

HTTP/1.1 401 UnauthorizedWWW-Authenticate: Negotiate b64(responseToken)

InitializeSecurityContext(responseToken)

NegTokenTargGET /something

Authorization: Negotiate b64(NegTokenTarg)

IWA Example

• Simple intranet web site showing identity of authenticated 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 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!

SAML 2.0 + IWA

• Compose the two protocols• AD FS acts as a broker between the AD

domain and the outside world

SAML 2.0 + IWA ProtocolsBrowserIdentity Provider Service Provider

GET /something

HTTP/1.1 302 FoundLocation: https://idp.ex.com/saml?...

GET https://idp.ex.com/saml?...

200 OKSAML Assertion in HTML FORM POST /acs

SAML Assertion

HTTP/1.1 302 FoundLocation: 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…

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

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

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

OAuth Roles

OAuth 2.0 ProtocolBrowser

Authorization Server Client App

GET /something

302 FoundLocation: https://login.ex.com/?

response_type=code&client_id=…&redirect_uri=…GET /?response_type=...

302 FoundLocation: https://app.cl.com?

code=… GET /app.cl.com?code=…

Resource Server

Authenticate

POST /tokencode=…&grant_type=authorization_code&client_id=…&client_secret=…

&redirect_uri=…

GET /dataAuthorization: OAuth 00D5…

200 OK{ “access_token”: “00D5…”}

200 OKData200 OK

Some Content

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

OAuth 2.0 + SAML 2.0 + IWA ProtocolsBrowser

Authorization Server Client App Resource Server

JUST KIDDING!

☺

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

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!

Security Token Service

• WS-Trust protocol• Token in– Username/password– Kerberos– SAML– Custom

• Token out– SAML– Custom

• No protocol diagram required!

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

High Level Protocol FlowDesktop AppDesktop O/S STS Resource Server

Get Kerberos Token

Kerberos Token

Kerberos Token

Authorization Server

SAML Assertion

OAuth Token

GET /dataAuthorization: OAuth 00D5…

200 OKData

OAuth Token

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!

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

Please Complete the Survey!

www.theexpertsconference.com

Questions & Answers

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