MuleSoft Omni Gateway in front of legacy IBM ACE

The situation

A bank runs its core integrations on IBM App Connect Enterprise. One endpoint serves 278 operations, mostly SOAP 1.1 and plain HTTP, with no consumer-level security at all. Every caller that reaches the endpoint can reach everything behind it.

The bank needed to open that estate to external partners, fintech apps and digital channels, safely. Rewriting the ACE flows was not an option: they are stable, they are audited, and they carry core banking traffic.

What we built

We put a MuleSoft Omni Gateway in front of ACE and added security, governance and visibility there instead of inside the middleware.

Gateway platform

Omni Gateway (Flex) runs in connected mode on the bank's own OpenShift, managed centrally from Anypoint API Manager. We stood it up as DEV and UAT environments on the LTS channel, with TLS terminated on the bank's F5. Nothing leaves the bank's network.

Two front doors, one back end

Consumers choose the style that suits them: a REST/JSON API or a SOAP passthrough. Both land on the same unchanged ACE back end. Partners who want a modern contract get one; partners already speaking SOAP keep working.

Identity and access

OAuth 2.0 client credentials through the Red Hat build of Keycloak. The JWT is validated at the gateway and the client id is checked against approved Anypoint contracts, so an unknown or unapproved client never reaches the middleware.

Built-in policy set

JWT validation, response timeout, rate limiting and spike control on the token endpoint, and SLA-ready per-consumer limits. A single misbehaving partner can no longer degrade a shared ACE endpoint.

Custom policies built with the Rust PDK

The off-the-shelf policy set covers perimeter security. Operation-level control needed custom work, so we wrote three policies with the MuleSoft Policy Development Kit in Rust.

Per-operation authorization

The policy reads the requested operation from the request body, either the JSON root key or the SOAP body element, and allows or denies it per consumer. Grants come from a version-controlled registry, so a partner gets exactly its 60 of 278 operations and nothing else. Anything outside the grant returns a clean 403 before it reaches ACE.

This is the capability a single shared ACE endpoint simply cannot provide.

Request signing

An optional body signature check against per-consumer certificates, for partners that need non-repudiation on what they send.

PAN masking logger

Card numbers are masked in anything the gateway logs, so observability does not become a compliance problem.

Automation

Everything is reproducible. Scripts deploy gateway instances and apply policies per environment, with no hand-configured drift between DEV and UAT.

Consumer onboarding runs as a single command. It creates the client application, the Keycloak client and the Anypoint contract, applies the operation grants, then probes all 278 operations across both front doors against the expected allow/deny matrix. The target is zero mismatches, and the run is the evidence.

Each consumer also receives a generated client pack: an integration guide in Word, PDF or Confluence, a Postman collection, and an OpenAPI specification containing only that consumer's operations. Partners never see what they are not entitled to call.

What the bank gets

Zero change to legacy ACE. Security, governance and visibility are added in front of the middleware, not inside it. No flow rewrites, no regression risk on core banking traffic.

Least privilege per partner, at operation level. Grants are explicit, version controlled, and tested on every onboarding.

A modern contract for partners. REST/JSON, OAuth 2.0 and OpenAPI instead of SOAP-only, with no back-end rewrite.

One control plane. Policies, contracts and per-consumer analytics, including requests, latency and errors per client application, all in Anypoint.

Fast partner onboarding. From an agreed operation list to tested credentials and a client pack in a day.

Fits the bank's infrastructure. Runs on their OpenShift behind their F5. Data stays in their network.

Ready for the next step. The same gateway can later front new APIs, add data-level authorization, or route to a modernized back end without consumers noticing.

Where this fits

This pattern pays back fastest where a mature IBM integration estate has to be exposed to external consumers under regulatory scrutiny: open banking and partner programs, digital channels built on top of core systems, and any estate facing an ACE re-platforming decision where consumer lock-in needs to be broken before the migration starts.

Talk to us

If you are running IBM ACE and need to open it up without touching it, we will walk your current endpoints, consumers and security posture with you and come back with a concrete target state.

Get in touch with our team to arrange a walkthrough of your ACE estate.