I appreciate all help and feedback. Parts bolded are critical parts if this is too verbose. Perhaps it will help to mention I am a green developer. I have found some useful info from related questions posted here and on Stack Overflow but nothing that felt 100%.
Background
Currently at work we are developing a web application with strict constraints set forth by the client. Normally we are a Rails shop, but the client really wanted to work with us. Thus to fit into their architecture we will be using ASP.NET. We are not very experienced with ASP.NET but some of the team including myself have used .NET for desktop applications.
This application is three tiered and includes:
- Public facing server(s)
- Web services server(s)
- Data server(s)
The client is expecting high demand and they may have multiple servers in any one of the tiers. There is a firewall between every tier. From my understanding this is a very common set up.
A core goal is to minimize trips over the wire from the public facing server to the database.
The Problem
How do we handle user authentication without hampering performance on an N-Tier application with potentially many servers at each layer?
What We've Done so Far
We toyed with the idea of using view state but ultimately felt like this would be a poor idea. Of course we are not opposed to re-visiting view state, but feel that view state offers no benefits over cookies and simply makes it harder for a user to have multiple tabs of our application open.
I have been exploring the path of using the default session state with a custom implemented session store. The default session state tends to generate multiple requests going over the wire. Logging in and out this is okay, but when the user is using the app we do not want this. The custom session store helps minimize impact, but not by enough.
Conclusion & Possible Idea
Since trips to the database will be inevitable on almost all requests once inside the application, perhaps giving the user a key on successful login is the best way to go. Then when the user requests a new page, or posts a new page we could send that key with the related SQL transaction for the request and validate the key. I believe this will simplify the code base immensely.
So to re-iterate the problem: How do we handle user authentication without hampering performance on an N-Tier application with potentially many servers at each layer? Does the idea above sound like a solid implementation?
Thanks,
Jonathon