B2C Stack (web centric)

In this case, we focus on a Business-to-Consumer (B2C) scenario with customers shopping through a web store run from a web browser on cross-platform mobile devices or desktop/laptop computers.

Customers may have named accounts natively supported by the Ecommerce engine driving the web store without the need of an ERP system for account management. The company’s ERP system is nonetheless utilised but mainly to support commercial transactions such as order management.

Use case

The web store needs to access resources that ultimately reside in an ERP backend system such as SAP. Rather than exposing SAP functions directly to the Ecommerce engine an abstraction service layer re-casting SAP specific capabilities as general business services is preferred. The required architecture is a typical microservices driven architecture de-coupling the web store from backend systems using an API gateway to secure entry into the corporate network:

Ecommerce <→ API Gateway <→Neptune DXP Microservices <→ SAP Neptune DXP connector <→ SAP

For example, a customer places an order in the webstore. After payment is complete the web store invokes an order business service via an API Gateway that orchestrates the order placement adjustment with the underlying ERP system, in this case SAP. Adequate security measures must be incorporated throughout this architecture to protect the API traffic throughout the entire stack.

Neptune DXP security architecture

A series of steps are taken to authenticate access to resources at various levels to ensure only valid users can perform stock adjustments and that their actions are recorded for traceability:

secusecase2

We can summarise the series of security tasks taking place in the following three steps:

  1. Enterprise API authentication

  2. Microservice API authentication

  3. ERP API authentication

Let’s unpack these to construct a more detailed narrative on how this can be implemented.

Enterprise API authentication

The steps below run through the security interactions, necessary, to proxy API calls to a Neptune DXP Microservice from an ecommerce engine used to publish and operate a web store:

  1. Web store API request à API gateway: The web store orchestrates the API request to carry out the order placement by invoking a service endpoint exposed for consumption by the API Gateway. As the web store resides in the public domain it must authenticate with the API gateway to ensure it’s a valid requester. In this scenario, let’s assume the chosen authentication method is via an API key.

    Note during the implementation of the API service the API developer may have created the order placement endpoint (for example, /orders) into product called Customer Order Management API and generated a unique (API) key specific to the web store. Other mechanisms may also be users such as basic authentication or OAuth 2.0.

  2. Validate API key: The API gateway validates the API key and performs any additional security policies configured (for example, throttling, CORS, transformations).

  3. *Proxy API request (Neptune DXP inventory microservice): The API gateway should then proxy the API request to the underlying API of the Neptune DXP microservice designated to handle the order for example, a customer order management microservice. The API Gateway will inject the credentials of a local generic user setup in the Neptune DXP Order Microservice to authenticate the API Gateway to execute its API endpoint utilising the basic authentication mechanism.

Microservice API authentication

The steps below run through the security interactions necessary to authenticate to a Neptune DXP Microservice API and proxy API calls to the Neptune DXP SAP connector:

  1. Authenticate user (Neptune DXP inventory microservice): The API request is automatically authenticated against the Neptune DXP Microservice local user store, referencing the generic user credentials supplied by the API Gateway. To eliminate the possibility of a malicious user hijacking the generic API user account access to any Neptune DXP functions should set to None. This means that the generic API user is only useful to authenticate the API gateway into the microservice and not for any tasks in the Neptune DXP microservice environment. This precludes access a malicious physical user without impacting the operation of the microservice or the execution of its APIs.

    The Neptune DXP Order Microservice will then automatically route the API request received to a nominated Node.js server script to handle the API request.

  2. Neptune DXP microservice internal tasks: At this stage the Neptune DXP microservice may, optionally, perform various tasks such as store data in its local database (for example, an audit journal of the request), orchestrate other services (for example, to validate the request), or issue asynchronous events that may be consumed by other services or systems.

  3. Proxy API request, ERP (Neptune DXP SAP connector): Once these tasks are completed the microservice may initiate a proxy request (via script) to a backend ERP system that will ultimately process the customer’s order. In this case it is an SAP system with a Neptune DXP SAP connector installed allowing access to SAP underlying order creation services.

    The call to the Neptune DXP connector will automatically generate a onetime X.509 certificate specific to the app user carrying their username in as element in the certificate and pass it on to SAP in the API request.

    Note As a pre-requisite during design time the microservice will have onboarded the SAP API and associated it with an X.509 certificate policy configured to automatically inject the app user’s name as a element in the certificate.

    The calling script will automatically reference the pre-configured authentication setting stored in the Neptune DXP microservice where the SAP Neptune DXP connector is discovered as a remote system.

ERP API authentication

The steps below run through the security interactions necessary to authenticate to the Neptune DXP SAP connector:

  • Authenticate user, ERP (Neptune DXP SAP connector): The SAP Neptune DXP connector handles the authentication of the API request using the username and password provided by the API request received from the Neptune DXP Microservice and processes the order placement function.

    Note the use of basic authentication means that the request must be a generic user.