Salesforce is an open and easily extensible platform. However, sometimes it's hard to figure out the best, most secure way to build these integrations. Join us as we help you build secure integrations with Salesforce by understanding the platform authentication and authorization constructs like profile permissions and OAuth scopes. We will demonstrate the importance of leveraging Salesforce security features like mutual SSL, IP range restrictions, and Connected Apps.

1. Secure Salesforce - External
App Integrations
​ Astha Singhal
​ Senior Product Security Engineer
​ salesforce.com
​ @astha_singhal
​ @SecureCloudDev
​ Chris Vinecombe
​ Application Security Engineer
​ salesforce.com

2. ​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
product or service availability, 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, new products and services, 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 outcome of any litigation, risks associated with completed and
any possible mergers and acquisitions, 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, our limited history reselling
non-salesforce.com products, 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 for the most recent fiscal year and in our quarterly report on Form
10-Q for the most recent fiscal quarter. These documents and others containing important disclosures 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 presentations, 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.
​
Safe Harbor

3. Astha Singhal
Senior Product Security Engineer
salesforce.com

4. Astha Singhal
- Working with product teams from design to implementation to help them
build secure applications for our customers.
- Conduct penetration tests and code reviews on Salesforce applications.
- Facilitating the security process via better security training and enabling self-
service for product teams.
- Helping them understand security bugs and guiding through remediation of
security issues.

5. Chris Vinecombe
Application Security Engineer
salesforce.com

6. Chris Vinecombe
- Work with vendors to ensure third party applications used by Salesforce are
secure.
- Conduct penetration tests on Salesforce’s vendor applications.
- Assist Salesforce business units in selecting secure vendors and products.
- Help vendors understand security vulnerabilities and assisting with
remediation of security issues.

7. Building Salesforce Integrations
- Extend Salesforce functionality with external app integrations
- Building data flows and interactions between your external app and
Salesforce
- Need a way to map Salesforce user identity to your external system
- Need a way to authenticate and secure data flows between the two systems
- Need a way to grant access to Salesforce data without breaking the
Salesforce security model or trust in the Salesforce platform

8. Integration methods
API / OAuth
- External services authenticate with Salesforce via OAuth and receive access
tokens
- Tokens must be treated with same sensitivity as a password
- Utilize public-facing API’s to share data with Salesforce instances
- Developers can expose custom Apex REST endpoints

9. Integration methods
Apex Callouts
- Use Apex code to access external REST API’s
- Can be used to send data out or pull data in to/from an external service
- Actions must be initiated by a user action from within Salesforce

10. Integration methods
Connected App
- Runs on the Salesforce app canvas
- Does not have access to the Salesforce app DOM at any time
- Authenticate via OAuth or SAML using Salesforce credentials
- Easy way to integrate an external application into the Salesforce “skin”
- The OAuth scope for the connected app determines the amount of access
this app would have to your Salesforce data
- Make sure to provide least privilege to the OAuth token being created.

11. Integration user vs End User
Integration User
- Creating an integration user to make callouts from the external app into
Salesforce.
- Lets you create a least privilege integration user to perform certain
operations required by the app.
- You don’t have to provide API access to all users.
- Only one credential to manage on the external system.
- You have to make sure that the Salesforce security model is not broken
when the external system accesses Salesforce data.

12. Integration user vs End User
End User
- Lets your external app make requests as current logged in user with the
specified OAuth scope.
- Lets the user select if they want to allow access or not.
- Preserves the Salesforce security model in your external requests without
any additional measures.
- The external app needs to make sure all end user OAuth credentials are
stored securely on the external system.

13. Setting up a Connected App
- Go to Setup -> Create -> Apps -> New Connected App.

14. Setting up a Connected App

15. Advantages of Connected apps
​ No need for custom authentication logic.
​ Least privilege access control based on the external app use case.
​ Easy to revoke access for misbehaving apps.
​ Out of box functionality for standard Auth protocols.
​ Can provide access without sharing Salesforce username password with the
external app.

16. Credential handling
- External app credentials (consumer key/secret) should be stored securely off
the Salesforce platform.
- Salesforce OAuth tokens should be stored securely off the platform using the
industry best practice for your development platform
- API tokens for the external app should be stored via Protected custom
settings inside Salesforce.
- All credentials should be secure in transit by using HTTPS (TLS) for all
communication

17. Transport Security
Security Expectations of HTTP
- None
- Anyone on the network can eavesdrop traffic
- Anyone on the network can modify content
- Anyone on the network can divert traffic

18. Transport Security - What is TLS?
​ A user visiting a site over HTTP has no assurance that the user is interacting
with the legitimate site
​ The Transport Layer Security protocol allows for secure communication
between applications and users.
​ Uses PKI (Public Key Infrastructure) to have a Trusted Certificate Authority
(CA) vouch for the server’s identity.
​ Prevents tampering, eavesdropping, and man-in-the-middle attacks against
secure communications. Provides authentication and confidentiality.

19. Mutual TLS
- Salesforce supports Mutual TLS for communications between Salesforce
and your external server.
- This allows you to do a two-way verification, where the client and server can
confirm one another’s identity.
- Good for server to server authentication, where the client is not prompting a
user to log in manually.

20. Mutual TLS
Acme.com

21. Salesforce Mutual TLS
- Client certificates are uploaded and stored in the Salesforce database,
where they are used for verification.
- You can also download the Salesforce client certificate to authenticate on
your web server, when making Apex callouts, etc.
- Salesforce provides a mechanism to prevent falling back to the standard TLS
port.

22. Setting Up Mutual TLS
​ Have mutual TLS enabled for your organization.
​ Generate Certificate Signing Request (CSR) and acquire a certificate from a
Trusted CA.

23. Setting Up Mutual TLS
​ Upload the certificate to Security Controls | Certificate and Key Management
​ Enable “Enforce SSL/TLS Mutual Authentication” permission for the API client
user. This will force mutual TLS on port 8443 for this user.
​ This user permission can be added via a PermSet or by adding the permission
to the user profile.
​ Configure the API client to connect on port 8443 and present the client
certificate.

24. Setting Up Mutual TLS

25. Why use mutual TLS ?
- This seems like a lot of work! Why should I do this?
- Provides you a good way to authenticate both parties (Salesforce and
external app) when building external integrations
- You don’t just have to rely on IP range restrictions and static API keys for
client authentication.
- Out of the box mutual TLS implementation provides authentication and
confidentiality.

26. Thank you

27. Secure Salesforce at Dreamforce 2015
​ 10 DevZone Talks and 2 Lighting Zone Talks covering all aspects of
Security on the Salesforce Platform
​ Visit our booth in the DevZone with any security questions
​ Check out the schedule and details at http://bit.ly/DF15Sec
​ Admin-related security questions?
​ Join us for coffee in the Admin Zone Security Cafe

28. Secure Salesforce at Dreamforce 2015
​ Hardened Apps with the Mobile SDK
​ Martin Vigo and Maxwell Feldman
​ Thursday 2:30pm in Moscone West 2008
​ Code Scanning with Checkmarx
​ Robert Sussland and Gideon Kreiner
​ Thursday 3:30pm in Moscone West 2011
​ Lightning Components Best Practices
​ Robert Sussland and Sergey Gorbaty
​ Thursday 4:45pm in Moscone West 2007
​ Common Secure Coding Mistakes
​ Rachel Black and Alejandro Raigon Munoz
​ Thursday 5:00pm in Moscone West 2006
​ Chimera: External Integration Security
​ Tim Bach and Travis Safford
​ Friday 10:00am in Moscone West 2009

29. Additional Resources
Salesforce mutual TLS set up
Salesforce Connected Apps documentation
Digging deeper into OAuth 2.0 on Force.com
Salesforce Trust academy
How to generate a CSR

30. Share Your Feedback, and Win a GoPro!
3
Earn a GoPro prize entry for
each completed survey
Tap the bell to take a
survey2Enroll in a session1

31. Questions?