CODEWITHSUNDEEP
asp.netauthenticationasp.net-2.0
Aaronster
Aaronster

Reputation: 1824

Why has my ASP.NET single sign-on stopped working?

I have a .NET 2.0 web application which acts as authentication stub for an older .NET 1.1 web app. So a user logs in via the 2.2 app and then gets redirected to the 1.1 app to do their business. I had used the technique described by Scott Guthrie, with matching machine keys in the local web.config files, so that the auth ticket would be readable by both applications. This technique has worked for me in five instances for a couple of years.

Until now.

As of this morning four of our paired applications, configured as described above, have stopped working in production: we get bounced back after a (seemingly) successful authentication attempt. During a login attempt I get bounced back to the login page. I've checked event logs and IIS logs and found nothing of consequence. We can see the auth cookie has been set in our browsers. We've tried multiple browsers (IE and Chrome). Over the weekend I know that more than a dozen patches were installed on the web server, one of which added Framework 4.0, but I have no way of knowing whether any of these patches caused the problem. Interestingly, I noticed the same behavior on my dev box before Christmas. Since that time none of the four paired applications has been re-deployed, so don't think it was a deployment issue which caused it to spread to production.

There is one pair of applications which is still working and we're comparing the code and configuration to see what's up, but so far we haven't found anything (or else I wouldn't be writing this post!)

UPDATE I figured out what that lone pair of applications was doing right: it was handling authorization through code. So I developed a workaround for my ailing apps:

ORIGINAL:

<authorization>
    <allow deny="?" /> 
</authorization>

WORKAROUND:

<authorization>
    <allow users="*" /> 
</authorization>

Then I added code to my ASPX base page to check for an auth cookie:

if (Request.Cookies.Get(FormsAuthentication.FormsCookieName) == null)
    Response.Redirect(System.Configuration.ConfigurationSettings.AppSettings["MembershipLoginURL"],true);

My code seems to be fulfilling a role which used to be performed by ASP.NET, namely checking whether or not a user is authorized. So - I have a workaround, but the mystery remains.

Does anyone know if there was a patch from Microsoft, released in the past four months (our server was just updated with four month's worth of patches), that disabled ASP.NET's ability to authenticate/decrypt cookies between web applications on different versions of .NET?

Upvotes: 4

Views: 1067

Answers (2)

Aaronster
Aaronster

Reputation: 1824

I received a response from Scott Guthrie... the problem I am experiencing was caused by a Windows update.

Here's the hotfix: FIX: Forms authentication cookies compatibility issue between .NET Framework 1.1 and .NET Framework 2.0 SP2 ASP.NET applications after you apply the security update from security bulletin MS10-070

I have deployed this hotfix on my local XP SP3 machine and also staging and production Windows 2003 machines and it definitely fixed the problem.

Upvotes: 2

Chris B. Behrens
Chris B. Behrens

Reputation: 6295

If there's a working application on the server, then that seems to point away from the patches per se being the problem, though they may be part of it.

I have an order of operations for these things. When you see a problem, debug it. If you can't debug it, instrument it (put code in that logs what's going on inside the application). If you can't instrument it, diff it.

If you're not using a diff tool already, I would strongly suggest using one. I like Beyond Compare from Scooter Software, but there are plenty of other good ones. Install it on your server and run a diff between the working and non-working configs. That might tell you the answer right there.

It doesn't sound like you're using certs anywhere in this scenario, but they come into play a lot with SSO's, so on the off chance that there is a cert involved, and you haven't mentioned it, expiring certs bring SSOs down mysteriously overnight, so be sure and double-check that.

Upvotes: 1

Related Questions