Fixing ASP.NET Web Forms WS‑Federation Sign‑Out Redirects in ADFS

by

Summary

A production issue was identified where users, upon logging out of an ASP.NET Web Forms application, were being stranded on the ADFS default logout confirmation page instead of being redirected back to the application’s login screen. Despite the application correctly issuing a wsignout1.0 request containing a valid wreply parameter, the ADFS server ignored the redirection instruction. This resulted in a broken user experience and confusion regarding the application’s session state.

Root Cause

The root cause is a security policy enforcement mechanism within ADFS regarding the wreply parameter during sign-out requests.

  • Parameter Misuse: In WS-Federation, the wreply parameter is standard for Sign-In operations. For Sign-Out operations, the protocol specifically expects the wsignout1.0 command to be paired with a wreply (or more traditionally wpostreply) that is explicitly validated against the Relying Party Trust (RPT) configuration.
  • ADFS Security Defaults: ADFS 2016 and 2019 implement strict validation. If the wreply URL provided in the query string does not exactly match the identifier defined in the Relying Party Trust’s Endpoint configuration, ADFS considers the request potentially malicious (an Open Redirect attack) and falls back to its internal default logout page.
  • Implementation Mismatch: The application was attempting to manually override the Wreply property in the RedirectToIdentityProvider notification, but the value being passed did not satisfy the ADFS server’s security requirements for the specific Relying Party.

Why This Happens in Real Systems

In complex enterprise environments, this happens due to the friction between application logic and identity provider (IdP) security hardening:

  • Strict Redirect Validation: IdPs like ADFS, Okta, or Azure AD do not blindly honor redirect URLs. They use a “whitelist” approach to prevent attackers from using the IdP to redirect users to phishing sites.
  • Protocol Nuances: Developers often assume wreply is a universal “redirect after this action” parameter. However, different Federation protocols (SAML, WS-Fed, OIDC) treat post-action redirection differently.
  • Configuration Drift: The Wtrealm (the identifier) and the actual URL used in the application might differ by a trailing slash or a minor character, causing the IdP to reject the redirection.

Real-World Impact

  • User Friction: Users are left staring at a technical “You have signed out” page, leading them to believe the application has crashed or the session is stuck.
  • Support Overhead: Increased tickets from users reporting that they “can’t get back to the login page” or that the “logout button is broken.”
  • Security Perception: A broken authentication flow decreases user trust in the application’s security posture.

Example or Code

The problematic implementation involves attempting to force a redirect via the Notifications callback, which ADFS may ignore if the destination isn’t pre-registered.

// The logic that fails to trigger the redirect in ADFS
Notifications = new WsFederationAuthenticationNotifications
{
    RedirectToIdentityProvider = context =>
    {
        if (context.ProtocolMessage.IsSignOutMessage)
        {
            // This value MUST match an allowed endpoint in the ADFS RPT configuration
            context.ProtocolMessage.Wreply = ConfigurationManager.AppSettings["SignOutRedirectUrl"];
        }
        return System.Threading.Tasks.Task.FromResult(0);
    }
}

How Senior Engineers Fix It

Senior engineers resolve this by aligning the Application Identity with the IdP Configuration rather than trying to “force” the protocol:

  • Synchronize Endpoints: Ensure that the URL provided in SignOutRedirectUrl is explicitly added as a WS-Federation Passive Request Endpoint within the ADFS Management Console for that specific Relying Party Trust.
  • Verify Relying Party Identifier: Ensure the Wtrealm in web.config matches the Relying Party Identifier in ADFS exactly (e.g., checking for https://fdfp.oc.gov.ma/Workflow vs https://fdfp.oc.gov.ma/Workflow/).
  • Use Correct Parameters: Instead of manually manipulating the ProtocolMessage in OWIN, configure the WsFederationAuthenticationOptions to use a registered, valid endpoint that ADFS is already configured to trust.
  • Audit ADFS Logs: Check the ADFS Admin logs (Event Viewer) on the server. ADFS will explicitly log why a redirect was rejected (e.g., “The redirect URL is not in the allowed list”).

Why Juniors Miss It

  • Focusing on the Client, Not the Server: Juniors often assume that if the browser is sending the correct URL (the wreply is visible in the address bar), the server must honor it. They fail to realize the server is the ultimate authority.
  • Treating Auth as a Black Box: They view ADFS as a “magic” service that just works, rather than a highly configurable security gatekeeper with its own strict rulesets.
  • Debugging the Code instead of the Config: They spend hours debugging the Startup.cs or the Logout button logic, when the actual fix resides in the ADFS Management Console settings.

Leave a Comment