This video shows how to configure the Google Cloud Translator service for the ServiceNow Dynamic
Translation feature by creating certificates and key providers to authenticate the connection.
You can skip to these topics from the YouTube description for this video
When you’re setting up connection aliases, you provide a password, URL link, and API
key to set up the translation service. But Google Translator requires a bit more
setup. This is because your Google Cloud account comes with a specific JSON code that
helps keep your information encrypted. You’ll need to extract the key values of
this encryption to create a secure connection alias in your instance.
To authenticate a connection alias with Google Translator, you’ll need to create a Java Keystore
certificate, using the key values in the JSON file. Creating this certificate will enable
you to create a X.509 certificate, and JWT keys to support JWT identity providers.
These items help generate the OAuth Entity profile for your account,
which in turn generates OAuth 2.0 credentials. These credentials, along with the connection
attributes and alias values, enable the Dynamic Translation feature to use Google Translator.
We have a lot to cover, so let’s get started.
Here, the product documentation describes how to download the JSON file from your Google account.
It even provides an example of a JSON file and the information you’ll need to extract. We’ll refer to
these steps as we go through the process. Once your Google Cloud account is set up,
download the JSON file like we’ve done here. In this file, you’ll find the private ID,
the private key, the client email, and the client ID. You’ll need all these values to
set up the certificate. They’re embedded in the script in every JSON file.
First, copy the private key. We’ll need to remove ,or unescaped,
all back-slash N characters from the key. Using a JSON formatter can make this process easier.
Then we’ll save this private key script as a dot-PEM
file. We’ll use this key later to create the certificate.
Next, we’ll copy the client certificate URL from the JSON file and paste it in the browser URL
field. There are two certificates in this URL. We need to extract the one that corresponds to
private_key_id certificate. We’ll copy this certificate…
And just like we did with the private key, we’ll unescape all back-slash n characters,
and paste it in its own dot-PEM file.
Make sure to name this file “certificate.pem” and the private key file “private key.pem”.
Next we’ll copy the open-SSL command here on the doc page, and paste it
here in Terminal to create a PKCS 12 file. In the script, be sure to add the paths to the
certificate key and the private key. We’ll add certificate.pem here…
Private key.pem here…
And certificate.pem again here. Here, we’ll create an export password.
And now we see it has created a PCKS 12 file with the name “testkeystore.p12”.
On the doc page, we’ll copy the keytool command…
And we’ll paste it in Terminal here. This will be our PKCS 12 file,
and this will be our JKS file. Next we’ll create and verify a
destination keystore password… and re-enter our source keystore password as before.
And now, our Java KeyStore certificate has been generated, containing the key files for setting
up the Google Translator connection. Now we’ll use the JKS certificate to create
a X.509 certificate. We’ll need that to set up the connection for Google Translator.
We’re logged into our instance as system admin.
We’ll go to Certificates… Where we can create a new x.509 certificate.
We’ll call it “Google certificate”… And we’ll attach the JKS file we just created.
For Type we’ll choose Java KeyStore,
and we’ll enter the password we created for our JKS file.
We’ll save the certificate… and validate the key store in our instance.
Now, we’ll generate a new JWT key for this certificate.
We’ll go to JWT keys and create a new key. Let’s name it Google, and link the Google
certificate we just created for the signing keystore.
We’ll type the password for the JKS file here in the Signing Key field, and save the record.
Now, we need to set up the JWT Key provider.
This is located under System OAuth along with the JWT Keys.
We’ll create a new provider record and use the
Google key we just created for the signing configuration.
In the new record, three claims have been created. One for AUD, one for ISS, and one for SUB.
We can use these claim values to generate the claims as active.
Here in the claim value field for AUD, we’ll add the URL value from the documentation.
For ISS, we’ll copy the client_email value from our JSON file,
and paste it in the claim value here.
We don’t need SUB to run the JWT provider. But we do need to create one custom claim.
In the Custom Claims related list, we’ll create a scope claim for all customers to see.
We’ll copy the URL for this scope claim in the documentation…
and paste it in the Claims Value field.
Let’s review what we’ve done so far: We created our Java KeyStore certificate
from our Google Cloud JSON file, and we also set up the x.509 certificate,
the JWT key, and the JWT provider to connect this Google account to Dynamic Translation.
Now, we can configure a connection and credential for Google Translator.
We go to Connection and Credential Aliases, and open up our GoogleTranslation connection alias.
The record shows us three attributes we need to provide: location, project_id, and version.
We’ll make the location “global”. For the project_id,
we’ll copy dynamic translation in the JSON file and paste it here.
We’ll open the credential field, which is Google OAuth 2.0, and edit the record.
We’ll open the record in its own tab. All the fields are filled by the application registry,
except for the JWT provider. We’ll type “Google JWT provider” and save the record.
This completes the setup for our
connection with the Google Translator service. If we ever need to check if the connection
is still verified, we can click here under Related Lists to receive an OAuth token.
And that’s it. Our Google Translator connection is ready to go.
For more information, see our product documentation, knowledge base, or podcast.
Or ask a question in the ServiceNow Community.