Feature Wiki

Information about planned and released features

Tabs

SOAP Webservice Integration (Phase 5)

Page Overview

[Hide]

This document is still in progress and in draft form. Some points are placeholders in the feature page template.

1 Summary

Phases 1 to 4 built a REST API on top of ILIAS Activities, with authentication, middleware, documentation, and schema validation. Phase 5 is the last planned phase. It adds SOAP to the same `ApiGateway` component, so that both protocols use the same Activities and the same security.

The goals of Phase 5 are:

  • SOAP for every Activity: Each Activity that works over REST will also work over SOAP, without any change to the Activity.
  • One security model: SOAP will use the same login tokens, permission checks, rate limiting, and logging as REST.
  • Admin control and documentation: Administrators will switch SOAP on or off in the same place as REST. Clients get a generated service description (WSDL).

2 Problem Statement

Phase 1 added REST because SOAP, as the only protocol, was heavy and hard to integrate. REST was meant to complement SOAP, not replace it. Many existing integrations and enterprise tools still need SOAP.

The old SOAP server (`public/soap/server.php`) does not benefit from the work of Phases 2 to 4:

  • It repeats business logic that Activities already provide.
  • It does not use the token login, permission checks, rate limiting, or logging of the `ApiGateway`.
  • Its inputs and outputs are not described by the Activity schemas, so documentation and behavior can differ.
  • It is configured separately from the other webservices.

As a result, ILIAS keeps two webservice stacks that behave differently. New Activities are only available over REST.

3 Concept

Phases 1 to 4 built the REST API on ILIAS Activities. Phase 5 adds SOAP next to it, using the same Activities.

Today SOAP only runs in the old SOAP server (`public/soap/server.php`). It does not use the login, permissions, rate limit or logging of the `ApiGateway`, and it repeats logic that Activities already have. New Activities are only available over REST.

After Phase 5, an Activity works over both protocols with no code change. A SOAP client sends a SOAP 1.1 request to `/soap/v2`. The endpoint takes the operation name from the request (`/apigateway/helloworld` becomes `apigatewayHelloworld`), runs the login and permission checks, and calls the Activity. The Phase 4 schemas validate input and output. Errors are returned as `soap:Fault`. Clients use the same Bearer token as REST.

Nothing changes for REST clients or the old SOAP server, and no existing data changes. Both SOAP endpoints run side by side during the transition. The `v2` in `/soap/v2` only separates the new endpoint from the old one. When the old SOAP component is discontinued, `v2` will be removed and the endpoint will move to `/soap`.

Good to know: the URL is `/soap/v2`, not `/soap/v2/index.php`. An empty XML element arrives as an empty string, not `null`. Only Bearer tokens work.

No new Composer dependency is needed. Only the `ApiGateway` component changes.

4 User Interface Modifications

4.1 List of Affected Views

Administration > Webservices > Settings > SOAP. The tab has existed since Phase 2 and now has content.

4.2 User Interface Details

The SOAP tab gets the same form as the REST tab:

  • Activate Webservice: SOAP on or off. Default: off.
  • Activate WSDL: Guests can open the WSDL at `/soap/v2?wsdl`. Default: off.
  • Rate Limit: Maximum requests per minute. Planned default: 300.

4.3 New User Interface Concepts

None.

4.4 Technical Aspects

  • Each webservice owns its routes. Only Activities are shared.
  • The WSDL is generated from the Activity schemas, so documentation and behavior match.
  • A new public entry point at `soap/v2`. Its `.htaccess` disables the `/soap/v2` to `/soap/v2/` redirect, which most SOAP clients do not follow.

5 Non-Functional Implications

5.1 Security

A new endpoint and a new input format (XML) change the attack surface. The parser rejects documents with a DTD and does not load external resources (XXE). A request size limit is added on top of rate limiting. Each operation uses the permission checks of its Activity, so SOAP can never do more than REST. A written security concept will be delivered with the feature and needs Jour Fixe approval before merge.

5.2 Privacy

The API does not change user data. Rate limiting follows the Phase 3 rule: only salted hash fingerprints of the IP address, endpoint method and URI, user ID (if logged in), and request timestamps are kept to count requests per client. Logs must never contain passwords or tokens.

5.3 Accessibility Implications

None foreseen. The form uses standard ILIAS UI components.

6 Process Information

6.1 Involved Authorities

6.2 Contact

This feature is developed by Minervis GmbH.

6.3 Funding

Funding needed: 16.000,00 €

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

7 Discussion

JourFixe, ILIAS [jourfixe], ...

8 Implementation

The feature will be implemented by Hamouda, Ahmed [ahamouda].

8.1 Description and Screenshots

{ Description of the final implementation and the changed behaviour in the related components. Please add screenshots to visualise the changes if possible. }

8.2 Test Cases

Test cases completed at {date} by {user}

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

8.3 Privacy

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

8.4 Approval

Approved at {date} by {user}.

Full Screen

Last edited: 28. Oct 2026, 12:38, Günther, Andre [ILIASBase]