=Gateway Synchronous Delegate

This document provides more information about the Gateway Synchronous Delegate functionality. This functionality is intended for on-premises systems that want to work with the OIG Gateway to integrate with applications synchronously, but cannot directly use the facilities provided by the OIG Gateway to do so. The OIG Gateway inherently asynchronously processes exchanges. It does, however, provide in the means to process exchanges seemingly in a synchronous fashion. This does require the calling system to follow a Post-Redirect-Get pattern, which means that it needs to be capable of dealing with HTTP 303 (See Other) headers. Not every calling system is able to deal with this however, for instance because it is a legacy system. In that case that system can use the OIG Agent’s synchronous delegate functionality. Effectively, this delegate passes on a synchronous blocking request from the calling system to the OHI Gateway. This delegate is capable of dealing with the aforementioned Post-Redirect-Get pattern.

Calling the Synchronous Delegate

The OIG Agent exposes a specific REST endpoint for this functionality: <tt>/syncdelegate/{code}</tt>. The agent subsequently routes this traffic to OIG Gateway under the type: <tt>integration</tt>. Effectively, this means that the OIG Agent becomes a component that invokes a regular integration call to the OIG Gateway. You access the OIG Synchronous Delegate through HTTP Post method. It requires the submission of a payload. So when there is an integration (of type integration) configured in the OIG Gateway that has a code oec, calling the OIG Agent Synchronous Delegates translates to:

OIG Agent Synchronous Delegate Call	OIG Gateway Integration Invocation
/syncdelegate/oec {headers} {payload}	/api/exchanges/integration/oec {headers} {payload}

In the above table there is mention of {headers} and {payload}. In general, all the information that is provided to the delegate is used in the call to the OIG Gateway. With respect to the {headers}, secure sensitive information (Authorization and host) are not passed along.

With respect to the response - the delegate relays the HTTP response code, headers and payload (as controlled by the aforementioned desired response type) it retrieves from the OIG Gateway back to the caller.

Calling the delegate requires a valid OAuth2 token

The synchronous delegate endpoint only accepts requests that contain a valid OAuth2 Bearer token that is passed as part of the Authorization HTTP Header. In order to validate tokens, the following properties need to be configured:

Property	Description
agent.oauth2.issuerURI	Issuer URI for token validation. This is the value that is listed as 'issuer' value in the OpenID Provider metadata (see: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata). And it must be identical to the 'iss' Claim value in ID tokens issued from this Issuer.
agent.oauth2.clientId	ClientId or audience for token validation. the 'aud' (audience) Claim value typically contains the client_id value registered at the Issuer identified by the 'iss' (issuer) Claim as an audience (see: https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).
agent.oauth2.jwkSetURL	JWK Set URL for token validation. See: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
agent.oauth2.jwsAlgorithm	Name of the JSON Web Signature (JWS) algorithm that was used to sign the token. Optional, defaults to RS256.