1. Integration Guide
  2. Outbound HTTP Integration

Outbound HTTP Integration

HTTP is used as the transport protocol for both the original HTTP POST and new REST communication methods that can be selected by the workflow process which triggers the outbound message. REST provides access to more HTTP methods e.g. PATCH and DELETE, whereas HTTP POST as its name suggests, is limited to just HTTP POST.

Therefore, many of the same configuration options apply to both. Use cases where there are differences will be highlighted explicitly.

Security

There are multiple supported approaches for HTTP authentication:

  • None (Default).
  • HTTP Authentication (Basic)
  • OAuth 2.0 – Client Credentials (only available for REST com method)

The External System has an Authentication Type option in the user interface where the selection can be made.

No Selection

When no selection is made no credentials will be passed to the external URL.

External Systems migrated from a previous version will not show any selected option. However, if a username and password had previously been specified, this will be equivalent to HTTP Authentication (Basic). In these cases, it is recommended to explicitly select this option to declare this requirement to avoid any future confusion. For example, if there is a genuine reason not to send credentials then any values in the present Username and Password fields would also have to be removed.

HTTP Authentication (Basic)

The username and password credentials from the External System, if present, are used as the HTTP Basic Authorization authentication properties on the outbound HTTP connection. HTTPS URLs are also supported. These credentials are sent using the standard Authorization HTTP header as defined in RFC 7617.

OAuth 2.0 – Client Credentials

OAuth 2.0 is the de facto standard for authentication and authorization for REST APIs and is now available as an option for outbound Transmission XML when sent using the "REST" communication method.

The roles involved in the protocol are:
  • Resource Owner: The entity who owns and controls who can access the protected resource. The resources can be limited by "scope".
  • Authorization Server: The entity trusted by the resource owner to apply the authentication and authorization process.
  • Client: The user or application requesting access to the protected resource.
The protocol works by running the following stages:
  1. Client submits Authorization request to obtain a token.
  2. Client requests resource and passes token.
Each step above requires its own URL to process the request. Additionally, the Authorization Server can use one of a number of protocols to run the process of receiving an access token:
  • HTTP Authentication (Basic): This must be supported and is expected to be the most common use case. This option also uses the Username, Password and Application Scope fields to pass as the Client Credentials for the authorization.
  • HERE OAuth 1.0 Signature: This is specific to the HERE REST API (not covered here).