Secure service discovery

Neptune DXP supports the onboarding of APIs compliant to the Open API 2.x/3.x specification. There are no special security adaptations needed other creating an API authentication policy and assigning to the external API. This then allows, at runtime, for Neptune DXP scripts making an API to automatically inject that policy into the API call being made to authenticate with the external service.

External APIs can be onboarded either in a:

Whilst use of external APIs in the application server is freely available it should be used judiciously. An expansive utilisation of external APIs in apps will introduce strong coupling logic. This may be fine for generic APIs such as currency exchange rate convertors. For more complex use cases such Fulfilment APIs abstracting carriers and/or freight brokers it may warrant the use of a Neptune DXP microservice.

In this case the use external APIs in the application is discouraged and the implementation of a microservice that acts as a proxy to multiple carrier APIs, composing requests to produce sanitised and carrier responses, acts as a de-coupling mechanism. This then allow for the addition or removal of carrier APIs without impacting the application’s implementation. If the carrier API were instead imported directly in the application any change to the carriers employed or their API implementation will trigger change to the application. In turn this may be more costly to refactor and test if it reaches a wide audience.

Each Neptune DXP Microservice allows for other Neptune DXP runtimes to be discovered as a remote system. Upon discovery the authentication credentials must be specified to enable automatic access to that remote system. A typical use case for this mechanism is for discovering Neptune DXP microservices without having to implement a service mesh:

The image shows an example of an application that places an order, which is handled by the Order Microservice. A Payment microservice abstracts the process of a payment to achieve the desired decoupling between unrelated functions, that is, ordering vs. paying. By extension an additional microservice could be implemented to handle the payment process. With this approach the Payment service acts as an aggregator of one of more payment processors. It sanitises the idiosyncrasies of individual payment processors and instigate a corporate payment standard that remains unchanged as processors are added or removed over time.

In this example, the Neptune DXP Service Discover setup will look as follows:

To secure such complex synchronous orchestration sagas the discovering service must declare an authentication mechanism allowing its API to authenticate remotely. There are two supported methods:

Basic Authentication carries the risk of the generic user’s credentials of being exposed and requires the use of HTTPS, for service-to-service communications, to prevent that. The use of certificates mitigates this but then requires their periodic reset, which can be onerous when many services are in operation.

A Neptune DXP application server or microservice and connect directly to the Neptune DXP SAP connector by discovering it as a remote system. The discovery of the Neptune DXP SAP connector from the Neptune DXP application server is discouraged if there is a desire to de-couple the front end from the SAP backend. Instead it is encouraged for Neptune DXP microservice to access SAP by discovering the Neptune DXP SAP connector and abstract SAP’s opinionated operations from the front-end. Upon discovery the Neptune DXP Microservice must declare the authentication mechanism employed to sign in to SAP when processing API requests. There are two supported methods:

The Principal Propagation mechanism eliminates the need for the Neptune DXP microservice to be cognizant of the underlying SAP user account. Instead a self-signed X.509 certificate is generated in the Neptune DXP microservice and a username is declared against one of the certificate’s elements for example, email address. This can be fixed or inserted at runtime, see B2C Stack (web centric). The certificate is the imported into SAP and mapped to an SAP user. As a separate process the Neptune DXP microservice must import an SAP API, generated by the Neptune DXP SAP connector, abstracting an SAP class. The Neptune DXP microservice certificate created earlier can then be used to define an API authentication policy that can be assigned to the Neptune DXP SAP connector API. Each time the Neptune DXP connector API is called a one-time certificate is generated attaching the username (static or dynamically injected). When the API call is sent to SAP it will parse the certificate to extract the username. After mapping it to the corresponding SAP user it will use these mapped credentials to sign in to SAP.