Quick Integration

For a quick start, we recommend using our integration wizard that covers the most common use case that is secure collect and exchange of sensitive data with 3rd parties. Click on Integration button and choose Wizard among all the other options that can be useful in the future. Want to explore other integration methods now, go here.

'quick-integration-wizard'

Securing Inbound Connection

To secure traffic going to your systems, you need to create your first inbound route. To do this, enter your Upstream Host. It is required to route traffic from your clients or frontend.

Enter the address of your server, e.g. https://api.mycompany.com.

Your data flow:

  • BEFORE: client.foo.com → server.foo.com
  • AFTER: client.foo.com → tenantid.sandbox.verygoodproxy.com → server.foo.com
  • ALTERNATIVELY: you can load your client website/app through the route. It is useful if your client and backend do not communicate via API. We can provide a CNAME to white label this when you’re ready to use for production.

In this way, our inbound route will direct your inbound traffic between your client-side, the VGS Vault (where sensitive data is stored), and your backend systems.

'routing-traffic'

As you routed your inbound traffic through VGS, we can introspect on it and secure your data. Next step is to post data to that URL, and you’ll be provided with a log of the payload. You can use a provided curl for sample integration. Just copy and run this curl request in your Terminal.

Click on the log entry and a modal will pop up showing you general information on the request. You may get more insights on the contents of the payload by clicking through the``General|Headers|Body`` tabs and their Request|Response buttons.

Click “Secure this payload” to begin securing your data by creating filters. And even though the data here is just ACC00000000000000000 let’s redact it! Here we only have one JSON item, but nested JSON or JSON lists will also populate, select as many items of the payload as you need to secure and safely store.

Let’s quickly review the dropdowns on the modal:

  • The first dropdown is the Operation redact or reveal. This Operation can be performed on request OR response. For this guide, we’re just doing requests, but we could also redact and reveal responses just as easily.
  • The second dropdown is Storage. We have two storage options: Persistent and Volatile. CVVs and PINs must be stored volatilely (in memory) and have a Time To Live of 1 hr. All other data can be stored persistently. It’s important to note that your “Storage” type needs to match on reveal (we’ll see this on Outbound Connection ).
  • The third dropdown is the type of alias VGS will return to your server. We have different Alias Formats. The first one is a proprietary alias. This is best used for non numeric data (in fact it must be used for non-numeric because the other formats are strictly for numbers).

Now, go ahead and send a request and check it on the Logs page on the side menu bar. Wait a minute. It looks almost the same! That’s the general information on logged request. To see what your server will receive, click on the Body tab.

'alias-created-inbound'

There we go. You have now protected your server from receiving any sensitive information without changing any code.

Note

  • The echo server is for the test data only. It’s a security issue using it in Live.
  • You should have only one upstream destination for your inbound connections. If you used echo server as a destination for your requests once and now creating another route, consider deleting the one with the echo server. Learn how to configure multiple inbound routes.

Securing Outbound Connection

When your inbound route is already set up, go to the Wizard that will automatically trigger quick integration flow for securing your outbound traffic.

'outbound-wizard'

To route traffic from your server to the 3rd parties, you will need access credentials that were generated at the very beginning. If you forgot to save them - no worries, create a new pair in the Vault Settings page.

As you can see we have some environmental settings that you can set on your server to run your outbound routes through VGS. If you just want to test the functionality, there is a curl available. If you do decide to go ahead and set up an environmental variable in Python/Ruby or any language/framework of your choice, you’ll need to add our CA cert to your Trusted Certificates (this is self issued to establish a trusted secure connection between you and VGS, not third parties).

Once traffic is detected you’ll be brought back to the logger, and you’ll notice the request you just made already populated.

'outbound-logs'

Click on on the log with payload, like the Securing Inbound part, and the modal will, once again, pop-up.

Let’s look at the “Body” tab - here’s the payload we’re about to reveal. Click on “Secure this payload” button.

'alisa'

Notice that the json keys are the same here, but that does not matter. You can add the alias to any payload and give it a different name - maybe one required by a third party api and it will work just the same.

'secure-payload-outbound'

Once you have selected your options (that match how you redacted it Storage and Format). Go ahead and click “Secure this payload.” After, the confirmation about securing of outbound traffic will pop-up.


Now let’s send an actual alias through the outbound route we just created by replace the slug “ALIAS” with the alias returned in the securing inbound connection part of the guide to demonstrate the reveal process.

Once again we’ll see the details and some general information on request. Switch to the “Body” tab and you’ll see the raw request you sent compared to what your third parties will receive.

'alias-reveal'

You now have taken sensitive information, swapped it for an alias on inbound, and swapped it back on outbound, keeping sensitive data off your system.

If you’d like to see some working apps integrated with third-party APIs, check out our example integrations.

Additional Settings

Advanced Preferences you might want to set up:

IP whitelisting to restrict IPs and IP ranges that requests originated from. The IP address the request is made from will be matched against a comma-separated list of IPs or CIDRs. For example 1.2.3.4/32, 192.168.0.15/24

CNAMEs allows you to use your own domain as an alias to verygoodproxy.com. Thus your users may seamlessly transition between VGS and you without recognizing that the content exists on two separate domains. To request custom hostname provisioning: * Create a CNAME pointing your address, for example, secure.your-domain.com, to either sandbox.verygoodproxy.com or live.verygoodproxy.com. Then contact our support at support@verygoodsecurity.com to request provisioning of a TLS certificate.

Mutuals TLS allows the upload of certificates to establish a trusted connection with the third-party services (that demand mutual tls type of connection) like Visa and MasterCard.

Where next?

Now that you’ve tried our quick integration, you might want to check out:

vgs-collect

vault-api