Zero Trust Proxies for SAP: A Pragmatic Path to MFA Without Rewriting Your Apps

David Thompson breaks down what you need to know

If you’ve spent time managing SAP web access, you know the pain. A legacy Web Dynpro ABAP application still relies on basic authentication. A custom BSP app has a homegrown SSO cookie that breaks every time you patch the ICM. Auditors are demanding MFA, and the board wants zero trust. But rewriting authentication for dozens of internal apps is expensive, risky, and months away. There is a middle path — and it’s more practical than most vendor pitches would have you believe.

The Real Story

Zero trust is a sound concept: don’t trust anything inside or outside the network by default. But too many SAP teams think zero trust means ripping out the NetWeaver gateway, rewriting every app to accept OIDC tokens, or buying a whole new IAM stack. In practice, the fastest way to get there is an identity-aware proxy that sits in front of your web applications and enforces SSO and MFA before a request ever hits the application server.

Datawiza Access Proxy is one example. It terminates user sessions, redirects unauthenticated users to your enterprise identity provider (IdP), validates OIDC/OAuth tokens, and then injects the authenticated user identity into the HTTP headers that your SAP web app already understands. No application code changes. No ABAP modifications. No custom authentication exit in the ICM.

Let me be clear: I’m inherently suspicious of security products that promise to fix problems without touching your apps. But the underlying architecture here is sound because it treats identity enforcement as infrastructure, not as application logic. That’s a shift SAP teams have needed for a decade.

The standard flow looks like this:

1. User requests “.
2. DNS routes the request to the proxy, not the SAP web dispatcher.
3. Proxy checks for a valid session cookie or OIDC token.
4. If absent, proxy redirects to your IdP (Azure AD, Okta, Ping, SAP IAS — pick your poison).
5. User authenticates, possibly with MFA.
6. IdP issues an ID token or authorization code.
7. Proxy exchanges it, validates signature, and injects headers like X-User-Id, X-User-Email, and groups.
8. The SAP app sees a standard header-based SSO and grants access.

This works for Fiori launchpads that already expect SAML or OIDC, but it’s even more valuable for older assets like SAP Enterprise Portal, BusinessObjects, or custom BSP applications that were never built for modern federation.

What This Means for You

For Basis administrators, this is a way to centralize authentication without touching every system. Instead of maintaining SSL client certificates, logon tickets, and SAML configurations on ten different SAP instances, you configure the proxy once and point it at your IdP. You still need to trust the proxy’s headers — make sure your SAP backend only accepts connections from the proxy IP and never from clients directly.

For architects, the strategic question is where this fits in your long-term identity roadmap. A zero trust proxy is not a replacement for modernizing your apps. It’s a bridge. Use it to secure legacy apps while you migrate them to OData services or clean core S/4HANA. But don’t let it become permanent technical debt.

For consultants and developers, this changes how you design authentication for new custom apps. Instead of building a custom OAuth client into every Fiori extension or BSP page, you can rely on the proxy to pass identity headers. That reduces code, reduces security review cycles, and lets you focus on business logic. But you need to validate that the proxy’s header names don’t collide with existing headers in your app, and you must never accept these headers from an untrusted source.

Here’s a simplified Datawiza configuration snippet to illustrate the setup:

{
  "apps": 
    {
      "domain": "legacyapp.sap.internal",
      "upstream": "",
      "oidc": {
        "client_id": "datawiza-proxy",
        "client_secret": "secret",
        "discovery_url": "",
        "redirect_uri": ""
      },
      "headers": {
        "user": "X-User-Id",
        "email": "X-User-Email",
        "

## References

- Zero Trust Proxy: How It Works & Datawiza Example
- [Zero Trust Proxy: How It Works & Datawiza Example- SAP Community Hub

---

## References

- [SAP Community Hub](https://community.sap.com/)
- [Zero Trust Proxy: How It Works & Datawiza Example](https://sapinsider.org/articles/zero-trust-proxy-how-it-works-datawiza-example/)
- [Zero Trust Proxy: How It Works & Datawiza Example](https://www.sapinsideronline.com/feed/)