Interfaces: Security Levels and Authentication

work in progress! The HVS32 can be operated in cloud environments without concerns, assuming that the connection from the host system (ERP or WMS, hereinafter referred to as ERP for simplicity) to HVS32 is within a shared, secure, internal network.
However, if the shipping software HVS32 needs to be publicly accessible — meaning that the host system (ERP/WMS) and the shipping software HVS32 are not located in the same network (LAN, vLAN, vNET, private cloud) — the communication between the two systems must be secured.
This implies that both the connection must be encrypted, and each incoming connection must be authenticated and authorized.

Security Levels (Infrastructure)

To secure the network bridge, there is no 100% perfect or foolproof solution. Typically, one has to opt for a compromise depending on the specific case. However, in the infrastructure, various security levels can already be implemented to significantly enhance security.

LAN / vLAN / vNET / private cloud / VPN

If the two servers are within the same network or there is a secured network bridge via VPN in place, this provides the best foundation for secure data communication between the host system and the shipping software HVS32.

S2S

In the case of an unsecured network bridge, it is crucial to ensure that communication takes place exclusively through encryption and authentication.

Dead-End-Server

Since all connections to the DGS are incoming, as an additional security measure, the DGS can be installed on a separate server where all outgoing connections are blocked via firewall.

Authentication

Authentication mechanisms can only be considered "secure" when used in combination with other security mechanisms such as HTTPS/SSL. Encryption is achieved through HTTPS using TLSv1.2 or TLSv1.3 (if supported by the client).
The following authentication options are specific to the RESTv2 interface.

Basic Authentication

The Basic Authentication is a simple authentication scheme integrated into the HTTP protocol. The client sends HTTP requests with the Authorization header containing the username and password.

Digest Access Authentication

HTTP Digest Access Authentication is an authentication mechanism integrated into the HTTP protocol designed to enhance the security of web applications. In contrast to simple Basic Authentication, Digest Access Authentication does not transmit usernames and passwords in plaintext but employs cryptographically secure methods.
In Digest Authentication, the client sends a request to the server, which responds with a "Nonce" (a unique random number). The client combines this nonce with the username, password, request method, and URI to create a "Digest" (checksum). This Digest is then sent to the server.
The server can verify the Digest by applying the same algorithm on the server side and comparing the calculated values. Since the Digest is created using the Nonce and cryptographically secure techniques, Digest Authentication effectively protects against attacks such as password theft and Man-in-the-Middle (MitM) attacks.

API Keys

API Key Authentication is a straightforward method for securing API access. In this authentication method, the user is provided with a unique API key, which is used in the header of each API request.
The server validates the received API key to ensure that the request comes from an authorized user or application.
It is crucial to securely store the API key to prevent unauthorized access. Additionally, regularly updating the API key is important to maintain security.

OAuth 2.0

Client Credentials

OAuth 2.0 Client Credentials is an authentication method in the OAuth 2.0 protocol that allows an application to authenticate against the Authorization Server. This is useful for applications accessing APIs without user involvement and is well-suited for server-to-server communication between services.
The ERP system is registered at the server and receives a unique Client ID and a Client Secret.
Initially, the ERP system sends an HTTP POST request to the Authorization Server, including the client credentials (Client ID and Client Secret). The response includes an Access Token and a Refresh Token.
Subsequently, for authentication in each request, the ERP system includes the Access Token in the Authorization Header of the HTTP requests. When the Access Token expires, a new Access Token can be requested using the Refresh Token. In case of multiple uses of a Refresh Token, all Refresh Tokens and Access Tokens are automatically blocked.
It is crucial to securely store the Client Secret to prevent unauthorized access. Additionally, it is important to regularly update the Client Secret to enhance security further.

Authorization Code

This authentication method is exclusively available through the authentication system IRIS Cloudsystem.