Cross Application Authentication (part 1 – Trouble Shooting)
with Native .NET Forms Authentication
Where I work we have numerous applications written in .NET planted across our IIS root. Instead of each application authenticating it’s users in their own way, we have a central authentication application. Then each application uses a shared dll to interpret this authentication. Up until recently all these applications were written on top of the .NET 1.x framework. When applications started to be written in against the .NET 2.o framework we ran into a few snags. The first part of this post will cover these snags so you can avoid them yourself. This information is taken from authorities resources, which are sited at the end. This is simply the interpretation and real world application of them. There are still some fact holes that I would love to fill. If you find this and can fill in the wonderment, feel free to comment.
Failure To Communicate
You can simply take a 1.x project and open it in Visual Studio (VS) 2005 and follow the wizard. Some would have you believe that the application will then just run without tampering with. Anyone with a any experience will tell you that if that happens you simply aren’t in the forest to hear the tree fall, and you are just waiting for the other shoe to do the same.
After some code related problems that I will cover in Part 3, I found that when I tried to login to my application the forms authentication application would not give me any feed back, it would simply postback and refresh. I could purposely mistype my authentication and get the error back that confirmed my actions. This application was also working for many other 1.x applications at this time. This made me conclude that the application was not hearing the authentication token. A quick look at the cookies in Firefox confirmed that the cookie was there.
var nameEQ = name + "=";
var ca = document.cookie.split(';');
for(var i=0;i < ca.length;i++)
var c = ca[i];
while (c.charAt(0)==' ') c = c.substring(1,c.length);
if (c.indexOf(nameEQ) == 0)
This allowed me to see when the cookie was set.
I learned something when I setup my test app. When you are running 1.x code and 2.x code on the same IIS server you must put them in different application pools. This made gave me a hypothesis, that is 1.x apps are not allowed to talk to 2.x apps. A search of MSDN showed me that the preferred way of securing forms authentication is to prevent communication between applications. Also serialization and encryption was completely revamped for v2.0. This added weight to this hypothesis.
Proving What Lacked in Documentation
I looked for specific documentation on this but about the only thing I came across told me that the encryption and serializatoin had changed between 1.x and 2.0. This was emphasized by the error in the application log. It simply told me “Forms authentication failed for the request. reason: The ticket supplied was invalid”. While this was enough proof for me, I have business owners I need to justify the deployment to. So to prove this in realworld terms I needed to build an authentication application on 2.x. (This was very easy using the 2.0 built-in authentication controls.) In the web.config I placed the following as instructed in the documentation at MSDN:
<allow users="*" />
I added a button that would not use the RedirectFromLoginPage() method but instead simply set the cookie with SetAuthCookieand(), then display that I was authenticated. I also added a means of displaying the cookie information on that page to prove that everything was set and that I could read the information in the intended fashion.
lblStatus.Text = "-" + FormsAuthentication.FormsCookieName + "-";
lblStatus.Text += "<br>Authenticated as: " +
lblStatus.Text += "<br>From: " +
Then I needed a page that would need authentication in the same app. I created a subfolder and a page that used the same code as above to display the authentication information. Then I made a web.config file in that directory and added the following to it:
<deny users="?" />
This proved that the application was working on it’s own. I then changed the web.config of myTestApp to look similar to the following:
<deny users="?" />
This sets the cookie name to key off of the newly defined name and redirect unauthenticated users (signified by ‘users=”?”’) to /myauth/default.aspx. By changing the name of the cookie, the users of the site may have to authenticate twice, but as long as their session is kept alive they can pass between applications without re-entering their credentials.
Now it was time to test. Imagine my dismay when I found that I got the same results. Authentication worked when dealing with the same application, but it seemed to be isolated from the other application. So I started in on the configuration of the server. This is covered in the next post.