Network Services Configuration🔗
The sedex-Client provides two distinct network services within the participant’s environment.
- Web Service Proxy (WSP) / sedex Messaging REST API (two coupled services) – enables secure synchronous access to external web services and exposes the (optional) sedex Messaging REST API for asynchronous message exchange.
- Client Monitoring – provides a web-based interface to observe the operational state of the sedex-Client.
Both services share similar network-related configuration principles, which are described on this page and must be configured properly to ensure secure access from within the participant’s network.
Info
This page focuses exclusively on the network configuration aspects of these services, such as port numbers, binding addresses, and TLS security options.
For detailed information about further service-specific configuration parameters, refer to the page about general client configuration properties or the dedicated chapters for each component.
Network configuration properties🔗
Use the following properties in the client configuration file (<sedex_home>/conf/sedex-client-configuration.properties
) to define the network interface and port bindings.
Note that the property key prefixes differ depending on the network service (wsproxy or monitoring).
| Web Service Proxy Property Key | Client Monitoring Property Key | Description and example values |
|---|---|---|
wsproxy.http.port |
monitoring.http.port |
Port number to access the service using (unsecured) http protocol. Values: 8080 / 8000 |
wsproxy.http.disabled |
monitoring.http.disabled |
Set to true, to disable http access. Values: true (recommended) / false |
wsproxy.https.port |
monitoring.https.port |
Port number to access the service using (secured) https protocol. Values: 8443 / 9443 |
wsproxy.address |
monitoring.address |
IP address of the network interface to bind to. Set to 0.0.0.0 to bind to all interfaces.Values: 127.0.0.1 / 0.0.0.0 |
The following sections explain the available configuration options in more detail and discuss how to adapt the network settings to achieve a secure and appropriate configuration for your specific environment.
Network Protocols: HTTP vs. HTTPS🔗
Both the sedex Web Service Proxy and the Monitoring Server can expose their network services using either the unsecured HTTP protocol or the secured HTTPS protocol.
The table below outlines the key differences between HTTP and HTTPS, emphasizing the security advantages of using HTTPS for sedex network services.
| Protocol | Security Level | Communication | User Authentication | Recommended |
|---|---|---|---|---|
| HTTP | Unsecured | Unencrypted | Not possible | No |
| HTTPS | Secured | Encrypted using SSL/TLS | Possible using Basic Auth over SSL/TLS | Yes |
It is strongly recommended to use HTTPS exclusively whenever possible, as it provides encrypted and authenticated communication based on SSL/TLS.
The unsecured HTTP protocol should be disabled to prevent potential security risks.
Default Configuration Principles: Security First vs. Compatibility First
The default configuration of the sedex-Client is designed with a strong focus on security and controlled compatibility.
Security First (for new installations):
Starting with sedex-Client version 8.0, new installations are configured by default so that all network services are available exclusively via HTTPS.
If HTTP access is required, it must be manually enabled in the configuration.
Compatibility First (for updates and migrations):
When updating or migrating existing installations, the previous behavior is preserved to ensure a smooth transition.
This means that if HTTP was previously enabled, it remains enabled after migration.
Nevertheless, it is strongly recommended to adapt connected applications to use HTTPS and to disable HTTP as soon as possible.
SSL/TLS Endpoint Certificates🔗
Each SSL/TLS endpoint requires a valid TLS certificate that is used to provide cryptographic security for network communication.
The sedex-Client supports both automatically generated self-signed certificates and the manual installation of custom TLS certificates.
For detailed information on how to configure and manage these certificates, see the separate page about the TLS-Certificates for Network Services.
Network Interface Binding Address🔗
The network interface binding determines on which network interface (IP address) the sedex-Client exposes its network services.
You can either specify a particular interface by providing its IP address or use the wildcard address 0.0.0.0 to make the service available on all network interfaces.
| Address Value | Description | New Installation Default | Migration Behavior (Legacy Versions) |
|---|---|---|---|
localhost or 127.0.0.1 |
Local Access Only. The service is bound only to the local host interface and is therefore accessible only from the machine itself. | Default | Existing value is retained. |
Specific IP address (e.g. 10.20.55.114) |
Bound to a specific network interface. The service is accessible only via the specified network interface and IP address. | Must be set manually. | Existing value is retained. |
0.0.0.0 |
Wildcard binding. The service is accessible via all available network interfaces on the host. | Must be set manually. | Adopted if no previous bind address was defined, to prevent unintended loss of external accessibility. |
During installation, the user can specify which network interfaces should be used to expose the network services. The binding configuration can later be adjusted manually by modifying the corresponding properties as described above.
Note
In earlier versions, all services were exposed on all interfaces by default.
Starting with newer versions, this behavior has been improved for security reasons:
service availability can now be restricted to a specific interface — which is particularly recommended when the services are only accessed locally from the same host.
User Authentication and Access Control🔗
While many configuration aspects are identical for the two network services — Web Service Proxy and Monitoring — they differ fundamentally in how user authentication is handled and how users are configured.
The following sections describe the user management and authentication mechanisms for each service individually.
User Authentication for Monitoring Service🔗
Access to the Monitoring Service via the HTTPS protocol can be restricted to a single user account using HTTP Basic Authentication.
Two dedicated configuration properties are available to define the username and corresponding password:
| Property Key | Description and Example Value |
|---|---|
monitoring.https.username |
Username for accessing the Monitoring Service via HTTPS. Example: MyMonitorUser |
monitoring.https.password |
Password associated with the Monitoring user account. Example: MySecurePassword123! |
Note
Once Basic Authentication is configured, access to the Monitoring Service is only possible via HTTPS.
For security reasons, Basic Authentication is not supported over unsecured HTTP connections.
Web Service Proxy Access Restriction🔗
Access to the Web Service Proxy and the sedex Messaging REST API can be restricted to a defined list of users. A dedicated user administration system is included that supports multiple user accounts, individual permissions, and secure authentication mechanisms. This enables a flexible and fine-grained user and access management approach.
For detailed information on configuring and managing these user accounts, refer to
User Administration for the sedex Web Service Proxy.