Skip to content

Beware WIF Session Authentication Module (SAM) redirects and WebAPI services in the same application

February 8, 2013

It is very common to want to build a browser based app in the same project as a WebAPI endpoint. If you’re also using claims and WIF (and thus the SAM) then there’s a subtle problem you should look out for.

When HTTP requests are made into an application using WIF then the SAM intercepts each one of these to look for the incoming session token for authentication. If the cookie’s there, then no worries, but if the cookie is not present then the SAM does an interesting thing — it essentially checks the incoming URL against the URL for the application as it’s configured in the host (meaning IIS) and it performs a case-sensitive comparison. If that comparison fails then it redirects the user to the correct cased URL. You can see the code here:

 if (!this.TryReadSessionTokenFromCookie(out sessionToken) &&
     string.Equals(request.HttpMethod, "GET", StringComparison.OrdinalIgnoreCase))
    {
        string absoluteUri = request.Url.AbsoluteUri;
        string y = MatchCookiePath(absoluteUri);
        if (!StringComparer.Ordinal.Equals(absoluteUri, y))
        {
            application.Response.Redirect(y, false);
            application.CompleteRequest();
        }
    }

I suppose this makes sense since URLs are case sensitive and thus the intent is to redirect the user’s browser to the correct cased URL so that the cookies will be sent in correctly.

This behavior causes a problem for API-based clients. If they issue a HTTP request and have the casing on the URL wrong then they get a redirect response rather than being dispatched to the expected handler in the server. Normally this wouldn’t be an issue since the redirect is back into the same URL originally requested (with the casing corrected). The problem is that the redirect will not necessarily retransmit HTTP headers sent on the original request. I ran into this problem because I was writing a C# WebAPI client using HttpClient class. It was sending an Authorization header and the automatic redirect was dropping the header and thus the call became unauthenticated. It made for a very frustrating hour of debugging.

So if you have an API client making HTTP calls into a claims-enabled application and headers you are sending aren’t being seen by the server, then this might be your problem. The moral of the story is that URLs are case sensitive which is often forgotten.

One Comment leave one →
  1. August 25, 2017 11:50 am

    It was great to find this posting. We encountered this issue because we have a web proxy with url rewrite rules. The output of the rewrite did not case-match the application url. This caused infinite redirects.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: