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> [email protected] </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 - [email protected]– Blog - blog.sforce.com– Twitter - @metadaddy