Salesforce Auth Provide – Facebook

In this blog, I am going to explain how to configure Salesforce social sign on with Facebook.
Custom Domain should be created and enabled for users.
Create a Facebook application:-

First, log into the Facebook Developer Site and create a new Facebook App. You can do this by clicking the “My Apps” menu at the top of the screen and then click on the “Add a New App” button. You should see something like the following:

Enter a “Display Name” (the name of your app), and choose a category for your app. Once you’ve done this, click the “Create App ID” button.
Next, click on Settings on the left side, and make note of the App ID and App Secret. You’ll need those later when you connect your Facebook Application to Salesforce. Click “Submit” to finish creating the new application. Your App Id and App Secret looks as shown below

Configure Facebook authentication provider in your Salesforce:-

Now we are going to configure your sales force login by using the facebook. To do this , go to setup ->Security Controls ->Auth Providers -> New –>Select Facebook as Provider Type as shown below

1.Enter a Name for the provision as Facebook or you can choose your any desired name wish to have
2.Enter Consumer Key and Consumer Secret from the App Id and App Secret which you got from the Facebook application.
3.Authorize Endpoint URL and Token Endpoint URL, User Info Endpoint URL are optional and leave it as of now. ‘Automatically create a registration handler template’.this is going to create a new Apex Class which will handle the user login by using facebook. If the User is not there in salesforce it’s going to create a new user or if exists it’s going to update the user
5.Select Execute Registration As any System admin User. Make sure user is having Manage users permission

Salesforce generated Registration handler looks as shown below. you can update the Registration handler with your own logic.


Map the Callback URL in Facebook

Now you have to go back the Facebook application which you created earlier, then associated your Callback URL in Facebook as shown below.Go back to your facebook application you just created in last steps. Click on Settings in left option bar. Click on Add Platform.

Select Platform as Web Platform. Update the Salesforce callback URL in Site URL as shown below

Testing Application:-

You can test your application by simply pasting Test-Only Initialization URL in browser it will redirect to the Facebook login page.

Adding the Facebook login to My Domain:-

To available Facebook login for all the user, you must need to add it to my domain in Salesforce as shown below.Go to Setup –> Domain Management –> My Domain.go to Authentication Configuration Click edit then Select Facebook as shown below.Save it

After adding it my domain you can able to login into Salesforce by directly using your facebook from your domain login page as shown below.

Now you can able to login into Salesforce by using Facebook. once you select the facebook login it will redirect to the Facebook for login. Up success login in facebook, you will be redirected to Salesforce homepage.


Salesforce Platform encryption Setup

In this blog, I am going to explain how to setup platform encryption basic setup which includes setup your tenant secret keys, Creating an encrypted fields and files, tenant secret key life cycle.

Do we need any special permission?

Before setup the platform encryption, the user need this permission.

Manage Encryption Keys – To create a Tenant Secret keys.
View Encrypted Data – To view the encrypted data.

Generate a Tenant Secret

Platform encryption works based on the Tenant Secret and Master Secret keys. The master secret key is managed by the salesforce and rotates for every release. whereas Tenant Secret is An organization-specific secret used in conjunction with the master secret and key derivation function to generate a derived data encryption key. When an organization administrator rotates a key, a new tenant secret is generated. to generate the Tenant Secret go to Setup, enter Platform Encryption in the Quick Find box, then select Platform Encryption. Select Generate Tenant Secret as shown below . The platform encryption link is under Security Control.

As an admin, you can able to manage the tenant secret keys life cycle like archive and active and destroy as shown below. You can rotate your tenant secret key for every 24 hrs in production.

Encryption on fields and Files

With the new platform encryption, you can be able to encrypt the fields and Files.

What Standard fields are support encryption?

Salesforce support the following standard fields on Account, contact, and Case are encryption

How to encrypt the files?

in order to encrypt the files, go to setup — > Security Control — > Platform Encryption.
Under File and Field encryption check the Encrypted fields and attachment and save it

That’s it. Now you are good to enjoy the platform encryption future

How to create an encrypted field?

Now we are going to create a new custom field on contact called SSN which is encrypted .goto Setup -> Customize > Contact fields –> create a new custom some field SSN with Text data type
as shown below. Make Sure encrypted checkbox is checked. Save the field.


After contact record is created, the SSN values are encrypted as shown below

File encryption looks as shown below.

Sales force Platform Encryption API – APEX

In this blog, I am going to explain how to use the TenantSecret object in salesforce to generate the tenant secret key for Platform encryption.

We are going to build the visualforce page that used to create tenant secret key and view all the existing tenant secret key. Visualforce page looks as shown below

The Page controller is shown below



Visual force page is shown below.


Github URL for the code:-

Salesforce Platform Encryption dislike vs like

Even though salesforce platform encryption is most powerful future it’s having certain limitation. I am going to walk through those limitations and possible solutions.

What fields are supported?

Salesforce Platform encryption support below data types on both standard and custom object Custom fields.

  • Email
  •  Phone
  • Text
  • Text Area
  •  Text Area (Long)
  •  URL
  •  Date
  •  Date/Time
  • Encrypted filed can’t use in custom formula fields
  • You can’t use Schema Builder to create an encrypted custom field.
  • Fields that have the Unique or External ID attributes or include these attributes on previously encrypted custom fields can’t be encrypted:
  • Fields that are used in custom formula fields
  • Fields that are used in an account contact relation
  • On a custom object, the standard Name field can’t be encrypted.

General features limitations? 

  • Criteria-based sharing rules
  • Similar opportunities searches
  • External lookup relationships
  • Skinny tables
  • Filter criteria for data management tools
  • Duplicate Management matching rules
  • These apps don’t support encrypted data. However, you can enable encryption for other apps when these apps are in use.  Connect Offline • • Heroku (but Heroku Connect does support encrypted data.) • Marketing Cloud (but Marketing Cloud Connect does support encrypted data.) • Pardot (but Pardot Connect supports encrypted contact email addresses if your Pardot org allows multiple prospects with the same email address.) • Process Builder • Salesforce Mobile Classic • Salesforce IQ • Social Customer Service • Steelbrick • Thunder • Visual Workflow • Wave


Encrypted fields can’t be used with the following SOQL and SOSL clauses and functions

– Aggregate functions such as MAX(), MIN(), and COUNT_DISTINCT()

– WHERE clause

–  GROUP BY clause

–  ORDER BY clause

We can use below small hints to overcome those limitations.

Hint 1: – Aggregate Result 

 In order to calculate aggregate data on encrypted field use apex code.

Hint 2: – Use SOSL instead of SOQL where conditions 

List<Account> acc= [Select Id ,Name From Contact Where Text__c= ‘123’];

The above query will fail at runtime if this is dynamic SOQL  with invalid strings return an INVALID_FIELD error instead of the expected MALFORMED_QUERY.   However, the Query can be replaced with the following SOSL statement

List<List<SObject> > acc= [FIND ‘123’ IN ALL FIELDS Returning Account(Id, Name, Text__c]

Hint 3: – ORDER BY clause

Instead of using order by clause, you can use custom apex sorting.

Hint 4: – Formula fields. 

you can use Workflows and Apex triggers to calculate the data instead of formulas on encrypted fields.

Platform Encryption with Salesforce


In this blog, I am going to explain the platform encryption and its architecture. It is common practice today to encrypt data Prevent from the unauthorized access. Salesforce Platform encryption 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 are 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 can you 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 that 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.