B2E Stack (application centric)

In this case , we focus on a Business-to-Employee (B2E) scenario with team members using either a mix of native apps installed in cross platform devices (iOS or Android), BYOD, or corporate devices, or web apps run from a web browser as cross platform devices (iOS or Android) or on desktop/laptops.

Use case

A cross-platform Neptune DXP application needs to access resources that ultimately reside in an ERP backend system, such as SAP. Rather than exposing SAP functions directly to the application 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 apps from backend systems using an API gateway to secure entry into the corporate network:

B2E Neptune DXP Mobile/Web apps <→ API Gateway <→ Neptune DXP Microservices <→ SAP Neptune DXP connector <→ SAP

For example, an in-store team member for a retailer uses a Neptune DXP application to adjust the stock seen on a shelf. The application invokes an inventory business service via an API Gateway that orchestrates the adjustment in SAP. Adequate security measures must be incorporated throughout this architecture to:

  • authenticate application users

  • protect the API traffic throughout the entire stack

  • reflect the application user’s name in SAP transaction records for audit purposes

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:

b2estack1

We can summarize the series of security tasks taking place in the following four steps:

  • End User Authentication

  • Enterprise API Authentication

  • Microservice API Authentication

  • ERP API Authentication

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

End user authentication

The steps below run through the security interactions necessary to authenticate a user to a Neptune DXP mobile or web application:

  1. Authentication: After the end user launches a Neptune DXP application they are presented with a sign-in screen to authenticate. The user must provide the:

    • Target company domain associated with the identify provider, for example, an LDAP or Microsoft Entra ID

    • Username

    • Password

      Additional security options may include the use of a pin code supported by Neptune DXP as a form of multi-factor authentication. Another approach would be the configuration of biometric authentication using Face or fingerprint recognition to speed up the process.

  2. Request User Authentication: Once the credentials are obtained the Neptune DXP application will request the Neptune DXP application server to broker the authentication request with an identity provider resource.

    Note if no domain was provided by the user then the application server will validate the user’s credentials against its local user store.

  3. Validate inbound traffic: The request process must of course clear through any edge security implementation you may have put in place such as, Web Access Firewalls (WAF) filtering for DDoS attaches or unwanted traffic origins, Internet or Application Gateway balancing incoming traffic through to your virtual network and of course any corporate firewall implementing strict security checks on all incoming traffic requests.

  4. Delegate user authentication request (IDP): The Neptune DXP application server automatically request the secure validation of the user’s credentials by connecting to the pre-configured Identity Provider (IDP) system.

  5. Validate user credentials (issue Bearer token): The Identity Provider (Microsoft Entra ID, LDAP or SAML) validates the given credentials and if acceptable issues in response a token uniquely associated with the user’s credentials. The token has a limited lifespan which is driven by your IDP’s configuration.

    Note in the case of Microsoft Entra ID or an ADFS implementation a refresh token may also be provided to automatically orchestrate the provisioning of a replacement bearer token upon its expiry.

  6. Respond to application (present Bearer token): The Neptune DXP server propagates the token back to the user’s Neptune DXP application.

  7. Store Bearer token: The Neptune DXP application in turn stores the token in its local secure cache to use in any future re-authentication request. This alleviates the need to re-expose the user’s credential over the internet limiting the likelihood of them being compromised. Note the application cache is encrypted by implementing the Advanced Encryption Standard (AES) utilising a 256-bit encryption key.

  8. Authorise user: The user accesses the Neptune DXP application Launchpad and, if authorised, use the Inventory application they to progress with the stock adjustment in mind.

Enterprise API authentication

The steps below run through the security interactions necessary to proxy to API calls to a Neptune DXP Microservice from an API Gateway:

  1. Application API request via API gateway: The application then orchestrates the API request to carry out the stock adjustment by invoking a service endpoint exposed for consumption by the API gateway. As the application resides in the public domain, it is treated as anonymous internet user, and must therefore 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 grouped the stock adjustment endpoint (e.g. /store/{id}/stocks) into an API product called, Inventory API, and generated a unique (API) key specific to the application. Alternative mechanisms may also be utilised such as basic authentication or OAuth 2.0.

    Note the API key may be stored, securely, locally in the application using a Neptune DXP data table. However, it is recommended that a Privileged Access Management service acting as a secrets vault is utilised instead as a more secure mechanism.

  2. Package Bearer token: A crucial step is the addition of the user’s bearer token issued by the Identity Provider when logged in the API request. This will be used by the microservice to re-authenticate the user against the IDP (see step below). The bearer token is programmatically recalled from the secure cache and added as custom header in the API request.

  3. Validate API key: The API Gateway will validate the API key and performs any additional security policies configured (for example, throttling, CORS, transformations,).

  4. Proxy API request (Neptune DXP inventory microservice) The API Gateway will then proxy the API request to the underlying API of the Neptune DXP microservice designated to handle the stock adjustment, e.g. an Inventory Microservice.

Microservice API authentication

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

  1. Authenticate app user (Neptune DXP inventory microservice): The Neptune DXP inventory microservice will automatically route the API request received to a nominated NodeJS server script to handle the API request. Before any tasks, specific to the stock adjustment, are carried out the script must parse the request header to recover the app user’s Bearer Token and use it to request from the IDP to authenticate the app user into the Microservice.

  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.

ERP API authentication

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

  • Authenticate user  via ERP (Neptune DXP SAP connector): The Neptune DXP SAP connector will consume the user certificate generated by the Neptune DXP Microservice and provide it to SAP for validation.

    Note as a pre-requisite SAP’s Single Sign On (SSO) built in mechanism must have already been configured to associate the SAP username with their corresponding app username.

    During the validation process, SAP will parse the certificate to extract the app username and will then attempt to match as an alias to its corresponding SAP user account. If successful, the Neptune DXP connector is authenticated as the SAP user and the transaction executed is recorded against it enabling full traceability. A similar approach can be adopted with all ERP system supporting authentication through the X.509 protocol such as Oracle EBS.