WS-Federation: Running and Retiring a Legacy Federation Protocol

WS-Federation still carries sign-ins for older .NET line-of-business applications, AD FS relying parties and federated Microsoft 365 domains, yet few teams know where it runs, who owns it or how it would be retired. WS-Federation is an XML and SOAP era protocol from the WS-* family: a browser is redirected to a security token service with parameters such as wa=wsignin1.0 and wtrealm, and comes back with a signed token, usually a SAML 1.1 or 2.0 assertion, posted to the application. It is still supported, but almost every identity platform now treats OpenID Connect and SAML 2.0 as the default for new work. This guide explains the current status, how to find every WS-Federation dependency, how to run what remains safely and how to migrate to OIDC or SAML with testing and rollback. It is for IAM engineers, AD FS owners and application teams, and complements the SAML vs OIDC Guide, which covers choosing the target protocol.

Key takeaways

• Legacy, not abandoned. WS-Federation 1.2 has been an OASIS Standard since 22 May 2009 with no later version, and Microsoft Entra ID and ASP.NET Core still support it, so retirement is a risk and cost decision rather than a vendor deadline.
• The real driver is AD FS. Most WS-Federation estates sit on AD FS, and moving off AD FS is where the protocol question is forced.
• Three places to look. AD FS relying party trusts, Entra ID applications and federated domains, and application code or configuration that references WS-Federation middleware or Windows Identity Foundation.
• The token signer is tier zero. Whoever holds the signing key can forge tokens for every relying party (ATT&CK T1606.002 SAML Tokens), so a forgotten WS-Federation estate is a standing golden SAML risk.
• Migrate in stages with a way back. Test instance first, then production tenant, keep the old trust documented and exportable, and cut over in off-hours.

What is changing and why

WS-Federation defines how a requestor obtains a security token from an identity provider's security token service and presents it to a relying party, with a "passive requestor" profile for web browsers built on HTTP redirects and form posts. It shares XML signature, metadata and SAML assertion handling with SAML 2.0, and its metadata format extends SAML 2.0 metadata: Microsoft's federation metadata document carries a WS-Federation RoleDescriptor and a SAML IDPSSODescriptor side by side with the same signing certificates.

Nothing in the standard is being withdrawn. What is changing is the platform around it:

• Identity providers have moved on: new integrations default to OIDC for applications and APIs, and SAML 2.0 for SaaS. Microsoft's AD FS migration guidance tells organisations to migrate apps using SAML and OpenID Connect first and to bring older protocols in through Application Proxy or Secure Hybrid Access partners.
• Application frameworks have moved on: WS-Federation in .NET Framework applications typically relies on Windows Identity Foundation or OWIN middleware. ASP.NET Core provides Microsoft.AspNetCore.Authentication.WsFederation, a port of the OWIN middleware, but rewriting an application for modern .NET is the natural point to switch it to OIDC.
• Security expectations have moved on: WS-Federation has no equivalent of OIDC's authorisation code flow with PKCE, no standard for API access tokens and limited sign-out reliability. The ASP.NET Core middleware disables unsolicited sign-ins by default because that WS-Federation feature is open to cross-site request forgery; for token encryption options, confirm current behaviour in Microsoft's documentation.

Official timeline and current status

Status checked on 8 November 2026 against the sources in Standards and references.

We found no announced retirement date for WS-Federation support in Microsoft Entra ID as of the date checked. Treat any date you hear from a vendor or partner as unconfirmed until you see it on the vendor's own announcement page, and recheck this table before you plan.

Who and what is affected

• AD FS relying party trusts: internal web applications, SharePoint on-premises, older Dynamics deployments and partner portals configured with the WS-Federation passive endpoint (typically /adfs/ls/).
• Federated Microsoft 365 and Entra domains: domains whose authentication type is "Federated" use AD FS (or another WS-Fed and WS-Trust provider) for user sign-in. See the AD FS to Entra ID Migration guide.
• Custom .NET applications: apps referencing Windows Identity Foundation, System.IdentityModel.Services, OWIN WsFederation middleware or ASP.NET Core WsFederation.
• Third-party products: older commercial software that only offers WS-Federation or "ADFS" as its SSO option.
• Partner federation: external organisations federated into your tenant through a WS-Fed identity provider.
• Non-human identities: service accounts used by AD FS, the AD FS token signing and token decrypting certificates, and any automation that calls WS-Trust endpoints with a username and password. These are often the least documented parts of the estate.

Finding affected systems and identities

1. AD FS inventory: on each AD FS farm, export all relying party trusts with Get-AdfsRelyingPartyTrust and record the identifier, the WS-Federation endpoint, enabled state, claim rules and token signing settings. Back up the Microsoft 365 relying party trust as Microsoft's guidance shows (Export-CliXML) before any change.
2. Usage evidence: use AD FS audit events or Microsoft Entra Connect Health for AD FS to see which relying parties actually receive sign-ins and how many users each has. Disabled or unused trusts are quick wins.
3. Federated domains: run Get-MgDomain and Get-MgDomainFederationConfiguration for each verified domain to list federated domains, their issuer URIs and MFA behaviour settings (federatedIdpMfaBehavior).
4. Entra applications: review app registrations and enterprise applications for WS-Federation reply URLs ending in paths such as /signin-wsfed, and for sign-ins to the /wsfed endpoint in sign-in logs.
5. Code and configuration: search repositories and configuration files for wsFederation, wtrealm, FederationMetadata, System.IdentityModel.Services, AddWsFederation and Microsoft.Owin.Security.WsFederation.
6. Owners: attach an application owner, business criticality and data classification to every item. Items with no owner and no sign-ins are candidates for removal, not migration.

Migration options

Option 1: OpenID Connect

The best target for custom web applications, single-page apps behind a backend, mobile apps and anything that calls APIs. Use the authorisation code flow with PKCE, validate issuer, audience, signature and lifetime, and keep secrets out of browsers. Claims that came from AD FS claim rules must be rebuilt as token claims, app roles or group claims. See the OAuth 2.0 and OpenID Connect Guide.

Option 2: SAML 2.0

The pragmatic target for commercial products and for applications whose libraries already handle XML signatures. It keeps an assertion-based model close to WS-Federation, so attribute mapping usually carries over. Harden it as described in the SAML Security Guide.

Option 3: Keep WS-Federation, move the identity provider

Re-point the application from AD FS to Entra ID's WS-Federation endpoint without code changes. This removes AD FS and its signing key from your infrastructure but leaves the protocol debt. Use it for frozen applications, with a dated plan to replace them.

Option 4: Cloud authentication for federated domains

For Microsoft 365 sign-in, Microsoft recommends password hash sync as the cloud authentication method. Test with staged rollout (Hybrid Identity Administrator role, cloud-only groups, no nested or dynamic groups), then convert each domain with Update-MgDomain -AuthenticationType "Managed". Conversion can take up to 60 minutes, and domains need not be converted together.

Choosing by organisation size

• Small estates (a handful of relying parties, one federated domain) can often complete Options 3 and 4 in one programme and decommission AD FS within a quarter.
• Large estates with hundreds of trusts should triage by usage and risk, move the identity provider first (Option 3 or SAML) to retire AD FS, and schedule OIDC rewrites with application roadmaps.

Running what remains safely

• Protect the signer: treat AD FS servers, their service account and token signing certificates as tier zero assets. Golden SAML attacks forge tokens with a stolen signing key (T1606.002), and attackers who change federation trust settings (T1484.002 Trust Modification) can add their own signer. See the Golden SAML and Federation Trust Abuse Defence Guide and the AD FS Security Guide.
• Validate properly: relying parties must validate the token signature against every signing certificate published in metadata rather than pinning one, check the issuer and audience (wtrealm), and reject expired tokens.
• Keep unsolicited sign-in off: leave AllowUnsolicitedLogins disabled in ASP.NET Core unless a documented requirement exists.
• Use metadata URLs: configure partners with metadata URLs so certificate renewal is automatic; Entra External ID notes it cannot renew a partner signing certificate rotated early or configured without a metadata URL.
• Restrict and monitor: require MFA through Conditional Access for re-pointed apps, and alert on federation configuration changes and new relying party trusts.

Testing and rollback

1. Document current state: export trusts and claim rules, record federation settings, and capture a sample token for each app with a browser tracing tool so claims can be compared.
2. Stage the move: Microsoft describes four stages: production on AD FS, an optional test instance against a test tenant, a test instance against the production tenant, then production cut-over. Sync identities and verify group membership with Entra Connect Sync before you begin.
3. Compare claims: confirm the new token carries the same name identifier, roles and attributes the application expects, including any claim the app uses as a database key.
4. Pilot users: enable the new configuration for a pilot group; for domains, use staged rollout groups.
5. Cut over in off-hours: Microsoft advises planning domain cut-over outside business hours in case of rollback.
6. Rollback: keep the AD FS trust in place but unused until sign-off; for domains, recreate federation with New-MgDomainFederationConfiguration using the documented settings. Set a hard date after which AD FS is decommissioned and its signing certificates revoked and destroyed.

Risks of doing nothing

• Forgeable tokens: every relying party trusting a forgotten AD FS signer can be accessed with forged tokens if that key is stolen.
• Unsupported dependencies: applications tied to old frameworks and servers fall behind on patching (NIST SP 800-53 SA-22 Unsupported System Components).
• Inconsistent controls: sign-ins through AD FS may not get the Conditional Access, MFA and identity protection signals applied to cloud authentication.
• Skills loss: fewer engineers understand WS-* claim rules, which lengthens outages and incident response.
• Blocked modernisation: APIs, mobile apps and agent integrations need OAuth tokens that WS-Federation cannot issue.

Detection and measurement

• Monitor: changes to relying party trusts, token signing certificates and domain federation settings; sign-ins to WS-Federation endpoints by application; token issuance for unknown relying parties; AD FS service account use from unexpected hosts.
• Metrics: number of active WS-Federation relying parties (trend to zero); percentage of WS-Federation sign-ins now served by Entra ID rather than AD FS; federated domains remaining; applications with a named owner and target protocol; days since last AD FS sign-in before decommission.

Framework mapping

Practitioner checklist

• Export every AD FS relying party trust and record identifier, endpoint, claims and usage.
• List federated domains and their federation settings with Microsoft Graph PowerShell.
• Search code and configuration for WS-Federation middleware and WIF references.
• Assign an owner and a target protocol (OIDC, SAML or remove) to each item.
• Protect AD FS signing keys and service accounts as tier zero until decommission.
• Migrate in stages: test instance, production tenant, pilot users, cut-over in off-hours.
• Compare claims before and after for every application.
• Keep documented rollback settings, then decommission AD FS and destroy its keys on a fixed date.
• Alert on federation and trust configuration changes.

Standards and references

• OASIS: Web Services Federation Language (WS-Federation) Version 1.2
• Microsoft Learn: Federation metadata in Microsoft Entra ID
• Microsoft Learn: Migrate apps from AD FS to Microsoft Entra ID in stages
• Microsoft Learn: Migrate from federation to cloud authentication
• Microsoft Learn: Authenticate users with WS-Federation in ASP.NET Core
• Microsoft Learn: Federation with SAML/WS-Fed identity providers
• MITRE ATT&CK: Forge Web Credentials: SAML Tokens

Related NHI Mgmt Group resources: SAML vs OIDC Guide · AD FS to Entra ID Migration · Federation and Trust Relationships Guide · NIST SP 800-63C-4 Federation Assurance Levels Guide