Platform Encryption with Salesforce

In this blog, I am going to explain the platform encryption and its architecture.
Introduction : 

It is common practice today to encrypt data Prevent from the unauthorized access. Salesforce Platform encryptions are allowed to today to encrypt data at rest, that is, data stored on servers with the salesforce platform encryption.  Data stored in many standard and custom fields and in files and attachments is encrypted using an advanced HSM-based key derivation system, so it is protected even when other lines of defense have been compromised.Your data encryption key is never saved or shared across organizations. Instead, it is derived on demand from a master secret and your organization-specific tenant secret, and cached on an application server.

Benefits of Encrypting Data at Rest

First and foremost, encrypting data at rest protects the organization from the physical theft of the file system storage devices (which is why end-user mobile devices from laptops to cell phones should always be encrypted). While this might sound unlikely, the physical disk devices are only as secure as the data center where they are located. Encrypting data at rest can protect the organization from unauthorized access to data when computer hardware is sent for repair or discarded.

What you can encrypt?

Salesforce platform Encryption allows you to encrypt fields, files, and attachments and Custom field as shown in this image.

Which User Permissions Does Shield Platform Encryption Require?

Assign permissions to your users according to their roles regarding encryption. Some users need the “View Encrypted Data” permission, while some need other combinations of permissions to select data for encryption or work with encryption keys. You can enable these permissions just like you would any other user permission.

How Platform Encryption Works

Shield Platform Encryption relies on a unique tenant secret that you control and a master secret that’s maintained by Salesforce. We combine these secrets to create your unique data encryption key. We use that key to encrypt data that your users put into Salesforce and to decrypt data when your authorized users need it. Encrypting files, fields, and attachments has no effect on your organization’s storage limits.

When users submit data, the application server looks for the org-specific data encryption key in its cache. If it isn’t there, the application server gets the encrypted tenant secret from the database and asks the key derivation server to derive the key. The encryption service then encrypts the data on the application server.

Take the time to identify the most likely threats to your organization. This will help you distinguish data that needs encryption from data that doesn’t so that you can encrypt only what you need to. Make sure your tenant secret and keys are backed up, and be careful who you allow managing your secrets and keys.

Before data is encrypted, a Salesforce administrator must enable encryption and generate a tenant secret. For each field, file, and attachment on which encryption is enabled, the corresponding metadata in the UDD is updated to reflect the new encryption setting. Users must have the “View Encrypted Data” permission to view encrypted field data.

  1. When a Salesforce user saves encrypted data, the runtime engine determines from metadata whether the field, file, or attachment should be encrypted before storing it in the database.
  2. If so, the encryption service checks for the matching data encryption key in cached memory.
  3. The encryption service determines if the key exists. a. If so, the encryption service retrieves the key. b. Otherwise, the service sends a derivation request to a key derivation server and returns it to the encryption service running on the App Cloud.
  4. After retrieving or deriving the key, the encryption service generates a random initialization vector (IV) and encrypts the data using JCE’s AES-256 implementation.
  5. The ciphertext is saved in the database or file storage. The IV and corresponding ID of the tenant secret used to derive the data encryption key are saved in the database.

Salesforce Named Credentials

In this blog, i am going to explain what Named Credentials. Named Credentials were introduced by Salesforce in the spring ’15 release. You can exchange secure authentication in REST API number of ways like OAuth, secure HTTP headers, other ways. Now we are going to see how named Credentials makes the differences.

Before Named Credentials?

If you think before named creations how we are managing the rest API authentication and endpoint URL  in different ways like Custom settings, Custom labels or some other options in Salesforce. Most importantly every time when you add or change you need to add it to remote site settings which are little cumbersome.If you use named credentials, you store the user credentials in the named credential itself with just clicks and configuration. It’s easy to maintain if you have to switch different creation in different org.

What is Named Credentials?

As per the document “A named credential specifies the URL of a callout endpoint and its required authentication parameters in one definition. To simplify the setup of authenticated callout, specify a named credential as the callout endpoint. If you instead specify a URL as the callout endpoint, you must register that URL in your org’s remote site settings and handle the authentication yourself”

In nutshell 

Named credentials allow you to store a URL and secret together which in turn allows Salesforce to manage all the authentication for Apex callouts that specify this named credentials

What are the benefits?

  •   Specifies the URL of a callouts endpoint and its authentication in one place
  •  No need to handle  Remote site settings of the callout URL
  •   Supports two types of authentication protocols for now: Basic Authentication(Password authentication) or OAuth.
  •  Can be configured easily if Authentication needs to be done in User Context or Admin Context

Basic HTTP Authentication 

Now lets understating how the basic HTTP Callout authentication will be handled with out using named credentials . Here we are going to use simple apex HTTP Request Class to handler the callouts as show below

HttpRequest req = new HttpRequest();
String username = ‘username’;
String password = ‘password’;
Blob headerValue = Blob.valueOf(username + ‘:’ + password);
String authorizationHeader = ‘BASIC ‘ + EncodingUtil.base64Encode(headerValue);
req.setHeader(‘Authorization’, authorizationHeader);
Http http = new Http();
HttpResponse res = http.send(req);
System.debug(‘====> result ==>’res.getBody());

even though above logic is not too complicated to handle, sensitive information like password and username got exposed. The second challenge is you need to maintain the remote site settings.

Authentication  with Named Credentials 

Now let’s see how the named Credentials make the difference in authentication  First define a Named Credential with the following values as shown below image   . to define named credentials Setup -> Security Controls ->  Named Credentials and create a new named credential.

Now you can invoke the named credentials in apex code as shown below.Apex code simply you have to pass the named credentials name followed by “callout:”

HttpRequest req = new HttpRequest();
Http http = new Http();
HTTPResponse res = http.send(req);
return res.getBody();

Limitations ?
primary named credentials was designed to implement more secure rest callout authentication. even though here are few limitations of named credentials

  • Named credentials only support HTTP Callouts and basic or OAuth 2.0 authentication. They are not an option for storing SOAP callout authentication secrets, encryption keys, or secrets for more complex authentication schemes
  • Named credentials are not currently available for packaging
  • Users with Modify All Data can update the URL

Salesforce Identity Provider for EchoSign

Introduction :- 
In this blog post, I am going to explain step by step to setup the salesforce identity provider with EchoSign. Setting up echo sign Identity with salesforce is having mainly three stages namely configuring Salesforce identity provider, configure EchoSign, create connected apps 
Prerequisites :-
1.Enable My Domain in Salesforce 

2. Start you free tail
Step1: -Enable  Salesforce Identity Provider 

1. Navigate to Setup | Administration Setup | Security Controls | Identity Provider. You should see Identity Provider setup. Click on “Enabled Identity Provider

 2. (Optionally) change the self-signed certificate to a production certificate issued by a certificate authority.This certificate is used to sign SAML assertions


3.Click on Save.As shown below Click on the Download Certificate button to download the certificate. This certificate is used to setup service providers. 


4 . Salesforce Identity Provider exposes the following endpoints. You would need these when configuring SAML at the service provider. (replace your domain with your MyDomain value) (replace your domain with your MyDomain value)

Step 2: Configure EchoSign 

  1. Sign in to your EchoSign account.
  2. Click on Account | Account Settings
  3. Click on SAML Settings tab under Account Settings.In the right side, you will see an option for SAML Mode, select SAML Allowed mode if you want users to sign in to EchoSign account using SAML as well as EchoSign credentials. Else select SAML Mandatory mode to sign in using SAML only.

4.A dedicated Hostname is required to enable SAML. If you already have dedicated hostname then this option will not be there. Otherwise, enter your hostname.

5.Under User Creation, check if you would like users to be provisioned into EchoSign when they sign in without an account.

6. Under Login Page Customization, you can enter Single Sign on Login message. It will be shown when you go for SP-initiated SSO. e.g. Sign In using Salesforce

7.Enter IdP Entity ID as your SAML IdP Issuer i.e. 

8.Enter IdP Login URL as SP-Initiated Redirect Endpoint” URL i.e. 

9.Enter IdP Logout URL i.e. e.g.

10.Enter IdP Certificate content.

11.You will see EchoSign SAML Service Provider (SP) Information. Note down these URLs as you will need them in Salesforce side Configuration.

12.Click Save Changes button to save the settings.


Step 3 :Configure salesforce connect app:- 

  1. Log in as an Administrator, and navigate to Setup | App Setup | Create | Apps
  2. Under Connected Apps section, click New.
  3. Under Basic Information,
    1. Provide Connected App Name
    2. The field API Name is auto-populated
    3. In the field Logo Image URL, select Choose one of our sample logos, find the logo, and copy past the logo URL. Or, enter your own URL.
    4. In the field Contact Email, enter your email address. 


Under Web App Settings,

  1. Select Enable SAML
  2. Enter Entity ID as
  3. Enter ACS URL as 
  4. Select Subject Type. e.g. Federation ID. Please note that SAML Subject must carry the same identity as of EchoSign user’s account ID i.e. email.
  5. In the field Name ID Format, keep the default selection (unspecified)
  6. In the field Issuer, keep the default value
  7. In the field Service Provider Certificate, keep the default (unselected)

  1. Save the settings.
  2. Go to Manage Apps | Connected Apps
  3. Select your App.
  4. Click Manage Profiles or Manage Permission Sets and add profiles/permission sets of users who can access this app.



IdP Initiated Login URL: It will be used to test the IdP initiated SSO. Right click IdP-Initiated Login URL, and copy the link into a notepad.

  1. Click Edit Policies 
  2. In the field Start URL, copy and paste the URL from Notepad.
  3. Click Save.
  4. SSO setup for EchoSign is complete.

After Configured the Policies, you can see the EchoSign App in App launcher as shown below.