Secure Legacy Apps with Microsoft Entra External ID and Datawiza Access Proxy

Many enterprises still run business-critical legacy web applications protected by older “web access management” and reverse-proxy stacks—CA SiteMinder, IBM Security Access Manager (ISAM/WebSEAL), Oracle Access Manager (OAM), PingAccess, and RSA platforms. These systems have been the front door for years, providing centralized login, cookie-based SSO, header-based identity injection, and basic access policies for applications that can’t easily be changed.

But identity requirements have evolved. Organizations now need modern external user experiences (partners, suppliers, customers), stronger MFA, more flexible policy controls, and a clean path to standardize on Microsoft Entra—especially Entra External ID for external identities.

The problem: most of the apps behind these legacy access stacks were never built to support modern protocols or modern user journeys. Rewriting them is slow, expensive, and risky.

This blog explains how to modernize entra external id legacy apps using Datawiza Identity Modernization—providing a practical migration path from SiteMinder, IBM Access Manager, Oracle Access Manager, PingAccess, and RSA—without rewriting your applications.

Why legacy apps protected by SiteMinder, ISAM, OAM, PingAccess, or RSA are hard to modernize

These platforms were designed for an era when “SSO” meant a central login plus a session cookie, and when most apps lived in a single datacenter. Modern identity programs often stall because:

• Legacy apps don’t support OIDC/OAuth 2.0 or token-first patterns
• Apps depend on headers, cookies, or proprietary session mechanisms
• External identity flows (sign-up, self-service reset, branding) are limited or complex
• MFA and step-up authentication are inconsistent across apps and portals
• Per-app integrations are brittle, slow to change, and costly to maintain
• The access layer becomes a bottleneck for cloud and zero-trust adoption

In short: the “front door” is doing its job, but it’s preventing you from standardizing on modern identity.

What Microsoft Entra External ID delivers for external users

Microsoft Entra External ID is built for external identities—customers, partners, suppliers, and other non-employees. It helps enterprises implement:

• Secure sign-in experiences for external users
• Strong multi-factor authentication (MFA)
• Registration, sign-in, and password reset user flows
• Centralized identity lifecycle and policy management
• A consistent identity layer across multiple external-facing applications

Entra External ID is the modern identity foundation. The remaining challenge is integration: how do you bring Entra External ID to legacy apps that can’t adopt modern authentication standards?

Where Datawiza fits: secure legacy apps without rewriting them

Datawiza sits in front of your application as an access proxy—so you can modernize authentication and policy enforcement without changing the legacy app itself.

The flow:

1. A user accesses the legacy app URL
2. Datawiza redirects the user to Entra External ID for authentication
3. Entra External ID authenticates the user (including MFA as configured)
4. Entra External ID returns identity claims to Datawiza
5. Datawiza enforces access policies and maps identity to the legacy app
6. The legacy app receives identity in the format it understands (headers, cookies, session mapping)

This creates a fast, low-risk path to secure legacy apps with Entra External ID—without rewriting applications.

Reference architecture: Entra External ID + Datawiza for legacy apps

User Browser -> legacy-app.company.com -> Datawiza Access Proxy (front door) -> Redirect to Entra External ID <- Token/claims returned -> Policy enforcement + identity mapping -> Forward to legacy app (on-prem or cloud)

This pattern is ideal for:

• B2B portals (suppliers, dealers, distributors)
• Customer-facing legacy web apps
• Packaged apps you can’t modify
• On-prem apps you plan to keep for years
• Mixed environments (some apps on-prem, some in cloud)

Migration paths from common legacy access stacks

If your current architecture is:

User -> (SiteMinder / ISAM / OAM / PingAccess / RSA) -> Legacy App

Your modernization path is:

• User -> Datawiza Access Proxy -> Entra External ID -> Datawiza Access Proxy -> Legacy App
• Below are practical ways this applies across the systems you mentioned.

Migrating from CA SiteMinder to Entra External ID

SiteMinder environments often rely on centralized sessions and identity injection patterns. With Datawiza Access Proxy in front, you can move authentication and external user flows to Entra External ID while keeping the app unchanged.

Why it works:

• You preserve the “front door” model teams already operate
• You migrate app-by-app (no big bang)
• You standardize external identities and MFA in Entra External ID

Migrating from IBM Security Access Manager (ISAM/WebSEAL) to Entra External ID

ISAM/WebSEAL is commonly deployed as a reverse proxy and identity enforcement point. Datawiza provides a similar access-gateway pattern, but integrates directly with Entra External ID to modernize external identity journeys.

Why it works:

• The reverse-proxy model remains familiar
• You reduce brittle per-app customization over time
• You get a consistent external identity layer across apps

Migrating from Oracle Access Manager (OAM) to Entra External ID

OAM is often deeply embedded in legacy SSO architectures. A phased approach is typically most successful:

• Start with external-facing apps where Entra External ID provides immediate value
• Use Datawiza to bridge modern identity to apps that can’t adopt OIDC/SAML easily
• Expand to additional apps as you build a repeatable rollout template

Why it works:

• You modernize without disrupting fragile legacy apps
• You reduce dependency on proprietary patterns while keeping stability

Migrating from Ping Access to Entra External ID

PingAccess is frequently used as an access gateway in front of apps, sometimes alongside other Ping products. If you’re moving external identities to Entra External ID, Datawiza can become the standardized integration layer to legacy apps.

Why it works:

• You can keep the gateway approach while standardizing external identity on Entra
• You get consistent claims-based policy and app integration patterns
• You migrate gradually by routing specific apps or user groups first

Migrating from RSA platforms to Entra External ID

RSA deployments often show up in older enterprise access architectures (authentication, MFA, or broader access management depending on the stack). When transitioning to Entra External ID for external users, Datawiza helps you modernize application access without forcing changes to the underlying apps.

Why it works:

• You move toward a modern external identity foundation
• You keep legacy apps stable while you upgrade authentication and policy
• You implement a phased migration plan with clear rollback points

What you gain: security outcomes and operational wins

1. Modern MFA + external user onboarding Entra External ID delivers external identity journeys that legacy access stacks often struggle to support cleanly.
2. Policy enforcement in front of the app Datawiza Access Proxy can enforce:

• Role/claims-based access controls
• URL/path-level restrictions (limit admin paths and sensitive functions)
• Step-up authentication patterns for higher-risk areas

1. Faster modernization with less risk No need to modify legacy app authentication code or build custom “one-off” SSO integrations per app.
2. Repeatable pattern across your legacy app portfolio Once you secure one app, you can apply the same architecture to the next—and scale consistently.
3. Better auditing and compliance readiness Centralized identity events from Entra External ID plus access-layer logs from Datawiza create stronger audit evidence.

Implementation blueprint (what an enterprise rollout looks like)

Step 1: Pick one target app and external user group Start where the ROI is highest—typically partner/customer portals.

Step 2: Document how the current access stack integrates For each app capture:

• Identity injection method (headers, cookies, both)
• User attributes required by the app (user ID, email, roles, tenant/org)
• Session patterns (timeouts, logout behavior, deep links)

Step 3: Configure Entra External ID user flows Define registration/sign-in/reset journeys and MFA requirements.

Step 4: Configure Datawiza identity mapping + policies

• Map Entra claims to legacy app identity format
• Enforce baseline and app-specific access rules

Step 5: Pilot and cut over safely

• Start with a pilot group
• Gradual routing (DNS/LB/WAF)
• Clear rollback plan

Step 6: Scale across more apps Create a migration template so each additional app is faster.

Common pitfalls (and how to avoid them)

1. User identity matching to existing app accounts Choose a stable mapping approach:

• Email match (simple, but can drift)
• Stable external ID claim (more robust)
• Org/tenant + user mapping for B2B portals

1. Session/logout edge cases Test:

• Multi-tab sessions
• Idle vs absolute timeout
• Deep links after authentication
• Back button behavior

1. Authorization gaps Use modernization to tighten access:

• Restrict admin URLs by role/network
• Step-up MFA for sensitive paths
• Segment external users by org and entitlements

Conclusion

If you’re modernizing entra external id legacy apps, the fastest path is to combine a modern external identity foundation with a purpose-built integration layer for legacy systems.

Microsoft Entra External ID provides secure external identity and user flows. Datawiza bridges that modern identity to legacy apps—especially those historically protected by CA SiteMinder, IBM Access Manager (ISAM/WebSEAL), Oracle Access Manager (OAM), PingAccess, and RSA—without rewriting applications.

If you’re planning a phased migration to Entra External ID—starting with one portal and expanding across your app portfolio—Datawiza can help you secure legacy apps quickly, reduce operational burden, and build a repeatable blueprint. Book a technical demo.