Runtime security

Neptune DXP supports multiple authentication mechanisms through native integration with the following identity providers:

Once users are authenticated their user account is used as the basis to establish the level of access to Neptune DXP runtime apps and functions. To facilitate a fine level of access, but also to enable the segregation of duties, the Neptune DXP platform implements the following authorisation model:

Let’s consider a case study concerning a typical Finance Accounts Payable (AP) business unit to put the above, somewhat abstract, elements into a real-life context.

In our case, the AP team has been experiencing an increasing volume of request from multiple warehouse distribution centres (DC) to initiate small charges to transportation companies when they breach their agreed SLAs, for example, late truck arrival, incomplete orders or damaged goods. To deal with this problem the AP team has commissioned a solution to automate the process of invoicing transportation companies (treated as vendors) using the following Neptune DXP apps:

The user community within the AP and DC functions are organised into general roles representative of their daily duties but not strongly coupled to their organisational positions:

These roles are then organised into groups to facilitate access to the apps:

When a user is created and assigned to a group, they will inherit all the roles associated into that group. This eliminates the need for repeat roles assignment to individual users. In the context of a large enterprise a user group is likely to have multiple roles some function whilst many will be for cross-cutting concerns such as health & safety, security, HR attendance.

With the apps built, the following Launchpad facility is created to manage access to the vendor charges process:

It composed of three tile groups that will host apps inside individual tiles:

Vendor Charges Launchpad composed of:

The above model allows for DC Supervisor to enter charges against their haulier vendors. AP Specialist then verify them and pay them. If a charge is over a maximum threshold an AP supervisor can clear it or reject its payment and finally the AP specialist can onboard a vendor contact to email them a charge invoice along with a weekly statement.

Neptune DXP’s Role based authorisation model allows for the definition of fined grained access to apps whilst minimizing the work required at user level. Coupled with the integration to an Identify Provider such as Microsoft Entra ID means that a user and its associated group can be automatically claimed at the time of logging into the Neptune DXP app, including changes to their user group assignments. The bulk of the authorisation work is then limited in structuring the application Launchpad hosting the apps and the access rights to individual user roles.

The Neptune DXP supports the self-registration users that have an email with a specific domain name. For example, if your company employees have corporate email addresses you can offer them the option to self-register to simplify and, potentially, reduce the cost of onboarding. Neptune DXP allows you to implement on or more apps targeted to a group of employees, partners or customers and deploy them into an application Launchpad specifically configured to support self-registration.

The following steps take place to complete a self-registration process:

Access to the apps for self-registered users is subject to role based access controls.

Data held in Neptune DXP apps can be, via a simple setting, be encrypted using the Advanced Encryption Standard (AES) utilising a 256-bit encryption key. When data is stored in the cache it is automatically encrypted and when fetched back to present to the user interface it is automatically decrypted:

Whilst the strong encryption of app data should suffice for all use cases, you may already operate a privileged access management service, for example, Microsoft Azure or Hashicorp Vault, acting as a secure storage for enterprise secrets such as credentials, API keys, passwords, license keys.

In this case the Neptune DXP app can onboard the REST API of the PAM service and enable key based access to secrets to further mitigate security concerns. To establish a trusted relationship between the PAM service and Neptune DXP app the recommended approach is to use a certificate-based authentication mechanism. The PAM service must issue a certificate that s imported into Neptune DXP and to create a certificate-based API authentication policy. The policy is assigned to the on boarded PAM REST API ensuring that each API call made from Neptune DXP runtimes is authenticated and accepted. The use of certificates is recommended because credential driven methods (for example, basic authentication or token based) require a sensitive secret, that is, password or a token to be stored in the local device.