Neptune DXP in the enterprise security landscape
Today’s enterprise security landscape is composed of several controls to verify and route incoming traffic to the backend private network. Pre-existing enterprise edge security measures can continue to be used, with minor adaptations, to facilitate ingress/egress traffic to and from Neptune DXP workloads. Depending on your organisation’s risk sensitivity, Neptune DXP’s security can be adapted accordingly allowing you to achieve a good balance between protective controls and usability. The indicative architecture below is an abstraction of a typical enterprise security landscape demonstrating Neptune DXP’s natural fit:
Security adaptations to deploy Neptune DXP in an existing technical landscape should be limited to configuration changes without significant re-implementation tasks.
Adaptations to deploy Neptune DXP
Neptune DXP ‘s support for multiple and standard transport and authentication protocols means that it should fit well within existing security arrangements of your enterprise network. Whilst each enterprise is unique the following areas are likely to be impacted.
User security adaptations
As Neptune DXP is both a runtime accessed by end-users and a development platform accessed by DevOps resources, user security must be looked at with two different lenses.
For end-user security, care must be taken to configure Identity and Access Management (IAM) to apps developed with Neptune DXP. The authentication method adopted may dictate changes needing to be made to an Identity Provider (IDP) already in use, typically around the user group and roles structure already defined in the IDP that may not be appropriate and may require restructuring. If integration with an identity provider is not possible or needed a local user security store could be used instead, fully supported by Neptune DXP. In this case, user definitions may diverge from those on an IDP service and over the long term may be introducing technical debt.
For DevOps users, similar care should be taken for authenticating and authorising access to the platform. Neptune DXP implements a comprehensive Role-Based Authorisation Control (RBAC) for access to its internal functions. If the DevOps roles relevant to mobile/web application and microservice development are not in place in the existing IDP they may need to be defined.
Device security (MDM)
For native Neptune DXP app deployments, Neptune DXP supports integrations with Mobile Device Management (MDM) services, such as Microsoft Intune, SOTI, MobileIron, AirWatch, BlackBerry Dynamics, Blue Cedar, and others, using Cordova plugins. Simply include in the MDM provider’s Cordova plugin to a Neptune DXP app deployment package to enable access to the device.
For Neptune DXP web apps an MDM service may still be relevant if you wish to operate a corporate partition managed by the MDM service and enable access to Neptune DXP apps through that alone.
In some cases, a cost-conscious enterprise may not be able to invest in an MDM service nor incur the ongoing annual operating costs. Whilst Neptune DXP does not constitute an alternative to an MDM service some built-in deployment and security features may serve as an acceptable substitute. The table below provides insight to help you decide whether the out of box deployment features may be sufficient to alleviate the need for a full-blown MDM service:
| MDM security features | Possible in Neptune DXP | Neptune DXP capability |
|---|---|---|
Identity Provider Integration |
Yes |
Native integration to Microsoft Entra ID, SAML, LDAP providers. A local user store is also supported along with the ability to build bespoke authentication. |
Multi-Factor Authentication |
Pending |
Support for Pin Code authentication |
User Self-Registration |
Yes |
Support for user self-registration against a company email domain e.g. <user>@neptune-software.com. |
User Authorisation |
Yes |
Support for Role Based Access Control (RBAC). |
User Locking |
Yes |
Supported on command or configurable to automatically lock users after 3 failed authentication attempts. |
Password Resets |
Yes |
Provision for a password reset URL – requires implementation. |
Remote App Installation/Wipe |
Pending |
Not for the native app itself, however, Neptune DXP apps access via the Neptune DXP application Launchpad can be deployed and deleted. |
Remote App Patching |
Yes |
Supported through PhoneGap build updates. |
Partitioned Isolation |
No |
Not supported |
Data Encryption |
Yes |
Simple setting to enable data encryption for the data store in devices using the Advanced Encryption Standard (AES) utilising a 256-bit encryption key. |
Remote Data Wipe |
Pending |
Not supported on command, however, configurable to wipe app data after 5 failed authentication attempts. |
Geofencing |
No |
Not supported – Neptune DXP support the Cordova geofencing libraries, but these cannot be used to extend control over the device |
Lost Mode (find my phone) |
No |
Not supported |
Location History |
No |
Not supported |
Remote Alarm |
No |
Not supported |
Remote Control |
No |
Not supported |
Remote Lock |
No |
Not supported |
Remote OS Patching |
No |
Not supported |
Jail-Break Detection |
Pending |
Achievable through a Cordova plugin addition to the mobile deployment package. |
Edge security
Web Application Firewall (WAF) filtering ingress HTTP traffic to protect against cross-site scripting or SQL injections attacks. Adapt by inserting whitelisting rules to enable access to newly deployed Neptune DXP apps operated on either corporate or anonymous mobile devices, used on BYOD basis. Similar adaptions may be applied to blacklist decommissioned apps as your landscape evolves and matures.
Content Delivery Network (CDN), for example, Cloudflare typically used to arrest traffic spikes, malicious or not, by caching content delivered to Neptune DXP apps. This limits the volume of traffic propagated to backend Neptune DXP microservices and ultimately any backend systems such as SAP. The scope of caching applies to both media artefacts used by DX apps (images, video, text) and API calls. By default, there should not be a need for any adaptations. However, it may valuable to make targeted interventions to optimise the cache settings for specific API calls such as cache expiry limits etc.
Internet/Application Gateway as the entry point to your virtual private network regulating and balancing ingress and egress traffic to grouped workloads. You may need to configure adaptations to handle terminating incoming internet connections from Neptune DXP Apps to initiate corresponding new internal connections to either a:
-
Neptune DXP App Server handing identity and access management (IAM) requests or internal processing such as server script executions or workflows, or an
-
API Gateway, if present, to proxy API requests to microservices or directly to the Neptune DXP SAP connector
Firewall multi-layered corporate firewall, filtering HTTP traffic within a private network.
-
North/South traffic adapts to modify rules validating for weaknesses or malicious alterations found in API requests made by Neptune DXP apps to either the API Gateway or directly to Neptune DXP Microservices if a gateway is not present.
-
East / West traffic enhanced compartmentalisation between Neptune DXP workloads could also be introduced to minimise the exposure of critical services. For example, a firewall service may whitelist traffic from a Neptune DXP ordering microservice orchestrating a Neptune DXP payment microservice (acting as a proxy to a payment processor) whilst excluding access from others Neptune DXP services.
API Gateway proxying API requests made by Neptune DXP Apps to Neptune DXP microservices or SAP through the Neptune DXP SAP connector, for example, a simple NGINX reverse proxy or a more expansive management suite such as Google Apigee or SAP API Management. Most gateways operate a cache layer, with adequate default settings. However, over time it ought to be configured to reduce the need to push every API request to a backend Neptune DXP workload. In addition, to the performance improvement, it reduces the exposure of private resources to external request, which increases security.
Identity provider (IDP)
Typical IDPs supported by Neptune DXP are Microsoft Entra ID or any other LDAP, SAML based federated login services, for example, Microsoft ADFS as a SAML provider. In all cases, Neptune DXP attempts to import information concerning user groups, roles and users. It may be required to represent the end-user base and DevOps team members if not already recorded and if necessary, make changes to their organisation (for example, groups, roles, attributes) in the existing IDP.