SOAP: Improve HTTP Communication and Performance in Reverse Proxy Scenarios

1 Initial Problem

The implicit use of SOAP in ILIAS for many processes leads to performance losses and configuration hurdles depending on the ILIAS infrastructure.

Specifically, the problems exist in all use cases where a reverse proxy is used in front of an ILIAS system or an entire ILIAS cluster, or an NginX as a "load balancer" uses multiple PHP workers on other VMs.

The SOAP URL is in reality always implicitly derived from the ILIAS URL or the "server_name" of the web server (NUSOAP library), which is also always operated with TLS over HTTPS nowadays.

However, this means that communication problems have to be overcome in "multi-tier" environments (PHP to web server or reverse proxy) and/or problems with correct SSL certificates (Common-Name) or web servers behind reverse proxy, which do not have to work with HTTPS. For this, the local DNS resolution often has to be "overwritten" and valid SSL certificates have to be kept synchronized on several VMs. In this case, communication inefficiently always takes place via the reverse proxy, even though the much closer or even local web server could process it faster. Depending on the infrastructure, firewall adjustments may also have to be made so that the PHP executing instances can also communicate with the reverse proxy.

2 Conceptual Summary

To address this, we suggest adding the following configuration options for these use cases:

1. Free configuration of the SOAP URL and SOAP Port when executing the ILIAS setup (already possible, but the SOAP library requires some patches to apply the correct SOAP URL when calling the WSDL via the ILIAS URL)
2. Confirugable options (when executing the ILIAS setup) to prevent the certificate check for expiration date and also matching Common-Name or Subject-Alt-Name in the SOAP connections executed via PHP-CURL, which is possible with corresponding connection options in PHP.

With these settings, SOAP "loopback" connections could be used on shorter routes instead of via the reverse proxy with the local web server or even "localhost" without communication over network connections/routers or firewalls and do not necessarily require HTTPS connections and valid certificates in this locally handled communication.

3 User Interface Modifications

3.1 List of Affected Views

None

3.2 User Interface Details

Not applicable

3.3 New User Interface Concepts

None

3.4 Accessibility Implications

None

4 Technical Information

See: Security

5 Privacy

Not applicable

6 Security

When using the PHP `SoapClient`, it's important to consider the security implications of the `verify_peer`, `verify_peer_name`, and `allow_self_signed` parameters. These parameters are part of the `stream_context` option and are used to control the verification of SSL certificates.

The `verify_peer` parameter, when set to `true`, enables the verification of the SSL certificate of the server. The `verify_peer_name` parameter, when set to `true`, ensures that the common name in the SSL certificate matches the hostname of the server. These two parameters are typically set to `true` to prevent Man-in-the-Middle attacks.

The `allow_self_signed` parameter, when set to `true`, allows connections to servers with self-signed certificates. While this can be useful in a development environment, it's generally not recommended in a production environment as it can make the client vulnerable to certain types of attacks.

In a production environment, it's usually recommended to always use valid, trusted certificates and to enable peer and peer name verification.

But there are scenarios where one could forego trusted certificates and peer verification. One such scenario could be a development environment where you have control over both endpoints of the connection and therefore the risk of a Man-in-the-Middle attack is minimal.

Another scenario could be an network where all machines are considered trustworthy. In such cases, it might be acceptable to disable peer verification and use self-signed certificates.

However, it's important to note that these are exceptions. In most cases, especially in production environments and whenever sensitive data is being transmitted, you should always use trusted certificates and enable peer verification to ensure the security of the connection.

7 Contact

• Author of the Request: Schenk, Ralf [rschenk]
• Maintainer: Abijuru, Jephte [Jephte]
• Implementation of the feature is done by: Abijuru, Jephte [Jephte]

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• …

9 Discussion

10 Implementation

{ The maintainer has to give a description of the final implementation and add screenshots if possible. }

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Privacy

Information in privacy.md of component: updated on {date} by {user} | no change required

Approval

Approved at {date} by {user}.