Endpoint

• The web service endpoint that is the root of all queries

• This is typically of the form protocol://resource e.g. https://api.google.com

• This endpoint can be extended when the connection is used to create an adaptor

• No trailing slash or question mark is necessary here

Constant Query Parameters

• This is the list of query parameters that will not change or be overridden in the adaptor 

• Typical use is for an api key that does not change

• Additional query parameters can be added to the adaptor

• Click Add Query Parameter to bring up the menu to add a query parameter

• Click on the icon for an existing query parameter to delete it

Constant HTTP Request Headers

• This is the list of HTTP request headers that will be sent for all requests for any adaptor that uses this connection.

• The typical use for unchanging headers like 'Content-Type' 

• They are constant (cannot be dynamically set).  If wanting a dynamically set header, they can be set on individual adaptors

• Click Add HTTP Request Header to bring up the menu to add an HTTP request header

• Click on the icon for an existing HTTP request header to delete it

AWS API Gateway Signature

When the engine receives an authenticated request, it creates the signature using the authentication information (AWS Credentials) contained in the request. If the signatures match, the AWS service processes the request. Otherwise, it rejects the request.

The signature includes information about the request, such as the Service string, Region, and AWS access key ID. The API Gateway verifies the signature by comparing it to a signature that it generates using the same information and AWS secret access key.

To calculate the signature following inputs are mandatory:

• Service: Enter the service string for the signature.

• Region: Select the required region you are trying to connect.

• AWS access key ID: Enter the AWS access key ID that is unique to your AWS account and is used to associate requests with your account.

• AWS secret access key: Enter the unique AWS secret access key used for signing requests and verifying the authenticity of the sender.

The signature is generated using a combination of the above details, HTTP request headers and query parameters.

Related Topic: 

• REST Web Service GET Method

• REST Web Service POST Method

• REST Web Service PUT Method

• REST Web Service DELETE Method

• REST Web Service PATCH Method

Mutual Authentication

Mutual Authentication is an optional additional security feature provided by Xponent. Mutual Authentication is off by default for REST web service connections. 

Mutual authentication or two-way authentication refers to two parties authenticating each other at the same time. This is an added security protection that is often implemented in internal business applications. By default, the Transport Layer Security (TLS) protocol only proves the identity of the server to the client using X.509 certificate, and the authentication of the client to the server is left to the application layer.

TLS also provides client-to-server authentication using client-side X.509 authentication. This requires the provisioning of the certificates to the clients. Mutual TLS authentication (mTLS) is widespread in business-to-business (B2B) applications as it ensures that only a limited number of programmatic and homogeneous clients are connecting to specific web services, the operational burden is limited, and security requirements are greater.

In order to allow a client to communicate with a Mutual Authentication protected endpoint, Xponent Engine's certificate authentication chain must be added to the server's configuration for trusted client certificate chains. Xponent's public certificate will be provided in the bundle as well.

Obtaining The Public Certificate

The first step in setting up Mutual Authentication is to obtain the proper certificates from Xponent to register with your gateway server or firewall. To do this, email support@xponent.com to request the certificates for Mutual Authentication. Our support team will reach out to you with the necessary certificates for your account.

Configure Web Server / Gateway

Once you have the client-side certificates, they need to be registered with your web server or gateway. This process may differ based on your server configuration, but the systems administrator for the business application should be familiar with how to register new certificates.

Enable Mutual Authentication in the REST Connection

The next step in setting up Mutual Authentication is enabling the feature for a specified environment and REST Web Service connection. This ensures that Xponent will properly authenticate via certificate with the endpoint it is targeting.  

• Click the Project Settings tab and then the Connections tab within your project

• Select the REST Web-Service Connection and Environment you want to enable Mutual Authentication (Please note this feature is only available for REST Web-Service connections)

• Type in the Endpoint that you would like to connect to

• Select the "On" Radio button under the "Mutual Authentication" Header and click Save Edits

Test Mutual Authentication is Working Properly

The last step is to ensure that outbound requests from Xponent are properly authenticated with the client. To test this, set up a graph that uses the REST Web-Service connection and run the graph visually in the environment that is configured for Mutual Authentication. If the connection succeeds, then Mutual Authentication is working correctly. If it fails - typically with a 401 Unauthorized response, the Visual Testing Console will display the error message that was received when trying to call the internal business application.