Interfaces: Security Levels and Authentication
null
Note: This article is a work in progress. The security features described for the DataGatewayServer are on our development roadmap for the end of Q1/2024 and therefore not yet implemented.
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 (Server-to-Server)
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 (DataGatewayServer - Communication-/Interface-Software) 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 the authentication header in every HTTP request, which contains the username and password.
The authentication header is named Authorization and includes the username and password base64 encoded in the format - Basic <Username>:<Password>.
User management is handled within the DataGatewayServer. New users can be created and deleted there.
Note: As the number of valid users increases, so does the likelihood of unauthorized access being granted through a "brute-force attack."
In this example user heidler and password Wolfschlugen is used.
POST <ENDPOINT> HTTP/1.1
Content-Type: application/json
Accept: application/json
Authorization: Basic aGVpZGxlcjpXb2xmc2NobHVnZW4=
Cache-Control: no-cache
Sollte die Authentifizierung aufgrund von ungültigen Benutzerdaten fehlschlagen, so wird der HTTP-Code 401 Unauthorized mit der Fehlermeldung "Unauthorized acces" im Body quittiert.
HTTP/1.1 401 Unauthorized
Www-authenticate: Basic realm="Restricted Area"
Date: Mon, 26 Feb 2024 09:00:44 GMT
Content-type: application/json
Content-length: 19
Unauthorized accessDigest Access Authentication
The Digest Access Authentication is an authentication mechanism integrated into the HTTP protocol designed to enhance the security of web applications. Unlike basic authentication, which transmits usernames and passwords in plaintext, Digest Access Authentication uses cryptographically secure methods.
In Digest authentication, the client sends a request to the server (without authentication in the header), which then returns a "nonce" (a unique random number). Alternatively, this nonce can be obtained via the endpoint v2/hsc/auth/digest.
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. Because 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.
Currently, only the MD5 algorithm is supported for digest creation. Additional algorithm procedures can be implemented upon consultation.
User management is handled within the DataGatewayServer. New users can be created and deleted there.
Note: As the number of valid users increases, so does the likelihood of unauthorized access being granted through a "brute-force attack."
API Keys
API key authentication is a simple method for securing API access. With this authentication method, the user/client is provided with a unique API key. This key must be included in the header of each API request.
The server verifies the received API key to ensure that the request is coming from an authenticated user or application.
It's crucial to securely store the API key to prevent unauthorized access. Additionally, regular updates to the API key are important to maintain security.
The API key is managed within the DataGatewayServer. New keys can be generated or existing ones can be deleted. Multiple valid API keys can exist.
Note: As the number of valid API keys increases, so does the likelihood of unauthorized access being granted through a "brute-force attack."
OAuth 2.0
Client Credentials
OAuth 2.0 Client Credentials is an authentication method within the OAuth 2.0 protocol that allows an application to authenticate with the authorization Server without user involvement. This is particularly useful for applications accessing APIs without user participation and is well-suited for server-to-server communication between services.
The ERP system is registered on the authorization server and receives a unique Client ID and Client Secret. Initially, the ERP 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. For authentication with each subsequent request, the ERP includes the Access Token in the Authorization Header of the HTTP requests. If 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 invalidated. The Client Secret must be securely stored to prevent unauthorized access. Additionally, it's important to regularly update the Client Secret to enhance security further.
The Client ID and Client Secret are managed within the DataGatewayServer. New credentials can be created or existing ones can be deleted there.
Note: As the number of valid Client IDs increases, so does the likelihood of unauthorized access being granted through a "brute-force attack."
Authorization Code
This authentication method is exclusively available through the authentication system IRIS Cloudsystem.