This webinar covers key topics and best practices on how to securely connect your applications with Salesforce. We will demonstrate Salesforce recommended solutions to securely handle secrets within your application and help you prevent data leaks You will also learn how to set up a Salesforce Connected App to handle authentication and access control when integrating with Salesforce.

1. December 1, 2015
Lorem Ipsum Dolor

2. Speakers
Swapnil Shinde
Product Security Engineer
@Swapnil34
Nitin Arya
Product Security Analyst
@n_arya0

3. Forward-Looking Statement
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.

4. Agenda
• Overview
- Integrating your external applications securely with Salesforce
• Leveraging JavaScript Remoting with Visualforce
- Extend Salesforce functionality with external app intergrations
- Map user identities to the external systems
- Grant access to Salesforce data without breaking security model
• Using Remote Objects with Angular.js
- Secrets in named credentials
- Secrets in custom settings
- Proper usage of secrets

5. Building Salesforce Integrations
• Extend Salesforce funcationality 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.

6. Integration Methods – Apex Callouts
• Use Apex code to access external REST API’s
• Can be used to send data out or pull data to/from an
external service
• Actions must be initiated by a user action from within
Salesforce
• Partners fail security review here*
Salesforce
Internet
Web service

7. Integration Methods – API/OAuth
• Salesforce has several API’s for developers
• To use these API’s authentica via
- SOAP API username/password login
- OAUTH authentication flow
• Delegated authentication
- Forward username and password ( sent over internet* )
• Federated Authentication using SAML (Single sign on*)
Salesforce Web service
REST
SOA
P

8. Integration Methods – API - OAuth
• Salesforce has several API’s for developers
• External services can 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
• Outbound messaging
SOAP
RES
T

9. 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.

10. Integration User or 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 on 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.

11. Integration User or 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 or 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 secureon the external system.

12. Setting Up A Connected App
Go to Setup > Create > Apps > New Connected App

13. Setting Up A Connected App

14. 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.

15. 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 communications.

16. 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.

17. 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.

18. 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.

19. Mutual TLS

20. 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.

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

22. Salesforce 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.

23. Setting Up Mutual TLS

24. 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.

25. Part 2:
Secret Protection

26. Primary Topic Today: Secrets
• We will be covering developer-oriented topics on secret
storage for the Salesforce Platform.
• Specific features to cover include:
– Secrets in named credentials
– Secrets in custom settings
– Proper secret usage
– Protected Custom Metadata Types ???????????
• Useful for anyone in the following areas:
– Salesforce Developers (primarily)
– Salesforce Administrators
– Prospective Partners

27. What is a secret?
• Simple Definition: A piece of data that requires higher than
normal protection.
• For Our Purposes: A secret will be a piece of data that
nobody should see, like a password or encryption key.

28. Who do we secure secrets from?
• Attackers
• Regular Users
• Partners
• Administrators (Biggest Challenge)
• Basically, everyone… Why?
• Theft of data
• Impersonation
• Privilege Escalation

29. Secret in Named Credentials

30. Named Credentials Overview
Named crewdentials are a feature for secret storage built into
the Salesforce platform.
• Available in the “Security” setup menu
• Point & click creation
• No Code required to store secret

31. Named Credentials - Usage
• Create a new named credential
• Add the URL + secret to the named credential
• Invoke the named credential in the httpRequest
HttpRequest req = new HttpRequest();
req.setEndpoint('callout:NamedCredential');
req.setMethod('GET');
Http http = new Http();
HTTPResponse res = http.send(req);
return res.getBody();

32. Pros
• Easy to create.
• Easy to invoke.
• Secret is not visible in the UI
and code to anyone.
• Secret is not leaked in the
debug logs.
Cons
• Only works for httpRequests
and certain authentication
schemes like OAuth 2.0.
• URL can be updated in the
setup, potentially leaking
secret. ???
Named Credentials - Breakdown

33. Demo:
Secrets in Named Credentials

34. Custom Settings Overview
Custom settings are stripped down sObjects exposed to the
application cache, enabling efficient access for developers.
Protected versus Public: What is the difference?
Protected Custom Settings can only be accessed from the namespace
they exist in.
• In a managed package, the namespace is that of the package.
• In an unmanaged package, the namespace is the local namespace (so
no effect).
What does this mean?
• Managed protected Custom Settings – Extra Security Benefits
• Managed Public/ Local Public/ Local Protected – No security benefits,
worse for secrets than sObjects.

35. Managed Protected Custom Settings –
Storage Method
1. Create a managed package.
2. Create a protected custom setting inside the package.
3. Create a Visualforce page inside the package to
create/update the secret.
- Transient string (in controller), should not return secret to the view state.
4. Access and use the secret inside the managed package.

36. Custom Setting Diagram

37. Pros
• Secret only available to Apex
code within managed
package namespace.
• Can store encryption key to
scale.
Cons
• Requires a managed
package!
• Methods must be well-coded
to prevent secret exposure.
Managed Protected Custom Setting - Breakdown

38. Managed Package Architecture

39. Demo: Secrets in Custom Settings

40. Using Managed Protected Custom
Settings Properly

41. Overview
Using Managed Protected Custom Settings Properly
Secret storage solutions with managed protected custom settings
are developed in Apex and Visualforce, and because of this there
are some best practices that must be followed:
• Properly encapsulating secret usage in the managed package
• Properly handling secret dependencies
• Avoiding secret reflection

42. Properly Encapsulating Secret Usage
What is encapsulation? Keeping functionality inside the managed
package.
Why encapsulate? Namespace benefits on work INSIDE the
managed package. Anything leaving the package loses benefits.
Things to consider for encapsulation:
• User interaction - Visualforce page/component inside the managed
package.
• Using the secret – Code must be contained within the managed
package.
• Invoking secret usage - Done with a global method, secret never
returned outside of the managed package.

43. Managed Package Architecture

44. Properly Handling Secret Dependencies
What are secret dependencies? If a secret is tied to another
piece of information, a dependency is created.
Examples:
• Passwords can be dependent on URLs.
• Encryption keys can be dependent on Salts.
Secret dependency best practices:
• Secrets and dependencies are controlled from the same place
• If dependent is updated, secret should be updated. This prevents the
attacker from gaining additional information.
• Example: If a URL is updated, password should change too!

45. Avoiding Secret Reflection
What is secret reflection?
Developers often mistakenly allow a secret to be reflected from the
controller (Apex) to the view (Visualforce). Since the view is client
side, the risk of secret exposure increases dramatically!
Secret reflection Best Practices
• Beware hidden inputs – hidden inputs often show secret in clear within
source.
• Use transient keyword – transient keyword prevents secret from being
stored in the Visualforce viewstate.

46. Demo: Proper Secret Usage

47. Recap
1. Named Credentials
• Pro – Simple. No secret refelcted in UI or debug logs.
• Con – URL can be changed and secret leaked, only works with httpRequests.
- Works well with: Passwords and OAuth tokens that don’t come with admin
privileges.
2. Managed Protected Custom Setting (Secret Storage Best Practice)
• Pro – Most secure option. Protects against users with elevated permissions such
as Modify all Data.
• Con – Requires a managed package. Requires careful attention to code (see
below).
- Works well with: Passwords, OAuth tokens, Encryption keys.
3. Using Managed Protected Custom Settings Properly
• Properly encapsulating secret usage in the managed package.
• Properly handling secret dependencies (update password when updating URL).
• Avoiding secret reflection (beware hidden inputs use transient keyword).

48. Additional Resources
• Secure Coding Guidelines - https:/
developer.salesforce.com/page/Secure_Coding_Storing_Secrets
• Intro to Managed Packages -
https://developer.salesforce.com/page/An_Introduction_to_Packaging
• Salesforce StackExchange –
http://salesforce.stackexchange.com/questions/tagged/security
• Developer.Salesforce.com Security Forum -
https://developer.salesforce.com/forums (full link hidden)
• Security Office Hours (Partners) -
http://security.force.com/security/contact/ohours
• Security Implementation Guide -
https://developer.salesforce.com/././securityImplGuide/ (full link hidden)
• Force.com Security Essentials Course -
https://trustacademy.salesforce.com

49. #forcewebinar

51. Additional Resources
• Digging deep into Oauth 2.0
• Salesforce trust academy
• Salesforce generate CSR
• Salesforce mutual TLS setup
• Salesforce connected apps

52. Q & A
Try Trailhead: trailhead.salesforce.com
Join the conversation: @salesforcedevs

53. Thank You