Legacy web access management (WAM) platforms still guard thousands of internal and partner web applications through web agents, reverse proxies and identity headers that the application trusts without checking. Products in this class, such as Broadcom SiteMinder and Oracle Access Manager, were designed around web agents in front of applications on a protected internal network. Moving those applications to a modern identity provider over SAML or OpenID Connect is one of the hardest parts of any identity platform migration, because the trust model inside each application has to change, not just the login page. This guide is for identity architects and application owners who need to retire WAM agents safely. It covers how WAM trust actually works, how to classify each application, the bridge patterns that buy time, and how to prove the old trust paths are gone. For the wider programme (coexistence, rings and decommissioning across the whole estate), see the Identity Platform Migration guide.
Products are named only as examples and are listed alphabetically; naming is not a ranking or an assessment. This is an independent guide from NHI Mgmt Group, based on each vendor's public documentation as of November 2026. It is not sponsored or reviewed by any vendor named. Product features change, so confirm settings against each vendor's current documentation.
Key takeaways
- The real risk is the trusted header. A header-based application usually believes whatever identity arrives in a request header, so any path that reaches it without passing the agent or proxy is an authentication bypass.
- Classify before you choose a pattern. Each application falls into one of four routes: native SAML or OIDC, a header bridge behind a modern gateway, a rebuild, or retirement. The route drives effort, cost and risk.
- Bridges are a stage, not a destination. Translating modern tokens into headers keeps old applications running, but it keeps the header trust model alive, so lock the network path down and give every bridge a retirement date.
- WAM holds machine secrets too. Agent shared secrets, cookie encryption keys and gateway connector credentials are non-human identities that need an owner, rotation and revocation at decommission.
- Finish means no reachable trust path. Decommissioning is only complete when direct access to every former WAM application is blocked or the application validates tokens itself, and old agent keys are destroyed.
How WAM trust works, and why it is fragile
A classic WAM deployment has three moving parts: a policy server that decides who may access which URL, an agent (a web server plug-in) or reverse proxy that enforces those decisions in front of the application, and a session cookie that carries the authenticated session between requests. When a request is allowed, the agent passes identity to the application, usually as an HTTP request header holding a user ID, groups or roles.
- Session cookies: Broadcom documents that SiteMinder Web Agents use four agent keys from the Key Store to encrypt and decrypt the SMSESSION cookie and other SiteMinder cookies. Anyone who can obtain or forge a valid cookie inherits the session, which is why cookie theft (ATT&CK T1539 Steal Web Session Cookie) and reuse (T1550.004 Web Session Cookie) matter here.
- Agent trust: each SiteMinder agent holds a shared secret in SmHost.conf that matches a trusted host object in the policy store. Oracle documents an equivalent per-AccessGate password for WebGate registration.
- Identity assertion: Oracle's documentation for OAM identity assertion on IBM WebSphere describes two modes. Cookie-based assertion validates the session token with the OAM server. Header-based assertion reads a configurable header (OAM_REMOTE_USER by default) and asserts the identity inside it.
The weakness is structural, not a product flaw: the application has handed authentication to something in front of it. If a load balancer rule, a second virtual host, a health check port or an internal network segment lets a client reach the application directly, a forged header is accepted. Microsoft's documentation for its own header-based mode makes the same point: access to the application should be restricted to traffic from the connector or another permitted header-based solution, commonly with a firewall or IP restriction on the application server.
See the Proxies and Forward vs Reverse Proxy Security Guide for reverse proxy hardening in general.
Inventory: what to collect from the WAM estate
The policy store is the best inventory you have. Export it before anything else, then reconcile it with web server and load balancer configuration, because agents are sometimes installed on servers that policy no longer references.
| Item | Where it lives | Why it matters for migration |
|---|---|---|
| Protected realms, URL patterns and rules | Policy store | Defines what is protected and what is deliberately unprotected (public paths often hide exposure) |
| Response attributes and header names | Policy responses (for example OAM HeaderVar returns) | The exact headers the application expects; the new gateway or application must reproduce or replace each one |
| Authentication schemes | Policy server | Forms, certificate, Kerberos or multi-factor steps that the new identity provider must cover |
| Agents, hosts and trusted host secrets | Agent configuration files, policy store | Machine credentials to rotate during coexistence and revoke at the end |
| Session settings | Realm and agent configuration | Idle and maximum timeouts and single logout behaviour to match or improve |
| User directories and groups | LDAP or directory connections | Groups used in policy must exist, with the same meaning, in the new provider |
| Federation partnerships | WAM federation module, if licensed | SAML partners already on standards can often move first with metadata exchange |
Then add usage: authenticated request counts per realm from WAM logs, so you know which applications are live, which are dormant and which have a handful of heavy users who need white-glove testing.
Classifying applications: four routes
| Route | When it fits | Effort | Residual risk |
|---|---|---|---|
| 1. Native SAML or OIDC | The application or its framework supports federation (most commercial software and modern frameworks) | Low to medium: configuration, claim mapping, testing | Lowest: the application validates signed assertions itself |
| 2. Header bridge behind a modern gateway | Code cannot change soon (vendor software out of support, no developer capacity) | Medium: gateway, header mapping, network lockdown | Header trust remains; depends on the network path being closed |
| 3. Rebuild or refactor | In-house application with an active team and a roadmap | High: code change, security testing | Lowest once done; best long-term outcome |
| 4. Retire | Dormant or duplicated application, low usage in WAM logs | Low: archive data, remove access | None once decommissioned |
Decision guidance: choose route 1 wherever it exists, even if it means a configuration change the application team has avoided for years. Use route 2 only with a written retirement date and an owner. For a small organisation with a few dozen WAM applications, a single gateway product and a two-route plan (native or bridge) is usually enough. A large enterprise with hundreds of realms should run a factory: a standard intake form, a claim mapping template, and weekly migration waves.
Microsoft's Zero Trust workshop guidance for guest-facing WAM applications recommends the same direction: replace custom header-based authentication with OIDC or SAML, move access decisions into central role-based access and entitlement management, and consolidate telemetry in one control plane. See the SAML Security Guide and the OAuth 2.0 and OpenID Connect Guide.
Bridge patterns: running header applications behind a modern provider
A header bridge authenticates the user with the new identity provider, reads claims from the token, and injects them as headers towards the application. Microsoft documents this for its application proxy: the administrator maps attributes in the admin centre, the service authenticates the user, translates claims from the ID token into HTTP headers, and the private network connector passes the request to the back end.
Whichever gateway you use, these controls decide whether the bridge is safe:
- Close the direct path: firewall or IP restrictions so only the gateway or connector can reach the application port. Test from another network segment that a request carrying a forged header is refused.
- Strip inbound identity headers: the gateway must remove any client-supplied copy of each identity header before setting its own. Verify this with a test request rather than assuming it.
- Match header names exactly: the application reads specific names (for example a SiteMinder-era user header or OAM_REMOTE_USER). Mismatches cause either outages or silent fallback to anonymous access.
- Prefer validated tokens over plain headers: where the application server can validate a signed token (for example via a trust interceptor or framework module), use that instead of a plain user header.
- Scope by path: Microsoft notes that all sub-paths under the published internal URL receive the same headers, and a different header set for a sub-path needs a separate application. Plan admin paths accordingly.
- Check the documented use: confirm that your gateway is designed for the traffic you route through it. For example, Microsoft states that its application proxy provides remote access and is not intended for general corporate access or for traffic from inside the same network as the application.
Migration runbook
- Freeze and export: freeze new WAM realms (new applications go straight to the modern provider) and export the policy store, agent list and session settings.
- Build the claim map: for each application, map every WAM response attribute to a claim or header from the new provider, including group and role formats.
- Pilot with a low-risk application: pick one route 1 and one route 2 application with engaged owners. Run both systems in parallel where possible, using a separate host name for the new path.
- Test authorisation, not just login: confirm that users without the right group are refused, that session timeouts match policy, and that logout ends the session at both the application and the provider. See the OpenID Connect Logout and Session Management Guide.
- Apply access policy at the new provider: recreate multi-factor and device rules as Conditional Access or equivalent policies. Microsoft notes that application authorisation policies in its proxy apply to the initial authentication request, so do not rely on them for per-request decisions. See the Conditional Access Guide.
- Cut over in waves: switch DNS or load balancer routing per application, keeping the WAM path available but unadvertised for a defined rollback window (our recommendation: two weeks for low-risk applications, one full business cycle, such as month end, for finance applications).
- Roll back cleanly: rollback is a routing change back to the WAM path. Keep agent configuration untouched until the rollback window closes, and record every rollback with its cause.
- Close the old path: remove the agent, remove the realm, block direct access and run the forged-header test again.
Where identity fits: WAM machine credentials
A WAM estate carries several secrets that behave like any other non-human identity credential:
- Agent shared secrets: Broadcom documents that SiteMinder rollover of the agent shared secret is configured per agent at registration, can run manually or periodically, and that agents not registered for rollover keep their existing secret. Agents set up years ago may never have rotated.
- Cookie encryption keys and session ticket keys: held in the policy or key store. Rotate them if any policy server or store backup may have been exposed during the migration.
- Gateway connectors and service accounts: the new bridge introduces its own connector registrations and, for Kerberos delegation scenarios, service accounts with delegation rights. Inventory and own them from day one.
- Directory bind accounts: the policy server's LDAP bind credentials often have broad read rights and should be disabled when the policy server is retired.
See the Non-Human Identity (NHI) Guide for lifecycle controls that apply to these credentials.
Detection and measurement
- Direct access attempts: alert on any connection to a former WAM application that does not come from the gateway or connector address range.
- Identity headers at the edge: log and alert when inbound client requests carry identity header names (for example the user header your bridge sets). These should never come from browsers.
- Session anomalies: sessions used from two distant locations or user agents, a sign of cookie theft or replay.
- Residual WAM traffic: authentication counts per realm on the old platform during coexistence; a realm that should be migrated but still shows traffic needs investigation.
| Metric | Target (NHI Mgmt Group suggestion) |
|---|---|
| Share of WAM applications migrated to native SAML or OIDC | Rising every quarter; bridges below 20% of the original estate at programme end |
| Bridged applications with a passed forged-header test in the last 90 days | 100% |
| Bridged applications with an owner and retirement date | 100% |
| Agent shared secrets and keys rotated since migration start | 100% of agents still in service |
| Rollbacks per wave | Falling wave on wave |
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2, IA-8 | Authentication of organisational and non-organisational (partner) users moves to the new provider |
| NIST SP 800-53 Rev 5 | AC-3 | Access enforcement moves from WAM policy to provider policy and application roles |
| NIST SP 800-53 Rev 5 | SC-23 | Session authenticity: protect session cookies and tokens during and after migration |
| NIST SP 800-53 Rev 5 | SC-7 | Boundary protection that keeps bridged applications reachable only through the gateway |
| NIST CSF 2.0 | PR.AA-01, PR.AA-03, PR.AA-05 | Credential management, authentication and least-privilege access policy |
| NIST SP 800-63C-4 | Federation assurance levels | Signed assertions, audience restriction, replay and injection protection for the new federation |
| MITRE ATT&CK | T1539, T1550.004, T1185 | Session cookie theft, reuse and browser session hijacking against WAM and successor sessions |
See the NIST SP 800-63C-4 Federation Assurance Levels Guide.
Common failure patterns
- A forgotten direct path: the application is published through the new gateway, but an old load balancer virtual server still forwards to it, and a header set by any client is accepted.
- Header pass-through: the gateway adds its header but does not remove a client-supplied one with the same name, and the application reads the first value.
- Groups that changed meaning: a directory group used in WAM policy is recreated in the new provider with different membership, granting or removing access silently.
- Bridges with no end date: the bridge becomes the new permanent architecture, and the header trust model survives another decade.
- Keys left behind: agents are uninstalled but trusted host objects, agent keys and directory bind accounts stay valid in a policy store that is kept "just in case".
- Logout mismatch: users log out of the application but the provider session remains, or the reverse, leaving sessions open on shared devices.
Practitioner checklist
- Export the WAM policy store, agent list, header responses and session settings before design work starts.
- Freeze new WAM realms; onboard new applications only to the modern provider.
- Classify every application into native, bridge, rebuild or retire, with an owner for each.
- Build a claim map per application covering every header and group the application reads.
- For each bridge, block direct access, strip inbound identity headers and run a forged-header test.
- Give every bridged application a written retirement date.
- Inventory and rotate agent shared secrets, cookie keys, connector registrations and bind accounts.
- Cut over in waves with a defined rollback window and record every rollback.
- At decommission, remove realms, destroy agent keys, disable bind accounts and re-test for direct access.
Standards and references
- NIST: SP 800-63C-4 Digital Identity Guidelines, Federation and Assertions
- Microsoft Learn: Header-based single sign-on for on-premises apps with Microsoft Entra application proxy
- Microsoft Learn: Resources for migrating applications to Microsoft Entra ID
- Microsoft Zero Trust Workshop: Migrate legacy web access management applications
- Broadcom: Shared secret and encryption keys management in Policy Server
- Oracle: Managing OAM Identity Assertion on IBM WebSphere
Related NHI Mgmt Group resources: Identity Platform Migration · SAML to OIDC Migration · Legacy Authentication and ROPC Retirement Guide · Identity Federation Failure Modes