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.
So was the cookie set properly for the page to be able to read it? I could see that the path on the cookie was ‘/’ and that the host name was correct, but to be sure I fired up Fiddler. After taking a look at the headers being sent to the server I saw that the cookie (we will call it ‘.MYAUTH’) was in fact being sent to the server. This made me wonder if the server was able to read the cookie. I threw together a quick webapp that we will call ‘myTestApp’. It tried to read the contents of the .MYPASPORT cookie. It could not. So I snagged a quick piece of JavaScript to read the cookie and added it to the default.aspx:

<script type="text/javascript">
function readCookie(name)
{
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)
{
return c.substring(nameEQ.length,c.length);
}
return null;
}
}
</script>

This allowed me to see when the cookie was set.

The Hypothesis
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[1]:

<system.web>
<authentication mode="Forms">
<forms name=".MYAUTH06"
loginUrl="default.aspx"
path="/"
enableCrossAppRedirects="true">
</forms>
</authentication>
<authorization>
<allow users="*" />
</authorization>
</system.web>

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 + "-";
if (User.Identity.IsAuthenticated)
{
lblStatus.Text += "<br>Authenticated as: " +
User.Identity.Name;
lblStatus.Text += "<br>From: " +
User.Identity.AuthenticationType;
}

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:


<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>

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:


<system.web>
<authentication mode="Forms">
<forms name=".MYAUTH06"
loginUrl="/myauth/default.aspx">
</forms>
</authentication>
<authorization>
<deny users="?" />
</authorization>
</system.web>

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.

Resources
TOOLS
Firefox
Web Developer Firefox Extension
Fiddler

MSDN
[1]Explained: Forms Authentication in ASP.NET 2.0
ASP.NET 2.0 Member/Role Management with IIS: Security and Configuration Overview
ASP.NET 2.0 Member/Role Management with IIS: Implementation

Advertisements

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