Authorization check using Global.asax

Question

In my ASP.NET web application, I want to check every time the user is trying to get a page from my application if the user exist in the DB (of course after the first time we save the user details in the session). I tried to use the Application_AuthenticateRequest event in the global.asax to check for each request but the session does not exist in this event. I need an advice for where i can put my authorization logic that i would still have the session data available (to reduce db access).

Answer 1

You could use the SqlMembershipProvider (or a custom provider if you're not using MSSQL) and deny unauthenticated users from the entire application except from the login page. This check will be limited to the time of logon as the authentication ticket will be stored either in session or as a cookie on the user's machine.

More details at How To: Use Membership in ASP.NET 2.0 and Examining ASP.NET 2.0's Membership, Roles, and Profile

Answer 2

You sound as though you are "rolling your own" authentication system.

I would look into using ASP.NET's built in Forms authentication system that is commonly used with an ASP.NET Membership Provider. Built-in providers already exist for SQL Server, and you can create your own Membership Provider by inheriting from the System.Web.Security.MembershipProvider base class.

Essentially, the ASP.NET membership providers usually work by setting a client side cookie (also known as an Authentication Ticket) in the client's browser, once the client has successfully authenticated themselves. This cookie is returned to the web server with each subsequent page request, allowing ASP.NET, and thus your code, to determine who the user is, usually with a single line of code like so:

string username = HttpContext.Current.User.Identity.Name;
// The above gets the current user's name.

if(HttpContext.Current.User.Identity.IsAuthenticated)
// Do something when we know the user is authenticated.

You then should not need to store anything in the Session state. Of course, if you want to store user-specific data in a session variable (i.e. user-data that may not be part of the authentication of a user, perhaps the user's favourite colour etc.) then by all means you can store that in a session variable (after retrieving it from the DB when the user is first authenticated). The session variable could be stored based on the user's name (assuming unique names) and retrieved using code similar to the above which gets the current user's name to access the correct session object.

Using the built-in forms authentication will also allow you to "protect" areas of your website from un-authorized users with simple declarative code that goes in your web.config, for example:

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

Adding the above to your "main" web.config would ensure that none of your pages are accessible to un-authorized users (though you'd probably never do this in reality - it's just meant as an example). Using the ASP.NET Role Provider in conjunction with the Membership Provider will give you even greater granularity over who can or can't access various sections of your website.