The following is a step-by-step walk through on how to use LivePerson MTLS service.

Before you start (initial introduction and terminology)

Authorization - Unless specifically indicated, the authorization mechanism used is a Bearer (oAuth2). Otherwise, it is an AppKey (oAuth1).

1) Log into Conversational Cloud using the Login Service API. Provide a username and password (for an administrator user) and receive an authorization token (Bearer) in return. Use this token as your authorization header for any request requiring a bearer in the future.

2) Domain - Unless mentioned otherwise, domain refers to the MTLS domain. To get the domain, you can make a simple call to the CSDS endpoint (GET method). For example:{accountId}/service/baseURI.json?version=1.0

This returns a list of account domains, the mtls domain is under the 'mtlsGateway' value (for va-a, it is for example). The MTLS documentation might refer to ac-common or Gen2 domain. These values can be taken from the accountConfigReadWrite key in the above request.

A note on Create/Read/Update/Delete usage — Following the REST protocol, POST is used for creating a new entity, PUT to update, DELETE to delete and GET (where applicable) to read.

Step 1 — Configuration

Follow mTLS Self Service

Step 2 — Use at runtime

If all previous steps were successful, runtime methods can now be used. The runtime includes mapping and forward methods.

Actions to take

  • Mapping method - This method receives serviceName/url in body and siteId passed in url. It returns for each triplet whether a certificate is configured for it. Use this method to make sure your certificates are configured properly, Since mtls is throttle protected this method is used to verify that mTLS is configured for the supplied parameters. The goal of this method is not to submit regular TLS requests through the service (using up bandwidth), even though it is possible.

  • Forward method - the request will be mTLS wrapped using the certificate fetched. The certificate is fetched using the provided parameters (accountId/serviceName/url). The request is then forwarded to the LP-forward-url specified. The response will return as if contacting the remote endpoint directly but will be authenticated, its identity confirmed via the certificate.