RASIT · DEV · DEFENSE
Back to selected work

Legacy systems integration

SEPE SOAP ↔ Moodle Connector

An independent multi-tenant integration service that bridges a public-sector SOAP 1.1 contract with modern and legacy Moodle platforms through encrypted, versioned snapshots.

Editorial illustration of a secure SOAP and XML integration gateway connected to modern and legacy learning platforms
Role

Architecture, backend, Moodle connectors, security, testing, and documentation

Year

2026

Status

Validated locally · environment pilots pending

Stack

PHP 8.2+ · Symfony 7.4 · SOAP 1.1 · Moodle

01

The problem

The external tracking boundary expects a stateful SOAP 1.1 contract, while learning activity lives inside Moodle installations with different versions, databases, and availability. Connecting them directly would duplicate credentials, couple each campus to a legacy protocol, and make temporary outages visible to the external consumer.

02

My contribution

I designed and implemented the central Symfony service, six-operation SOAP boundary, per-platform connector API, administration and audit flows, and two isolated Moodle connectors. I also documented the trust boundaries, compatibility risks, deployment checklist, and the difference between local evidence and production validation.

03

The solution

Each Moodle synchronises its catalogue, receives course-to-action assignments, builds an XML snapshot from enrolments, completion, grades, tutors, and tracked sessions, and submits it with a version and checksum. The central service validates immutable master data, encrypts the last accepted snapshot, and serves it through the platform's opaque SOAP endpoint.

04

Integration architecture

The design keeps the legacy external contract in one place and gives every Moodle platform an isolated modern connector boundary.

Key decisions

  • The SOAP contract is centralised instead of reimplemented inside every Moodle campus.
  • Versioned snapshots preserve the last valid state and let the SOAP boundary remain available during a campus outage.
  • The Moodle 3.5 connector is isolated from the modern codebase and described as a transitional path, not a security upgrade.

Security and integrity

  • Connector tokens and SOAP passwords use Argon2id hashes; XML payloads and database backups use Sodium secretbox.
  • Production SOAP and API traffic require HTTPS, with separate WS-Security and bearer credentials for each platform.
  • Snapshot writes use transactions, pessimistic locking, increasing versions, SHA-256 checksums, and immutable-field verification.
  • The admin boundary adds CSRF protection, login throttling, TOTP, secret rotation, and structured audit events.

Validation

  • The reviewed build completed 12 PHPUnit tests with 45 assertions covering the SOAP contract, XML service, encryption, WS-Security, and connector authentication.
  • Composer validation and locked-dependency audit passed, as did Symfony container linting and all four Twig templates.
  • Release builders produced the server, modern plugin, and PHP 7.0-compatible legacy plugin with SHA-256 hashes.
  • Moodle installation pilots, target-database operations, public TLS, and the official self-assessment kit remain explicitly pending.
05

Public evidence

The repository exposes the source, contracts, controls, packaging workflow, and a bilingual validation matrix without claiming SEPE affiliation or production approval.

01

Architecture and implementation

SOAP operations, connector API, Moodle data flow, compatibility matrix, and reproducible setup.

Review repository
02

Validation record

Executed checks, exact local results, covered behaviours, and environment validation still pending.

Review validation matrix
03

Security policy

Trust boundaries, secret handling, deployment requirements, and responsible disclosure guidance.

Review security model
SEPE SOAP ↔ Moodle Connector
Next case studyLedgerGuard z/OS
Discuss this workDownload résumé