Written by Jon Duelfer
Google’s Cloud Storage offers great flexibility and security for your data, whether it is data that needs to be tapped by today’s most demanding applications or even data that you want to store in archives. As Salesforce Consultants, this is a great option for our clients as they want to move all of their data into the Cloud, yet get a well-priced storage solution that is flexible, secure and can be easily integrated with their Salesforce Platform.
Some examples of data that could be migrated into Google Cloud Storage:
- Documents (PDFs, Word, Spreasheets)
- Archived data
For clients that have massive storage requirements, such as documents for architecture firms or images for large real estate agencies, Salesforce’s storage is not their ideal storage solution. This is because Salesforce sepecializes in indexed data that can be easily attached to records to store relationships between many objects. Instead, for massive dumps of documents and data, a specialized storage solution like Google Cloud or AWS should be integerated with Salesforce.
Integration with Google Cloud Storage on Salesforce’s platform is seamless and powerful. However is not as straightforward as many API integrations, due to Google’s strict adherence and requirement of the OAuth 2.0 Authentication. It is however one of the most secure authentication frameworks on the web, and after the intial development of the authentication structure, your organization will greatly benefit from the security, confidentiality and speed of the integration. In this tutorial we will outline the big picture of how to integrate with Google Cloud and then go into the nitty gritty details of how to implement it using the JWT authentication web standard.
Docs for authenticating with the Google Storage Platform can be found here. This tutorial will be based upon the integration of Salesforce and Google Storage using a Service Account. We will not, however, go into detail in how to setup a Service Account within the Google Storage Console, but will instead focus on how to integrate from Salesforce.
Google’s platform requires OAuth 2.0, and there is no other form of authentication allowed. OAuth 2.0 is the replacement of the obsolete OAuth 1.0 authentication framework, which guarantees a secure connection between a client and the server by not sending password-based credentials across networks. Instead, the “credentials” will be held within a private key generated by Google that you must download into your computer and upload into Salesforce, assuring that this key is not shared over insecure networks.
Generate Private Key
You will need to generate a private key for the service account. To perfom OAuth authentication in Apex, we will need a .jks private key. Google doesn’t offer us this format right off the bat, but you can use OpenSSL to convert the PKCS12 private key to JKS using Oracle’s official documentation.
Once you have the private key converted to JKS, you will have to upload it to your Salesforce organization. In the Setup menu, navigate to:
- Setup > Certificate and Key Management
Once inside the Certificate and Key Management page, you have to upload the JKS private key stored in your computer and provide the password that you entered for the Keystore during the conversion. You can imagine this as your organization’s password for integrating with Google Storage. Note: I used the same password that Google supplied for the PKCS12 private key for the keystore.
Once you have uploaded the token to Salesforce, you will have to write an Apex class that encapsulates the logic for fetching an access token from Google. In OAuth, you never send credentials over open networks, but instead send access tokens during requests. These access tokens (you can imagine them as temporary passwords) will expire within a certain number of time, so everytime you make a callout, you have to catch the possibility that the access token was exipired and your request was rejected by Google.
Note: replace double quotes with single quotes (our syntax highlighter doens’t support Apex code yet).
This class encapsulates the retrieval of an access token, whether it already exists as a custom setting or requires the fetching of another token from our Google Storage’s endpoint. In the case that we have to fetch another token, we have to build a JSON Web Token. If you have never worked with JSON Authentication like this before, there is nothing overly-complex about this code. You are really just sending your JKS private key in JSON format with additional meta information to secure the token request.
Then, you need to develop the full REST callout. I like to extend a common virtual class for all of my callouts:
This code can then be called like the following: